Guardrails voor AI-agenten: zo voorkomt u een kostbare fout

Een AI-agent die zonder beperkingen draait, is als een coureur op een proefrit zonder remmen. Meestal gaat het goed. Maar als het misgaat — en dat moment komt — gaat het snel en duur. In de praktijk hebben we agenten gezien die door een oneindige lus 's nachts duizenden API-calls genereerden met een rekening van duizenden euro's tot gevolg, agenten die productiedata overschreven in plaats van testdata, en agenten die interne documenten naar een extern endpoint stuurden terwijl ze probeerden te "helpen". Al die gevallen hadden voorkomen moeten worden door één ding: guardrails.

Guardrails zijn geen excuus of blokkade. Het zijn bedrijfsregels — zoals de stroomonderbrekers in een schakelkast. Als ze goed zijn ingesteld, vertragen ze de productie niet. Als ze ontbreken, legt één storing alles plat. Dit artikel beschrijft guardrails in concrete lagen en laat zien wat u moet implementeren vóórdat u een agent in productie neemt.

Waarom guardrails niet optioneel zijn

Een agent is geen chatbot. Een chatbot antwoordt — in het ergste geval stuurt hij slecht geformuleerde tekst. Een agent handelt: hij roept API's aan, schrijft naar databases, verstuurt e-mails, start scripts, reserveert resources. Elke actie heeft een neveneffect in de wereld buiten het LLM.

De meeste productie-incidenten bij agenten zijn niet ontstaan doordat het model "hallucineerde". Ze zijn ontstaan doordat het model de opdracht correct begreep, maar niemand had beperkt wat het mocht doen bij de uitvoering van die opdracht. Een aanvaller die weet van prompt injection (in de OWASP LLM Top 10 staat het al langere tijd op de eerste plek) kan instructies verbergen in externe inhoud die de agent inlaadt en als legitieme opdrachten uitvoert. Zonder guardrails gehoorzaamt de agent.

Guardrails zijn een meerlaags systeem — geen eenmalig outputfilter aan het einde van de pipeline. Elke laag vangt een ander type storing op.

Laag 1: Inputvalidatie

De eerste verdedigingslinie ligt vóór het LLM zelf. Voordat de agent een query ontvangt, moet u het volgende verifiëren:

• Invoerlengte — definieer een maximale promptlengte. Extreem lange invoer kan de context overspoelen, injecties verbergen of de verwerking vertragen.
• Sanitisatie — verwijder of escape HTML, SQL-speciale tekens en shell-metacharacters. Dit geldt ook voor teksten die de agent inlaadt uit externe bronnen (websites, e-mails, documenten).
• Intent-classificatie — een lichtgewicht classificator (een klein model of een regex-ruleset) detecteert of de invoer eruitziet als een manipulatiepoging (prompt injection, jailbreak-patroon). Tools als Lakera Guard of Guardrails AI lossen dit out-of-the-box op, maar zelfs een eigen ruleset op 20 patronen vangt 80 % van de gangbare pogingen.
• PII-detectie — als de agent invoer van gebruikers verwerkt, controleer dan of de invoer geen gevoelige gegevens bevat (rijksregisternummer, IBAN) die uw systeem niet mogen verlaten.

In de praktijk: inputvalidatie is goedkoop (milliseconden, geen LLM-tokens) en vangt triviale aanvallen op voordat ze het model bereiken.

Laag 2: Action allowlist

Dit is de belangrijkste laag voor agenten met tools. Definieer expliciet welke acties de agent mag uitvoeren — en blokkeer standaard alles andere.

Concreet: elke tool die de agent kan aanroepen, moet op de allowlist staan. Het is niet voldoende dat de tool in de code bestaat — hij moet geregistreerd zijn voor de betreffende context en gebruikersrol. Voorbeeld van een structuur:

• read_document(id) — toegestaan voor iedereen
• search_web(query) — toegestaan, maar alleen voor goedgekeurde domeinen
• send_email(to, body) — toegestaan, maar alleen voor interne adressen met @uwbedrijf.nl
• write_database(table, data) — alleen toegestaan voor niet-productietabellen
• delete_record(id) — geblokkeerd; vereist human approval

