Verdediging tegen prompt injection voordat een agent handelt

Een agent die een document leest en vervolgens iets verstuurt, verwijdert of exporteert, beantwoordt niet zomaar een vraag. Hij oefent bevoegdheid uit, vaak op materiaal dat is geschreven door iemand buiten uw organisatie. Prompt injection-verdediging gaat daarom in de eerste plaats niet over het aanleren aan een model om een verdachte zin te herkennen. Het gaat erom te bepalen welke acties bereikbaar blijven als die zin werkt, wie ze mag autoriseren en welk bewijs laat zien waarom een actie werd toegestaan of gestopt. In onze analyse is dat de vraag waarop een CISO, jurist of bestuurder aanspreekbaar is: niet of een filter beweert aanvallen te blokkeren, maar of de omringende workflow een geslaagde aanval kan indammen.

Hoe vaak slaagt prompt injection nog?

Het slaagt vaak genoeg in gecontroleerde evaluaties om geen workflow te bouwen op de aanname dat het wordt onderschept. In 2025 rapporteerde de technische blog van NIST over het versterken van evaluaties van AI agent-hijacking dat het gemiddelde slagingspercentage van aanvallen over vijf indirecte prompt-injection-taken 57% was, oplopend tot 80% na herhaalde pogingen. Dat tweede cijfer is operationeel van belang. Een aanvaller heeft niet nodig dat de eerste formulering werkt als het systeem herhaalde pogingen, afwijkende bewoording of herhaalde blootstelling aan vergelijkbare inhoud toestaat.

Gepubliceerd slagingspercentage van prompt-injection

• InjecAgent, ReAct-stijl GPT-4 — Jaar: 2024; Wat werd gemeten: Kwaadaardige instructies in externe inhoud die de agent geacht werd te lezen; Gerapporteerd succes: 24 procent; 47 procent met een versterkende hacking-prompt
• NIST indirecte-injectie-evaluatie — Jaar: 2025; Wat werd gemeten: Gemiddelde over vijf indirecte prompt-injection-taken; Gerapporteerd succes: 57 procent; 80 procent na herhaalde pogingen
• NAACL Findings, acht verdedigingen — Jaar: 2025; Wat werd gemeten: Adaptieve aanvallen tegen indirecte prompt injection; Gerapporteerd succes: Consequent boven 50 procent; alle acht verdedigingen omzeild
• Agentic AI coding-editors — Jaar: 2025; Wat werd gemeten: Prompt injection tegen coding-editors; één scenario met commando-uitvoering; Gerapporteerd succes: 66,9 tot 84,1 procent; 89 procent van 314 payloads

De InjecAgent-studie evalueerde 30 LLM-agents en vond dat een ReAct-stijl GPT-4-agent een geïnjecteerde instructie opvolgde in 24% van de aanvalsgevallen, oplopend tot 47% met een afzonderlijke versterkende hacking-prompt. De studie uit 2025 van agentic AI coding-editors mat slagingspercentages tussen 66,9% en 84,1%, en in één scenario activeerden 89% van 314 aanvals-payloads commando-uitvoering.

Deze populaties, modellen en taken verschillen, dus ze mogen niet worden samengevoegd tot één organisatorisch percentage. Elke noemer is de eigen verzameling gevallen van de studie, niet uw verkeer, uw documenten of uw agents. Een leverancier die ze middelt tot één opvallend percentage geeft u een getal zonder verdedigbare reikwijdte.

Restrisico is niet het aanvalspercentage. Het is de verzameling consequente acties die nog bereikbaar is nadat uw controles zijn ingesteld.

Die definitie verandert het inkoopgesprek. In plaats van te vragen hoe vaak een model een kwaadaardige instructie weigert, vraagt u wat er gebeurt bij de poging die er wel doorheen komt. Kan die een mailbox, een bestandsexport of een rechtenwijziging bereiken, of alleen een concept dat een persoon beoordeelt? Het antwoord hangt af van controles die om het model heen zitten, niet in de prompt ervan.

Welke controles horen buiten het model thuis?

De controles die rechten, bestemmingen en onomkeerbare acties bepalen, horen buiten het model thuis, in deterministische applicatiecode. De OWASP-richtlijn over prompt injection beveelt least privilege, human-in-the-loop-controles, vertrouwensgrenzen en output-validatie aan, behandelt het model als een niet-vertrouwde gebruiker en stelt dat er binnen het model zelf geen onfeilbare preventie bestaat. Dat kader is het juiste uitgangspunt voor verantwoord ontwerp.

