Guardrails voor AI Agents: Inspectie van Elke Tool Call en Model Hop

Wat Zijn Guardrails voor AI Agents?

Guardrails voor AI agents zijn mechanismen voor inhoudsinspectie die de daadwerkelijke payload van elke agent-interactie onderzoeken — de gebruikersprompt, de reactie van het model en de argumenten en resultaten van elke tool call — en actie ondernemen (toestaan, blokkeren of herschrijven) op basis van beleid.

Het helpt om twee vragen te scheiden die elke beheerde agent call moet beantwoorden:

• Of de call is toegestaan — afgehandeld door identiteits- en toegangsbeheer (welke agent is dit, wat mag deze doen).
• Wat de call bevat — afgehandeld door guardrails (zit er een injectie in dit tool-resultaat, een secret in deze output, een DROP TABLE in deze argumenten).

Toegangsbeheer is de uitsmijter bij de deur; guardrails zijn de metaaldetector. Je hebt beide nodig. Een agent kan volledig geautoriseerd zijn om je Postgres MCP-server aan te roepen en toch misleid worden om een destructieve query te sturen — toegang zei ja, en alleen een guardrail op de tool-argumenten ziet wat de query daadwerkelijk is.

Waarom agents de inzet verhogen

Guardrails zijn niet nieuw voor LLM-applicaties, maar agents veranderen het probleem op drie concrete manieren:

• Onbetrouwbare inhoud stroomt continu binnen. Elk tool-resultaat — een webpagina, een supportticket, een databaserij — komt bij de volgende beurt opnieuw de context van het model binnen. Elk deel daarvan kan een injectie bevatten, dus inputs moeten worden gecontroleerd zelfs als de gebruiker vertrouwd is.
• Outputs worden acties. Een gehallucineerd shell-commando of een te brede SQL-statement leest niet alleen slecht; het wordt uitgevoerd. Tool-argumenten moeten worden gecontroleerd voordat de tool wordt uitgevoerd.
• Ketenstructuren vermenigvuldigen het risico. Een keten van vijf tools betekent vijf kansen om een secret te lekken of PII te exfiltreren. Effectieve guardrails draaien op elke tool call afzonderlijk, zodat elke hop zijn eigen controles krijgt.

Waar Guardrails voor AI Agents Draaien: De Vier Hooks

Op TrueFoundry worden guardrails afgedwongen bij de gateway op het agentic call-pad — de keten van gebruiker → app → agent → sub-agent → MCP tool calls. Elke beheerde hop passeert een interceptiepunt met een voor- en na-hook.

De volgorde is van belang voor kosten en impact. Een fout bij pre-tool betekent dat de tool nooit wordt uitgevoerd — de goedkoopst mogelijke fout. Een fout bij LLM-input annuleert het lopende modelverzoek voordat je ervoor betaalt. Omdat elke hop onafhankelijk wordt gecontroleerd, wordt een gecompromitteerd tool-resultaat bij hop drie onderschept op hop drie, en niet pas nadat het al is vertakt naar nog eens drie calls.

Risico's Koppelen aan Guardrails

De waarde van het draaien van guardrails bij de MCP Gateway is dat elk echt agent-risico wordt gekoppeld aan een specifieke, ingebouwde controle. De ingebouwde guardrails van TrueFoundry draaien op door TrueFoundry beheerde infrastructuur — er hoeven geen API-sleutels van derden te worden geconfigureerd.

Naast de ingebouwde opties maakt de gateway verbinding met externe providers — Palo Alto Prisma AIRS, CrowdStrike AIDR, Cisco AI Defense, AWS Bedrock Guardrails, Google Model Armor, NVIDIA NeMo Guardrails, Guardrails AI en meer — en ondersteunt het volledig op maat gemaakte guardrails wanneer je logica nodig hebt die specifiek is voor jouw domein.

De guardrail voor prompt-injectie is specifiek gebouwd voor het agent-probleem: het analyseert de gebruikersprompt en eventuele document- of contextinhoud afzonderlijk, zodat een injectie die verborgen zit in een geretourneerde webpagina of ticket wordt opgemerkt, zelfs als het eigen bericht van de gebruiker schoon is.

Hoe Guardrails te Implementeren voor AI Agents

Het toepassen van guardrails op agent-verkeer is een proces van drie stappen, en het cruciale is dat niets daarvan in je agent-code staat.

Stap 1 — Registreer de guardrails

Maak in AI Gateway → Guardrails een guardrails-groep aan en voeg de integraties toe die je nodig hebt — ingebouwd, via een externe provider of op maat gemaakt. Een groep is ook de eenheid van toegangsbeheer: een Manager kan guardrails toevoegen, bewerken en verwijderen; een User kan ze alleen toepassen. Een veelvoorkomend patroon is één organisatiebrede groep die eigendom is van het platformteam, plus groepen per team voor productspecifieke controles.

Stap 2 — Maak beleid dat guardrails koppelt op basis van het doel

Maak in AI Gateway → Policies → Guardrails regels aan die bepalen wanneer elke guardrail draait. Dit is wat het model schaalbaar maakt voor vloten van agents: regels zijn gekoppeld aan het doel (de modellen, MCP-servers en zelfs specifieke tools die worden aangeroepen) en het subject (gebruikers, teams of virtuele accounts). Omdat een regel geldt voor elke aanroeper van een bepaalde MCP-server of model, beschermt het elke agent die dat doel raakt — zonder configuratie per agent.

Elke regel combineert:

• Doelen — modellen (IN / NOT IN) en MCP-servers, optioneel vernauwd tot specifieke tools (bijv. alleen de run_query tool van een database server).
• Subjecten — IN / NOT IN filters op gebruikers, teams of virtuele accounts.
• Metadata — overeenkomen op X-TFY-METADATA sleutel-waardeparen, zodat een regel alleen kan gelden voor environment: production.
• Hooks — koppel de geregistreerde guardrails aan LLM Input, LLM Output, MCP Tool Pre-Invoke of Post-Invoke.