De allowlist is niet alleen een beveiligingsmechanisme — het is ook documentatie van wat de agent werkelijk doet. Wanneer een agent zich onverwacht gedraagt, is de allowlist de eerste plek om te auditen.

Scope per sessie: geef geen globale toestemmingen. Elke agentsessie krijgt de minimaal benodigde scope (principle of least privilege). Een agent voor de analyse van leveringsbonnen heeft geen toegang tot HR-data nodig.

Laag 3: Uitvoeringslimieten (max_steps, budget, tijdslimiet)

Een agent in een oneindige lus zonder plafond is een recept voor een incident. Definieer harde limieten:

• `max_steps` — maximaal aantal stappen (iteraties) per uitvoering. Aanbevolen bereik voor productieagenten: 15–50 stappen afhankelijk van de complexiteit. Boven het limiet → graceful stop, geen crash.
• Tijdslimiet — elke uitvoering van een agent moet een timeout hebben. Als een agent 10 minuten bezig was aan een taak die 30 seconden zou duren, is er iets misgegaan. De timeout onderschept dat eerder dan de rekening.
• Token-/budgetlimiet — wijs elke sessie een maximum aantal tokens of een maximale API-cost toe. Voor agenten met variabele uitvoeringstijd is dit een effectiever plafond dan alleen max_steps. Een maximum van $0,50–$5 per sessie is voor de meeste use-cases redelijk.
• Retry-cap — tool calls mislukken wel eens. Retry-logica is noodzakelijk, maar zonder begrenzing (bijv. max 3 pogingen per tool call) kan een agent honderden calls genereren naar hetzelfde defecte endpoint.

LangGraph (de facto standaard voor stateful productieagenten) implementeert deze limieten native via graafconfiguratie — max_recursion_limit, checkpointing, interrupt-bodies. Instellen is een kwestie van minuten, niet van dagen.

Laag 4: Sandbox en isolatie

Als een agent code uitvoert, shell-commando's uitvoert of met het bestandssysteem werkt, is isolatie een vereiste — geen optionele feature.

• Containerisatie — code die de agent genereert en uitvoert, moet draaien in een geïsoleerde container (Docker, gVisor) met beperkte rechten. Niet op het hostsysteem.
• Read-only bestandssysteem — mount productiedata als read-only. De agent mag lezen, niet overschrijven.
• Netwerksegregatie — als de agent geen internet nodig heeft, blokkeer het dan. Als hij dat wel nodig heeft, definieer dan een allowlist van domeinen (niet open internet).
• Tijdelijke omgeving — maak voor elke uitvoering een schone sandbox, vernietig die na de uitvoering. Geen gedeelde toestand tussen sessies.

Voor agenten die code uitvoeren in een industriële omgeving (PLC-scripting, configuratie van netwerkapparatuur) is deze laag kritiek — een fout kan fysieke gevolgen hebben.

Laag 5: Human-in-the-loop (HITL) en approval gates

Niet elke actie van een agent vereist menselijk toezicht — dat zou het doel van automatisering tenietdoen. Maar sommige acties wel, en die moet u expliciet identificeren.

Typische high-risk acties die approval vereisen: - Financiële transacties boven een gedefinieerde drempel - Verzenden van externe communicatie (e-mails naar klanten, berichten aan partners) - Wijzigingen in productiedatabases of configuraties - Acties met onomkeerbare gevolgen (verwijderen, deployen)

LangGraph implementeert HITL via interrupt() — de agent stopt, wacht op menselijke invoer (goedkeuring / afwijzing / correctie) en gaat verder of stopt op basis van het antwoord. Dit is geen "vertraging" — het is een kill-switch voor kritieke acties.

Voor reguliere stappen gebruikt u de aanpak Human-on-the-loop: de agent draait autonoom, maar elke stap wordt gelogd en is real-time beschikbaar voor review via een observabilityplatform. Een mens grijpt alleen in als hij een alert ontvangt of wil auditen.