De onderstaande pipeline laat zien waar die controles zitten ten opzichte van het model.

Een controlepipeline in zeven stappen

1. Markeer alles wat binnenkomt als niet-vertrouwde data. Dat omvat de gebruikersprompt, opgehaalde documenten, webpagina's, e-mails, tooluitvoer en eerdere gespreksbeurten. Niets ervan erft bevoegdheid doordat het in dezelfde sessie binnenkwam.

1. Scheid instructies structureel van inhoud. Houd systeem- en ontwikkelaarsinstructies in getypeerde velden die externe inhoud niet kan beschrijven. Omsluit aangeleverd materiaal in expliciete scheidingstekens zodat de workflow, en niet de tekst, het onderscheid draagt.

1. Normaliseer voordat u filtert. Standaardiseer hoofdletters, Unicode, confusables, onzichtbare tekens, witruimte en encoderingen, en begrens vervolgens de invoerlengte. Matchen tegen ruwe tekst laat triviale obfuscatie langs het filter glippen.

1. Verleen alleen de tools die de taak nodig heeft. Controleer bestemming, rechten en datascope in applicatiecode voor elke voorgestelde aanroep. In dit model wordt least-privilege runtime-controle voor AI-agents een autorisatiebeslissing in plaats van een promptinstructie.

1. Houd consequente acties tegen voor een persoon. Verzenden, verwijderen, rechtenwijzigingen en vertrouwelijke exports wachten op menselijke goedkeuring van exact de voorgestelde actie.

1. Valideer argumenten en output. Controleer toolargumenten tegen een schema, scan op gevoelige waarden en toets of elke bewering in een concept binnen de aangeleverde context blijft. Log het volledige beslissingsspoor.

1. Stop wanneer het bewijs onvolledig is. Als onafhankelijke beoordelaars het oneens zijn of de basis voor een actie niet kan worden vastgesteld, laat de poort de actie niet door.

Deze stappen sluiten aan bij de bredere secure-by-design-patronen voor AI-agents van Cyndra, die nuttige context bieden voor teams die agent-rechten vanaf het begin structureren in plaats van ze achteraf in te bouwen.

De val van het tweede model

Een tweede model vragen om een actie goed te keuren creëert geen autorisatiegrens als hetzelfde onbeperkte toolpad open blijft. U heeft beoordeling toegevoegd, maar de uiteindelijke beslissing berust nog steeds op de gehoorzaamheid van het model. Onafhankelijke beoordelaars kunnen een voorgestelde actie betwisten en onenigheid aan het licht brengen, wat waardevol bewijs is. Een policy engine die geen model is, zou nog steeds de laatste poort moeten zijn.

Stel dat een dossierbestand een verborgen regel bevat waarin de agent wordt gevraagd het bestand naar een extern adres te mailen. De conceptsamenvatting kan er volkomen behulpzaam uitzien. De verdediging hangt niet af van het feit dat het model de regel opmerkt, omdat de verzendtool de bestemming in code vergelijkt met een goedgekeurde lijst, geen overeenkomst vindt en de oproep weigert. De aanval kan de tekst beïnvloeden zonder de mogelijkheid te verkrijgen.

Hoe moet niet-vertrouwde inhoud data blijven?

Niet-vertrouwde inhoud blijft data wanneer het systeem scheidt wat het model mag lezen van wat het mag doen. Screening en labels verminderen voor de hand liggende instructiesmokkel, maar de belangrijkste grens is de scheiding van data en machtigingen. De OWASP LLM Prompt Injection Prevention Cheat Sheet identificeert opgehaalde documenten, RAG-context, tooloutputs, webpagina's, e-mailtekst en gespreksgeschiedenis als kanalen die instructies kunnen bevatten, en beveelt aan om zowel de gebruikersprompt als de opgehaalde context te screenen voordat het primaire model ze verwerkt.

Dit diagram toont die scheiding tussen de datalaag en de machtigingenlaag.

Twee uitgewerkte gevallen

