Verdediging tegen prompt injection voordat een agent handelt
Prompt injection doorbreekt in tests nog steeds filters, dus verdediging leunt op externe controles die een geslaagde aanval beperken.
U bent verantwoordelijk voor het bepalen welke acties een agent mag uitvoeren nadat een prompt-injectieaanval slaagt, wie die acties mag autoriseren, en welk bewijs aantoont waarom een actie werd toegestaan of gestopt. Dit is niet een vraag voor het model, maar voor uw werkstroom.
Een analyse van 11 november 2026 van verdediging tegen prompt injection voordat een agent handelt stelt dat prompt-injectiefilters in gecontroleerde tests nog steeds in 47 tot 89 procent van de aanvalsgevallen falen, afhankelijk van het model en de taak. De analyse gebruikt een juridische intakeworkflow als voorbeeld, waar een inkomende e-mail verborgen instructies kan bevatten die de agent naar een extern adres stuurt. In onze beoordeling betekent dit dat u niet kunt bouwen op de aanname dat het model een aanval onderschept. De werkstroom eromheen moet bepalen wat er gebeurt als die aanval slaagt.
Waar zit het restrisico als filters falen?
Restrisico is niet het percentage aanvallen dat een model weigert. Het is de verzameling acties die nog bereikbaar blijft nadat uw controles zijn ingesteld. Een leverancier die zegt dat een model 80 procent van de aanvallen blokkeert, geeft u een getal zonder verdedigbare reikwijdte op uw eigen verkeer, documenten en agents. Elke onderzoekspopulatie is anders.
De vraag die u moet stellen is niet hoe vaak het model nee zegt, maar wat er gebeurt bij de poging die er wel doorheen komt. Kan die een mailbox bereiken, een bestandsexport activeren, 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, moeten in deterministische applicatiecode zitten, niet in het model zelf. OWASP behandelt het model als een niet-vertrouwde gebruiker en stelt dat er binnen het model geen onfeilbare preventie bestaat.
- Scheiding van data en machtigingen — niet-vertrouwde inhoud blijft data wanneer het systeem scheidt wat het model mag lezen van wat het mag doen.
- Normalisatie voorafgaand aan matching — hoofdlettergebruik, Unicode-verwarringstekens, onzichtbare tekens en coderingen worden afgedekt voordat patroonherkenning plaatsvindt.
- Least privilege voor tools — elke tool krijgt alleen de rechten die nodig zijn voor die specifieke taak, niet meer.
- Onafhankelijke verificatie van argumenten — een tweede systeem dat geen model is, controleert of de toolargumenten geldig zijn voordat de tool draait.
- Menselijke poort voor onomkeerbare acties — verzenden, verwijderen, machtigingen wijzigen en exporteren stoppen totdat een persoon de exacte argumenten goedkeurt.
- Fail-closed op onclassificeerde invloed — wanneer het effect van een stuk content niet kan worden geïdentificeerd, weigert de workflow door te gaan.
Hoe scheidt u inhoud van instructies?
Een dossierbestand bevat een verborgen regel 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. De verzendtool vergelijkt de bestemming in code met een goedgekeurde lijst, vindt geen overeenkomst en weigert de oproep. De aanval beïnvloedt de tekst zonder de mogelijkheid te verkrijgen.
In een juridische intakeworkflow wordt inkomende e-mailtekst eerst genormaliseerd 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 delimiters die deze markeert als data die het model mag citeren of samenvatten. 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.
Welke vier factoren bepalen of een actie mag doorgaan?
Een vermoede injectie wordt bepaald door consequentie, omkeerbaarheid, datagevoeligheid en of het beïnvloedende bereik kan worden benoemd. Een geslaagde classificatie is geen toestemming om door te gaan.
- Bepaal of de actie omkeerbaar is — een leesactie binnen een reeds geautoriseerd bestand kan doorgaan met logging; verzenden, verwijderen en machtigingen wijzigen stoppen.
- Controleer of het beïnvloedende bereik kan worden geclassificeerd — vraag voor elke betwiste actie welk documentstuk, toolresultaat of beeldregio deze heeft beïnvloed; als dat niet kan worden bepaald, faalt de poort gesloten.
- Eis exacte argumenten, niet algemene intentie — goedkeuring van "verzend deze samenvatting" is geen goedkeuring van een ontvangerslijst die de beoordelaar nooit heeft gezien.
- Registreer onenigheid als bewijs — als onafhankelijke beoordelaars het oneens zijn, registreert de workflow waarom; onenigheid is informatie, geen ruis.
Hoe test u of uw controles werken?
U test door aanvalssucces en taaknut samen te meten op een herhaalbaar corpus, in plaats van te tellen hoe vaak het model nee zegt. Draai hetzelfde corpus eerst tegen een baseline-configuratie. Voeg daarna één laag tegelijk toe: normalisatie, contentfiltering, tools met minimale rechten, en onafhankelijke responsverificatie. Dit vertelt u welke laag het resultaat heeft verdiend, wat van belang is wanneer een latere wijziging die laag ongemerkt verwijdert.
Registreer zeven metrics voor elke run: aanvalssucces, fout-positieven, 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.
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.
Een release die alleen geblokkeerde aanvallen rapporteert, heeft geen veiligheid aangetoond. Het heeft mogelijk aangetoond dat het systeem werk blokkeert. In juridisch, medisch of onderzoekswerk bevatten legitieme documenten routinematig gebiedende taal, geciteerde bedreigingen of beschrijvingen van wandaden. Het maximaliseren van weigeringen kan het nut vernietigen.
Verificatielagen kunnen 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. Die grens duidelijk benoemen is onderdeel van een verdedigbare positie, geen toegeving. Dezelfde grens geldt voor privacycontroles: detectie is niet onmogelijkmaking. Uw eigen professionele oordeel bepaalt welke restrisico's aanvaardbaar zijn voor 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.
Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van NIST, arXiv, ACL Anthology en OWASP Gen AI Security Project.
Geschreven door
Tobias Lindqvist
Adversarial machine learning en de beveiligingseigenschappen van retrieval-systemen.