Prompt-injectie: hoe een document of website je AI-agent kan overnemen

Wat is prompt-injectie?

OWASP omschrijft het als een kwetsbaarheid waarbij invoer het gedrag of de uitvoer van een taalmodel op onbedoelde manieren verandert. De oorzaak zit in hoe een model werkt: het krijgt één lange tekst, waarin jouw opdracht, de systeeminstructies van de maker en alle inhoud die het moet lezen door elkaar staan, en het voorspelt wat er daarna hoort te komen. Het heeft geen ingebouwd besef van wie wat zei. Een zin in een document die eruitziet als een opdracht, kan daardoor als opdracht werken.

Dat is anders dan een gewone beveiligingsfout. Bij een klassieke aanval misbruikt iemand een fout in de code; hier misbruikt iemand de kern van hoe het model werkt, en die kun je niet wegprogrammeren. Daarom staat het bovenaan de lijst, en daarom draait de verdediging niet om het onmogelijk maken maar om het beperken van wat het kan aanrichten.

Het gevolg kan onschuldig zijn (een antwoord dat afwijkt) of ernstig: gegevens die naar buiten lekken, een handeling die niemand bedoelde, een beslissing die op een verborgen zin is gebaseerd. Hoe ernstig, hangt af van wat het model mag doen. Een model dat alleen praat, kan hooguit iets verkeerds zeggen. Een model dat e-mails kan versturen of bestanden kan verwijderen, kan dat op verzoek van een vreemde doen.

• Invoer die het gedrag van het model onbedoeld verandert.
• De oorzaak zit in hoe een model werkt: alles is tekst, niets heeft een afzender.
• De ernst hangt af van wat het model mag doen.

Wat is het verschil tussen directe en indirecte injectie?

Bij directe injectie is het de gebruiker zelf die met zijn invoer het gedrag van het model verandert, bewust of per ongeluk. Iemand typt iets in een chatvenster dat het model zijn regels laat vergeten. Dat is een risico voor wie een chatfunctie aanbiedt, en het is het minst gevaarlijke van de twee, omdat de aanvaller alleen zichzelf iets kan laten zien.

Bij indirecte injectie komt de instructie uit een externe bron die het model leest: een webpagina, een bestand, een e-mail, een bericht in een database. De gebruiker vraagt iets onschuldigs (“vat deze pagina samen”) en de pagina bevat een zin die het model iets anders laat doen. De gebruiker ziet de zin niet eens; hij kan wit op wit staan, in een opmerking in de code, of in een afbeelding. Dit is de gevaarlijke variant, want de aanvaller hoeft geen toegang tot jouw systeem te hebben. Hij hoeft alleen een pagina te schrijven die jouw agent op een dag leest.

OWASP noemt ook varianten die de detectie omzeilen. Instructies verspreid over meerdere stukken die pas samen een opdracht vormen. Opdrachten in andere talen of in een codering. Betekenisloze tekenreeksen die de veiligheidsregels van een model verstoren. En instructies in afbeeldingen naast onschuldige tekst. Het beeld dat daaruit ontstaat: de instructie kan overal in zitten wat het model leest.

• Direct: de gebruiker verandert zelf het gedrag; beperkte schade.
• Indirect: de instructie zit in wat het model leest; de aanvaller hoeft niet binnen te zijn.
• Varianten: verspreid, vertaald, gecodeerd, in een afbeelding.

Hoe ziet het eruit bij een agent die e-mail of webpagina's leest?

Stel dat je project een assistent heeft die de e-mails van een gebruiker leest en er samenvattingen van maakt, en die ook e-mails kan beantwoorden. Iemand stuurt die gebruiker een e-mail met, ergens onderin, een zin die tegen de assistent zegt dat hij de laatste tien berichten moet doorsturen naar een adres. De gebruiker vraagt om een samenvatting. De assistent leest de e-mail, ziet een instructie, en als hij e-mails mag versturen, doet hij het. Niemand heeft iets gehackt; de assistent deed wat er stond.

Of een agent die webpagina's bezoekt om informatie te verzamelen voor een rapport. Een van de pagina's bevat een voor mensen onzichtbare tekst die de agent vraagt om het gesprek tot dan toe in een webadres te zetten en dat adres te bezoeken. De agent doet het, en het gesprek staat in het logboek van de aanvaller. OWASP beschrijft precies deze twee scenario's, plus een sollicitant die zijn cv voorziet van tekst voor het AI-systeem dat cv's beoordeelt, en een document in een kennisbank dat is aangepast om misleidende antwoorden op te leveren.

De rode draad: er is een agent die leest én handelt, en de tekst die hij leest komt van iemand die je niet kent. Dat is de combinatie waar je op let.

• Een e-mailassistent die kan versturen, en een e-mail met een instructie onderin.
• Een agent die pagina's leest, en een pagina met onzichtbare tekst.
• De combinatie: lezen én handelen, met tekst van een onbekende.

Waarom is het niet met een filter op te lossen?

Omdat een instructie in gewone taal onbeperkt veel vormen heeft, en het model juist goed is in het begrijpen van al die vormen. Een filter dat zoekt naar bekende zinnen, mist de zin die anders is geformuleerd, in een andere taal staat, over twee alinea's verspreid is of in een afbeelding zit. Een filter dat streng genoeg is om alles te vangen, blokkeert ook de gewone inhoud die het model moet lezen. Filteren helpt als een van de lagen; het is geen oplossing.

Daar komt bij dat de grens tussen inhoud en instructie voor het model zelf niet bestaat. Je kunt het vragen om instructies in documenten te negeren, en dat helpt deels, maar het is een vraag aan hetzelfde systeem dat je probeert te beschermen. Een aanvaller die weet dat je dat vraagt, formuleert zijn zin zodat hij niet als instructie klinkt.