In een juridische intakeworkflow wordt een inkomende e-mailtekst eerst genormaliseerd, waarbij hoofdlettergebruik, Unicode-verwarringstekens, onzichtbare tekens, witruimte en coderingen worden afgedekt, en vervolgens wordt de lengte begrensd voordat er patroonherkenning wordt uitgevoerd. Als een regel leest als een instructie aan de agent, verwijdert de workflow deze niet. Deze bewaart de regel in een bewijslogboek met het oorspronkelijke bereik, zodat een beoordelaar later precies kan zien wat er is binnengekomen en wat het systeem daaraan heeft gedaan.

In een opgehaalde medische PDF wordt de relevante passage omhuld met delimiter spotlighting die deze markeert als data die het model mag citeren, samenvatten of vergelijken met andere bronnen. Het is geen nieuwe taakdefinitie. Als de passage bewoordingen bevat die lijken op een opdracht, kan het model die bewoordingen rapporteren als inhoud. Het kan die bewoordingen niet promoveren tot een tooloproep.

Deze patronen sluiten direct aan op de risico's die worden beschreven in onze analyse van verborgen AI-instructies in externe documenten en retrieval, waar de drager eruitziet als gewoon werkmateriaal.

De volgende doorloop illustreert hoe instructieachtige inhoud zich kan verbergen in routinemateriaal dat een agent moet verwerken.

Teststrings die de moeite waard zijn om te bouwen

Beschrijf testgevallen op basis van structuur in plaats van herbruikbare payloads te verspreiden. Drie patronen dekken veelvoorkomende smokkelroutes:

• Verborgen instructie: een instructie geplaatst na een lange, onschuldige samenvatting in een aangeleverd document.
• Versluierde instructie: dezelfde instructie met ongebruikelijke Unicode-spatiëring of verwarringstekens.
• Escalatie via toolresultaat: een toolrespons die de agent vraagt om zijn eigen bestandstoegang te verruimen.

Eén hiaat blijft slecht opgelost. Impliciete passages en beeldinhoud kunnen het modelgedrag verschuiven zonder enige expliciete instructie te bevatten, en detectoren presteren daar slecht op omdat er geen opdrachtzin is om te matchen. Behandel die invloed als ongeclassificeerd. De poort faalt gesloten in plaats van te gokken.

Een label handhaaft geen vertrouwensgrens. Code die machtigingen controleert voordat een tool draait, is wat deze handhaaft.

Als build tickets is de eis concreet: getypeerde niet-vertrouwde velden voor elke externe bron, normalisatie voorafgaand aan matching, en geen tooloproep waarvan de argumenten alleen afkomstig zijn uit ongemarkeerde externe tekst.

Wanneer moet de workflow gesloten falen?

De workflow moet gesloten falen wanneer een voorgestelde actie onomkeerbaar of bevoorrecht is, of wordt beïnvloed door inhoud waarvan het effect niet kan worden geïdentificeerd. Een vermoede injectie wordt bepaald door consequentie, omkeerbaarheid, datagevoeligheid en of het beïnvloedende bereik kan worden benoemd, niet door een enkele weigeringsscore. De 2025 NAACL Findings-studie testte acht verdedigingen tegen indirecte prompt injection en omzeilde ze allemaal met adaptieve aanvallen, waarbij de aanvalssuccespercentages consistent boven de 50% lagen. Een geslaagde classificatie is daarom geen toestemming om door te gaan.

Deze vergelijking zet de vier factoren uiteen die de beslissing bepalen.

Stoppen, escaleren of toestaan na een vermoede injectie

• Lezen binnen een reeds geautoriseerd bestand — Gevoeligheid en omkeerbaarheid: Omkeerbaar, geen nieuwe bestemming; Beslissing: Toestaan indien gelogd en geen geheim het bereik verlaat; Wat te registreren: Actie, bestandsbereik, tijdstempel
• Concept dat alleen aangeleverde tekst citeert — Gevoeligheid en omkeerbaarheid: Geen tooloproep; Beslissing: Escaleren voor menselijke beoordeling; Wat te registreren: Geciteerd bereik en openstaande vragen
• Verzenden, verwijderen, wijziging van machtigingen of vertrouwelijke export — Gevoeligheid en omkeerbaarheid: Onomkeerbaar of bevoorrecht; Beslissing: Stoppen totdat een persoon de exacte argumenten goedkeurt; Wat te registreren: Argumenten die ter goedkeuring zijn voorgelegd
• Beoordelaars zijn het oneens of het beïnvloedende bereik kan niet worden benoemd — Gevoeligheid en omkeerbaarheid: Onzekerheid, waaronder impliciete of beeldinvloed; Beslissing: Gesloten falen; Wat te registreren: Onenigheid en ontbrekend bewijs