Alle overeenkomende regels worden geëvalueerd en hun guardrails worden samengevoegd per hook. Als Regel A PII-detectie toepast op LLM Input en Regel B prompt-injectiedetectie toepast op LLM Input, draaien ze allebei. Een regel zonder doel- of subjectvoorwaarden wordt een basislijn die geldt voor al het verkeer — nuttig voor een bedrijfsbrede controle op prompt-injectie bovenop al het andere.

Voor snelle tests of eenmalige calls kun je guardrails ook per verzoek doorgeven met de X-TFY-GUARDRAILS header, die beleidsregels volledig omzeilt:

Stap 3 — Verifieer in traces

Elk verzoek wordt getracet met de guardrails die hebben gedraaid en hun oordelen, zodat je de dekking kunt bevestigen voordat je erop vertrouwt. Dit is ook waar je valse positieven afstemt, wat voor agents belangrijker is dan voor chatbots: een geblokkeerde hop kan een hele keten laten mislukken.

Gebruik voor de lancering de Playground om testprompts en tool calls af te vuren op alle vier de hooks en te zien wat er wordt opgevangen.

Handhavingsmodi: Valideren, Muteren en Hoe Strikt te Blokkeren

Twee instellingen bepalen hoe elke guardrail zich gedraagt.

Operationele modus:

• Validate — inspecteren en blokkeren (bijv. detectie van prompt-injecties, wat alleen detecteert en blokkeert).
• Mutate — de inhoud herschrijven en optioneel blokkeren (bijv. PII-detectie die een e-mailadres redigeert voordat de prompt het model bereikt).

Handhavingsstrategie:

• Enforce — blokkeren bij een overtreding en als de guardrail zelf een fout geeft. Gebruik dit voor strikte compliance-controles zoals PII.
• Enforce But Ignore On Error — blokkeren bij een overtreding, maar verkeer doorlaten als de guardrail-provider een storing heeft. De pragmatische standaard voor het meeste agent-verkeer.
• Audit — alleen loggen, niets blokkeren.

Voor aangepaste logica implementeer je een guardrail als een HTTP-service en leest de gateway het responseresultaat: een HTTP 2xx betekent dat de guardrail is uitgevoerd, en de JSON-body bevat het resultaat — verdict: false om te weigeren, of een gewijzigde result-body om te herschrijven:

Aanbevolen uitrol voor agents: start elke nieuwe guardrail in Audit en bekijk traces om te zien wat het zou opvangen. Schakel over naar Enforce But Ignore On Error voor bescherming die een storing bij de provider overleeft. Bewaar volledig Enforce voor de controles waar je geen compromissen over kunt sluiten — PII, secrets, destructieve SQL. Omdat een enkele geblokkeerde hop een hele agent-keten kan breken, is eerst auditen niet optioneel.

Waarom Guardrails voor Agents Afdwingen bij de Gateway

Je zou kunnen proberen deze controles binnen elke agent te implementeren. De reden om dat niet te doen is dezelfde reden waarom een AI gateway beter is dan een API gateway voor dit verkeer: consistentie en dekking.

• Één beleid, elke agent. Omdat regels gekoppeld zijn aan het doel, erft een nieuwe agent die een reeds beheerde MCP-server aanroept de guardrails automatisch — er hoeft niets aan de code te worden toegevoegd.
• Framework-agnostisch. Agents gebouwd op LangGraph, CrewAI, AutoGen of een aangepaste loop routeren allemaal via dezelfde Agent Gateway en krijgen dezelfde controles.
• In het kritieke pad, niet in de weg. De gateway voegt ongeveer ~3–4 ms overhead toe en ondersteunt 350+ RPS op een enkele vCPU, zodat inspectie per hop niet de bottleneck wordt.
• VPC-native. Guardrails draaien binnen je eigen AWS-, GCP- of Azure-account over 1.000+ modellen achter één OpenAI-compatibele API — prompts, tool-argumenten en resultaten verlaten nooit je omgeving. Dat is wat SOC 2-, HIPAA- en GDPR-audits haalbaar maakt.

Het resultaat zijn guardrails die zich gedragen als infrastructuur: uniform toegepast, waarneembaar in elke trace en beheerd door het platformteam in plaats van verspreid over een dozijn agent-repositories.

Gerelateerde artikelen

• MCP Server Security Best Practices — het beveiligen van de servers die je agents aanroepen
• Enterprise AI Security with the MCP Gateway & Runtime Guardrails — het bredere veiligheidsbeeld voor bedrijven
• MCP vs A2A — hoe agents met tools en met elkaar communiceren
• AI Gateway vs API Gateway — waarom agent-verkeer een ander controlepunt nodig heeft
• What is MCP Authorization? — de toegangsbeheer-helft van governance

Conclusie

Guardrails voor AI agents zorgen ervoor dat een autonoom systeem niet handelt op de verkeerde instructie — door elke prompt, output en tool call te inspecteren op injecties, PII, secrets en onveilige operaties voordat ze schade aanrichten. Het moeilijke deel is niet een enkele controle; het is ze consistent toepassen op elke agent, elk model en elke tool zonder de logica door je hele codebase te verspreiden. Ze afdwingen bij de gateway lost precies dat op: één set regels, gekoppeld aan doelen, die elke aanroeper dekt, waarneembaar in elke trace en draaiend binnen je eigen cloud.

Zie hoe TrueFoundry guardrails uitvoert over je agents, modellen en MCP-tools vanaf één controlepunt → Boek een demo of start gratis.