De conclusie van OWASP en van iedereen die er serieus naar kijkt: ga ervan uit dat het een keer lukt, en richt je systeem zo in dat het dan weinig kan aanrichten. Dat is een andere manier van denken dan bij de meeste beveiliging, en het is de manier die werkt.

• Een instructie in gewone taal heeft onbeperkt veel vormen.
• Het model zelf vragen om op te letten is een vraag aan het systeem dat je beschermt.
• Uitgangspunt: het lukt een keer; beperk wat het dan kan aanrichten.

Welke zeven maatregelen noemt OWASP?

Ten eerste: begrens het gedrag van het model in de systeeminstructies, met een duidelijke rol en duidelijke grenzen. Ten tweede: leg vast welke vorm de uitvoer moet hebben en controleer of hij daaraan voldoet, zodat een afwijkend antwoord opvalt. Ten derde: filter de invoer en de uitvoer op wat er niet in hoort. Ten vierde: geef het model niet meer rechten dan het voor zijn taak nodig heeft, en gebruik voor elke handeling een aparte, beperkte toegang.

Ten vijfde, en dit is de belangrijkste voor een maker: laat een mens goedkeuren voordat het model een handeling met gevolgen uitvoert. Iets versturen, iets verwijderen, iets betalen, iets buiten het systeem sturen: dat gebeurt pas na een klik van een mens die ziet wat er gaat gebeuren. Ten zesde: scheid externe inhoud van de opdracht en markeer hem als zodanig, zodat het model weet dat een document een document is en geen instructie. Ten zevende: test je systeem alsof je de aanvaller bent, regelmatig, en zeker na elke wijziging.

Geen van de zeven is op zichzelf genoeg. Samen maken ze het verschil tussen een agent die op een dag een e-mail doorstuurt naar een vreemde, en een agent die dan een verzoek aan jou voorlegt dat je verbaasd afwijst.

• Gedrag begrenzen, uitvoer vastleggen en controleren, in- en uitvoer filteren.
• Minste rechten, en een mens bij elke handeling met gevolgen.
• Externe inhoud scheiden en markeren, en testen als een aanvaller.

Wat doe je als maker met een AI in je project?

Begin met de vraag of je AI leest én handelt. Leest hij alleen jouw eigen tekst en geeft hij antwoorden, dan is het risico klein en zijn de eerste drie maatregelen genoeg. Leest hij tekst van anderen (gebruikers, webpagina's, bestanden, e-mail), dan komt de scheiding erbij: die tekst gaat het model in met een duidelijke markering dat het gegevens zijn, en de systeeminstructie zegt dat instructies in die gegevens niet gelden. Kan hij daarna ook handelen, dan komen de rechten en de menselijke goedkeuring erbij, zonder uitzondering.

Vertaal dat naar je code. Elke handeling die het model kan uitvoeren, is een functie met een eigen, zo klein mogelijke toegang. Een functie die alleen kan lezen. Een functie die alleen een concept kan opslaan. En geen enkele functie die verstuurt zonder dat er een mens tussen zit. Wat het model niet kan aanroepen, kan een verborgen instructie ook niet laten gebeuren. Dat is dezelfde regel als bij de rechten op je database: wie alleen zijn eigen gegevens mag zien, kan die van een ander niet lekken.

En test het. Zet zelf een instructie in een testdocument, laat je agent het lezen, en kijk wat hij doet. Als hij de instructie negeert of aan jou voorlegt, is dat een controle die de meeste projecten met een AI erin niet gehaald hebben. De veiligheidschecklist op deze site heeft er een punt voor.

• Leest én handelt je AI: dan gelden alle zeven maatregelen.
• Elke handeling een eigen functie met minimale toegang; versturen nooit zonder mens.
• Test met een eigen testdocument, en na elke wijziging opnieuw.

En de agent waarmee je zelf bouwt?

Dezelfde regels gelden voor de agent die jouw code schrijft. Een bouwagent leest documentatie, webpagina's, bestanden in je project en foutmeldingen, en hij kan bestanden schrijven, commando's uitvoeren en soms dingen versturen. Dat is precies de combinatie van lezen en handelen. Een webpagina met een verborgen instructie kan zo'n agent vragen om iets in je code te zetten wat er niet hoort, of om een bestand te lezen dat hij niet zou moeten lezen.

De verdediging is ook hier hetzelfde. Geef de agent alleen toegang tot de map van je project, en niet tot je hele computer. Laat handelingen met gevolgen (iets versturen, iets verwijderen, iets installeren van buiten) altijd eerst aan jou voorleggen; de meeste bouwagents hebben daar een stand voor. Lees wat de agent wil doen voordat je akkoord geeft, ook als het er saai uitziet. En wees argwanend als de agent ineens iets voorstelt wat je niet vroeg en wat uit een pagina of document lijkt te komen.

De agent is een gereedschap dat leest wat het tegenkomt. Wie dat weet, houdt de gevolgen bij zichzelf, en dat is het hele punt van dit artikel: niet bang zijn voor de tekst, maar zorgen dat de tekst niets kan doen zonder jou.

• Een bouwagent leest én handelt; dezelfde regels gelden.
• Alleen toegang tot de projectmap; gevolgen eerst aan jou voorleggen.
• Argwaan bij een voorstel dat je niet vroeg en dat uit een tekst lijkt te komen.

Bronnen

Nagelopen op 5 september 2026. De definitie, de scenario's en de zeven maatregelen komen uit de OWASP Top 10 for LLM Applications, versie 2025; de vertaling naar een maker is werkwijze. Dit artikel bevat bewust geen voorbeeldtekst van een aanval.

• OWASP, LLM01:2025 Prompt Injection

Verder lezen

Drie plekken die hierop aansluiten.