Een omkeerbare leesactie binnen een reeds geautoriseerd bestand kan doorgaan met logging, mits er geen nieuwe bestemming en geen geheim bij betrokken zijn. Een concept dat niet-vertrouwde tekst citeert maar geen tooloproep voorstelt, gaat naar een persoon, omdat een citaat nog steeds een gecorrumpeerd feit kan dragen in een stuk, een klinische notitie of een bestuursdocument.

Verzenden, verwijderen, machtigingen wijzigen, vertrouwelijk materiaal exporteren of een nieuwe tool aanroepen stopt totdat een persoon de exacte argumenten goedkeurt, niet een algemene beschrijving van de intentie. Goedkeuring van verzend deze samenvatting is geen goedkeuring van een ontvangerslijst die de beoordelaar nooit heeft gezien.

Als onafhankelijke beoordelaars het oneens zijn, het bronbereik niet kan worden geïdentificeerd, of een afbeelding of impliciete passage de actie mogelijk stuurt, faalt de poort gesloten en registreert waarom. Onenigheid is bewijs, geen ruis die weggemiddeld moet worden.

Een laag restpercentage kan nog steeds onaanvaardbaar zijn in juridisch, klinisch, compliance- of politiek werk. Eén ongeautoriseerde verzending of één beschadigd feit in een document waarop wordt vertrouwd, telt mee, ook wanneer het volledige doel van de aanvaller mislukt. Gedeeltelijke compromittering is geen bijna-misser als het gedeeltelijke resultaat terechtkomt in een vastlegging waarop iemand handelt.

Voor auditdoeleinden moet elke beslissing met een poort vijf velden achterlaten: de voorgestelde actie, de toolargumenten, het stuk content waarop is vertrouwd, de uitkomst van de beoordelaar, en of de poort de actie heeft gestopt of vrijgegeven. Zonder die velden kunt u na een incident geen verantwoording reconstrueren. U kunt alleen beweren dat er een controle bestond.

Hoe test u zonder alleen weigeringen te tellen?

U test door aanvalssucces en taaknut samen te meten, op een herhaalbaar corpus, in plaats van te tellen hoe vaak het model nee zegt. De evaluatieaanpak die wordt beschreven in de multi-layer prompt-injection defense benchmark bouwt cases op rond directe instructie-override, kwaadaardige opgehaalde content, contextmanipulatie, data-exfiltratie en cross-context contaminatie, voegt vervolgens stapsgewijs controles toe en registreert zowel beveiligings- als taakbehoudsuitkomsten. Rapporteer resultaten uit uw eigen corpusruns, niet de kopcijfers uit de benchmark van iemand anders.

Bouw het corpus op in vijf families

Neem binnen elke familie verhulling op zoals Unicode-confusables, onzichtbare tekens, gecodeerde kandidaten en instructie-achtige tekst in gewone documenten. Voeg ook onschuldige maar invloedrijke passages toe. Zonder die blijft overblokkering onzichtbaar totdat een legitieme gebruiker er in productie tegenaan loopt.

Draai hetzelfde corpus eerst tegen een baseline-configuratie. Voeg daarna één laag tegelijk toe: normalisatie en lengtegrenzen, contentfiltering, hiërarchische instructieverwerking, tools met minimale rechten, en onafhankelijke responsverificatie. Alles tegelijk toevoegen vertelt u het gecombineerde resultaat, maar niet welke laag dat heeft verdiend, wat van belang is wanneer een latere wijziging de effectieve laag ongemerkt verwijdert. Deze gelaagde methode ondersteunt ook gestructureerd red teaming van prompt-injection-ketens van AI-agents over echte toolpaden.

Testcasefamilies en release-metrics