De EU AI Act (art. 14) verplicht vanaf 2 augustus 2026 menselijk toezicht voor high-risk AI-systemen — HITL-implementatie is niet alleen goede praktijk, maar een wettelijke verplichting voor de relevante categorie systemen.

Laag 6: Outputvalidatie

Het outputfilter is het laatste vangnet voordat het resultaat van de agent het systeem verlaat of een volgende actie triggert.

• Schema-validatie — als de agent gestructureerde uitvoer produceert (JSON, XML, parameters voor een volgend systeem), valideer die dan tegen een schema vóór gebruik. Misvormde JSON kan een downstream-systeem laten crashen.
• Contentfilter — detecteer potentieel schadelijke inhoud (PII in het antwoord, gevoelige bedrijfsinformatie, ongewenste patronen).
• Faithfulness-check — als de agent met documenten werkt (RAG), verifieer dan dat het antwoord niet "uit de lucht" komt. Eenvoudige heuristieken (aanwezigheid van citaten, confidence score) of LLM-as-judge vangen de ergste hallucinaties op vóór aflevering van het resultaat.
• Formaat en lengte — als de uitvoer naar een volgend systeem gaat, verifieer dan dat hij de limieten niet overschrijdt (max tokens, max bestandsgrootte).

Een tool als NeMo Guardrails (NVIDIA) of Guardrails AI maakt het mogelijk deze validaties declaratief te definiëren — u voegt een yaml-definitie van regels toe, geen extra code in de pipeline.

Kill-switch en noodstop

Zelfs als alle lagen correct zijn ingesteld, heeft u een mechanisme nodig om een agent onmiddellijk te stoppen. Een kill-switch is geen paranoia — het is een zekering die u (als alles goed gaat) nooit zult gebruiken.

Minimale implementatie van een kill-switch:

• Per-sessie kill — elke agentuitvoering heeft een uniek ID; een operator kan de sessie stoppen via een API of dashboard
• Global pause — een schakelaar die alle agenten tegelijk stopt (gedwongen update, beveiligingsincident)
• Circuit breaker — automatische kill als het foutenpercentage een drempel overschrijdt (bijv. 20 % mislukte tool calls in 5 minuten → agent stopt en wacht op handmatig herstarten)
• Resource monitor — als een agent tijdens een uitvoering meer dan X tokens of meer dan Y euro verbruikt, automatische stop + alert

De kill-switch moet ook werken als de agent in een lus zit — hij mag dus niet uitsluitend geïmplementeerd zijn als een stap in de agent-loop. Het moet een extern mechanisme zijn (watchdog-proces, Kubernetes job termination, systemd unit stop).

Hoe u de verdediging in de praktijk opstapelt

Guardrails is geen één module — het is een combinatie van lagen die elkaar aanvullen. Geen enkele laag is honderd procent afdoende; hun combinatie verlaagt het risico dramatisch:

1. 1.Inputvalidatie → vangt injecties en onzin op vóór het LLM
2. 2.Action allowlist → beperkt wat de agent kan doen
3. 3.Uitvoeringslimieten → voorkomt ongecontroleerde kostenescalatie en oneindige lussen
4. 4.Sandbox → isoleert neveneffecten
5. 5.HITL approval → stopt high-risk acties vóór uitvoering
6. 6.Outputvalidatie → vangt laatste problemen op vóór impact
7. 7.Kill-switch → maakt het mogelijk alles te stoppen in een noodgeval

In een reëel deployment implementeert u niet alles tegelijk. Prioriteer op basis van het risico van de use-case: een agent voor intern zoeken in documenten heeft primair inputvalidatie en een outputfilter nodig. Een agent die bestellingen uitvoert of contracten verstuurt, heeft de volledige stack nodig.

Vóór elke productie-uitrol raden we red-teaming aan: een systematische poging om de agent te doorbreken met het eigen team. Guardrails die niemand heeft getest, zijn guardrails op papier.

Guardrails en observability — twee kanten van dezelfde medaille