• Directe instructie-override — Op te bouwen testcase: Gebruikersbeurt vraagt de agent om zijn opdracht te negeren en beperkte content prijs te geven; Te registreren metric: Aanvalssuccespercentage
• Kwaadaardige opgehaalde content — Op te bouwen testcase: Instructie geplaatst na een lange onschuldige samenvatting in een aangeleverde PDF; Te registreren metric: Aanvalssuccespercentage en ongeautoriseerde tool-aanroepen
• Contextmanipulatie — Op te bouwen testcase: Eerdere beurt die de scope van de taak herdefinieert; Te registreren metric: Voltooiing van onschuldige taak
• Data-exfiltratie — Op te bouwen testcase: Opgehaalde tekst vraagt om een bestand naar een extern adres te sturen; Te registreren metric: Blootstelling van geheimen en ongeautoriseerde tool-aanroepen
• Cross-context contaminatie — Op te bouwen testcase: Feit uit het ene dossier geïntroduceerd in een ander dossier; Te registreren metric: Onenigheid bij de beoordelaar en fout-positiefpercentage

Registreer zeven metrics voor elke run: aanvalssuccespercentage, fout-positiefpercentage, voltooiing van onschuldige taken, ongeautoriseerde tool-aanroepen, blootstelling van geheimen, onthouding en onenigheid bij de beoordelaar. Elke metric vangt een fout op die de andere missen. Een configuratie kan een sterk weigeringspercentage laten zien en toch lekken via een tool-aanroep die nooit is geweigerd, omdat niemand er een vraag aan stelde die het als aanval herkende.

Eenvoudige woordfilters zijn op zichzelf niet voldoende, omdat normalisatiekeuzes bepalen wat het filter überhaupt kan zien. Maar de tegenovergestelde fout is net zo reëel. Het maximaliseren van weigeringen kan het nut vernietigen in juridisch, medisch of onderzoekswerk, waar legitieme documenten routinematig gebiedende taal, geciteerde bedreigingen of beschrijvingen van wandaden bevatten.

Een release die alleen geblokkeerde aanvallen rapporteert, heeft geen veiligheid aangetoond. Het heeft mogelijk aangetoond dat het systeem werk blokkeert.

Sluit elke release-cyclus af met een korte checklist: beveiligings- en nutscijfers naast elkaar, de gebruikte corpusversie, en de specifieke laag die sinds de vorige run is toegevoegd. Als het nut daalde terwijl het aanvalssucces nauwelijks bewoog, moet die afweging zichtbaar zijn voor de persoon die verantwoordelijk is voor het accepteren ervan, op schrift, vóór uitrol.

Wat moet u eisen voordat een agent handelt?

Eis vier dingen op schrift voordat een agent handelt op niet-vertrouwde content in een professionele workflow. Ten eerste: niet-vertrouwde content die structureel gescheiden wordt gehouden van instructies, zodat aangeleverd materiaal de taak niet kan herdefiniëren. Ten tweede: toolrechten die worden afgedwongen in applicatiecode, zodat een gemanipuleerde modeluitvoer zijn eigen bevoegdheid niet kan verruimen. Ten derde: een menselijke poort voor onomkeerbare of bevoorrechte acties, met goedkeuring gegeven op exacte argumenten. Ten vierde: een release-vastlegging die aanvalssucces naast taakvoltooiing, fout-positieven en onthouding toont.

De bewijsvraag

Vraag voor elke betwiste actie welk documentstuk, toolresultaat of beeldregio deze heeft beïnvloed, en wat er gebeurt wanneer die invloed niet kan worden geclassificeerd. Als het antwoord is dat de workflow toch doorgaat, heeft de controleomgeving een benoemd gat. Het verdedigbare antwoord is fail-closed en het eindoordeel bij de gebruiker laten.

Een verificatielaag kan naast de poort staan in plaats van deze te vervangen. Verificatie ondersteunt beoordeling en controle. Het waarborgt geen juistheid, compliance, of dat een injectie wordt opgevangen.

Dezelfde grens geldt voor privacycontroles. Het detecteert niet elke indirecte identifier en kan heridentificatie niet onmogelijk maken. Die grens duidelijk benoemen is onderdeel van een verdedigbare positie, geen toegeving.

Die maatregelen beschermen de workflow rondom het model. Ze maken van geen enkele afzonderlijke modeluitvoer een vertrouwde instructie.

Meer artikelen over dit onderwerp zijn verzameld in het overzicht Agentic AI en AI-agents.

Bronnen: Cijfers over aanvalssucces worden toegeschreven aan NIST's agent hijacking-blog uit 2025, de InjecAgent-benchmark, een studie uit 2025 over agentische code-editors en NAACL Findings; richtlijnen voor controles worden toegeschreven aan OWASP's prompt injection-richtlijnen en de operatorgids van Cyndra.