Guardrails beschermen u tegen een incident. Observability vertelt u waarom het er bijna van gekomen is — en wat u moet verbeteren. Zonder tracing en logging op het niveau van elke stap van de agent heeft u geen data om guardrails in de loop van de tijd te verbeteren.

Platforms als LangSmith, Langfuse (self-hostable op Postgres + ClickHouse) of Arize Phoenix leggen voor elke agentuitvoering de node-by-node state diff vast. Wanneer guardrails ingrijpen, ziet u precies welke input dat heeft getriggerd — en u kunt beslissen of het ingrijpen correct was of een false positive.

Dit is een iteratieve cyclus: guardrails verzamelen incidenten → observability analyseert oorzaken → guardrails worden aangescherpt. Zonder deze cyclus stagneren guardrails en dekken ze met de groeiende scope van de agent steeds minder nieuwe vectoren af.

Meer over de human-in-the-loop-architectuur — en hoe u approval gates implementeert zonder dat de agent een trage chatbot wordt.

Veelgestelde vragen

Is één outputfilter aan het einde van de pipeline niet voldoende?

Nee. Een outputfilter vangt alleen slechte uitvoer op — maar de agent kan in de tussentijd tientallen acties hebben uitgevoerd met reële neveneffecten (API-calls, schrijfacties naar de DB, verstuurde e-mails). Guardrails moeten acties blokkeren vóór uitvoering, niet alleen tekst filteren daarna.

Is prompt injection een reële bedreiging of slechts een academisch probleem?

Een reële bedreiging in productiesystemen. De OWASP LLM Top 10 plaatst het al langere tijd op de eerste positie. De eerste gedocumenteerde zero-click aanval via geïnfecteerde externe inhoud (EchoLeak, Aim Security, 2025) toonde aan dat een aanvaller niet eens rechtstreeks met de agent hoeft te communiceren — het volstaat om een document te infecteren dat de agent inlaadt. Elke agent die externe inhoud verwerkt (websites, e-mails, bestanden van derden) is een potentiële vector.

LangGraph interrupt() — hoe werkt dat technisch?

interrupt() is een mechanisme dat de uitvoering van de graaf op een gedefinieerd punt pauzeert, de volledige toestand opslaat (checkpointing) en wacht op externe invoer. Die invoer kan binnenkomen via een API-call, webhook of UI. Na ontvangst van de invoer gaat de graaf verder vanaf het punt van onderbreking — niet vanaf het begin. Zo "herinnert" de agent de context vóór de goedkeuring en vervolgt hij naadloos daarna.

Hoe bepaalt u welke acties human approval nodig hebben?

Een eenvoudig kader: een actie heeft approval nodig als (1) hij onomkeerbaar is (verwijderen, deployen, verzenden), (2) hij financiële impact heeft boven een gedefinieerde drempel, (3) hij een externe partij raakt (klant, partner, toezichthouder), of (4) hij productiesystemen wijzigt. Interne leesbewerkingen, zoekopdrachten en het genereren van drafts hebben doorgaans geen approval nodig.

Hoe beïnvloeden guardrails de latency van de agent?

Inputvalidatie en de allowlist zijn praktisch gratis — milliseconden zonder LLM. Een HITL approval gate voegt latency toe afhankelijk van de snelheid van de menselijke reviewer — seconden tot minuten, maar alleen voor high-risk acties. Outputvalidatie (schemacheck, heuristieken) is ook snel. De enige potentieel langzamere laag is LLM-as-judge voor de faithfulness-check — maar ook daar volstaat een goedkoop model (Haiku-tier) voor verificatie, geen frontier-model.

Conclusie

*Guardrails zijn geen rem voor AI-agenten — het zijn de voorwaarden waaronder u agenten kunt vertrouwen in een productieomgeving. Zonder guardrails is elke agent een experiment, geen product. Als u overweegt AI-agenten in uw bedrijf in te zetten, of als u wilt controleren of bestaande guardrails afdoende zijn, beoordelen we graag uw concrete use-case en stellen we een verdedigingsopbouw voor die overeenkomt met het werkelijke risico.*