Prompt injection bij AI: werking en verdediging

Prompt injection kan een AI-toepassing instructies laten volgen die afkomstig zijn uit gebruikersinvoer of externe inhoud. Lees hoe deze aanvallen werken, waarom toegangsrechten en toolgebruik het risico vergroten en welke verdedigingslagen de impact kunnen beperken.

Hoe prompt injection een AI-model beïnvloedt

Een AI-model verwerkt instructies en gegevens grotendeels als tekst. Prompt injection maakt misbruik van die eigenschap door tekst aan te bieden die het model probeert te laten afwijken van de opdracht of veiligheidsregels die de toepassing heeft opgesteld. Een gebruiker kan bijvoorbeeld vragen om vertrouwelijke informatie te tonen, maar dezelfde instructie kan ook verborgen zitten in een document dat het model moet samenvatten. Het model ziet dan zowel de bedoelde taak als de aanvallende tekst in zijn context.

Bij directe prompt injection voert iemand de instructie bewust in via een chatvenster, formulier of API-verzoek. Bij indirecte prompt injection staat de instructie in externe inhoud, zoals een webpagina, e-mail, PDF of ticket. De gebruiker hoeft die tekst niet zelf te schrijven of zelfs te zien. Zodra een AI-agent de inhoud ophaalt en verwerkt, kan de instructie invloed krijgen op de volgende stap.

Dit is geen klassieke software-injectie waarbij een parser een codefragment uitvoert. Een taalmodel interpreteert waarschijnlijkheden en context; het kent niet vanzelf een harde grens tussen betrouwbare opdrachten en onbetrouwbare tekst. Daardoor zijn formuleringen, rolverdeling en afbakening nuttig, maar vormen ze op zichzelf geen beveiligingsgrens. De risico’s hangen vooral af van wat de toepassing het model laat lezen en welke handelingen het daarna kan uitvoeren.

Directe en indirecte prompt injection verschillen in aanvalspad

Een directe aanval begint bij invoer die de gebruiker zelf aanlevert. Denk aan een prompt die vraagt om interne systeemprompts te onthullen, een moderatieregel te negeren of een tool aan te roepen. In een publieke chatbot kan de mogelijke schade beperkt blijven tot ongewenste antwoorden. In een toepassing met accountgegevens, bedrijfsdocumenten of schrijfbevoegdheden kan dezelfde poging leiden tot blootstelling van informatie of acties onder het account van de gebruiker.

Indirecte aanvallen zijn lastiger zichtbaar, omdat de aanvallende tekst kan meekomen uit een bron die op zichzelf legitiem lijkt. Een webpagina kan bijvoorbeeld instructies bevatten die alleen bedoeld zijn voor een AI-agent, of een document kan verborgen tekst bevatten die buiten beeld blijft voor de menselijke lezer. Als een agent e-mail doorzoekt, websites bezoekt of bestanden samenvat, kan zulke inhoud onderdeel worden van de modelcontext en de uitvoering beïnvloeden.

De verdediging verschilt per aanvalspad. Bij directe invoer zijn rate limits, misbruikdetectie en beperkingen op beschikbare functies relevant. Voor indirecte invoer moet de toepassing ook bronnen beoordelen, opgehaalde tekst als onbetrouwbaar behandelen en acties rond die tekst begrenzen. Een allowlist voor domeinen verkleint het aanvalsoppervlak, maar voorkomt niet dat een toegestane bron gecompromitteerd is. Het is daarom belangrijk om niet alleen te kijken naar wie de prompt verstuurt, maar ook naar de herkomst van alle inhoud die in de context terechtkomt.

Waarom een prompt geen toegangscontrole vervangt

Een systeemprompt kan het model instrueren om bepaalde informatie niet te delen. Dat is nuttig voor gedrag en consistentie, maar geen betrouwbare vervanging voor autorisatie in de applicatie. Als een model toegang krijgt tot gegevens die de gebruiker niet mag zien, kan een aanvaller proberen het model die gegevens te laten ophalen, samenvatten of indirect prijsgeven. Een instructie als “deel nooit vertrouwelijke informatie” verandert niet welke data technisch beschikbaar is.

Pas toegangscontrole toe voordat gegevens aan het model worden aangeboden. Filter zoekresultaten op de identiteit, rol en rechten van de gebruiker en geef alleen relevante records door. Bij een retrievalsysteem betekent dit dat toegangsregels niet uitsluitend in de prompt of in een documentmetadata-veld mogen zitten: de zoeklaag moet de bevoegdheden daadwerkelijk afdwingen. Controleer die rechten opnieuw wanneer een agent een actie uitvoert, vooral als de identiteit of context tijdens een workflow kan veranderen.

Ook toolrechten verdienen afzonderlijke grenzen. Een samenvattingsfunctie heeft doorgaans geen reden om e-mail te versturen of bestanden te verwijderen. Geef modellen daarom geen algemene serviceaccountrechten als een beperkte functie volstaat. Gebruik waar mogelijk aparte identiteiten per taak, beperk toegang tot specifieke objecten en registreer welke actor een actie initieerde. De afweging is dat fijnmazige autorisatie meer ontwerp- en beheerwerk vraagt. Die complexiteit is echter beter beheersbaar dan een model dat met één brede bevoegdheid uiteenlopende gegevens kan lezen en muteren.

AI-agents met tools vergroten de impact van aanvallen

Een model dat alleen tekst genereert, kan verkeerde informatie produceren, maar een agent kan ook tools aanroepen. Denk aan een browser, database, bestandssysteem, agenda of API voor klantbeheer. Prompt injection wordt daardoor een ketenrisico: aanvallende tekst beïnvloedt het model, het model kiest een actie en een tool voert die actie uit met de rechten van de toepassing. De schade ontstaat dan niet alleen in het antwoord, maar in de systemen waarmee de agent verbonden is.

Beperk toolgebruik per taak en maak functies zo specifiek mogelijk. Een tool die alleen een conceptbericht aanmaakt, heeft minder impact dan een algemene functie die berichten kan verzenden, verwijderen en doorsturen. Scheid lezen en schrijven waar dat kan, valideer toolargumenten tegen een schema en weiger parameters buiten de verwachte waarden. Laat gevoelige of onomkeerbare acties niet automatisch doorgaan op basis van alleen modeloutput. Een expliciete bevestiging door een bevoegde gebruiker kan een extra controle vormen, mits duidelijk is welke actie en gegevens worden bevestigd.

Een veelvoorkomende ontwerpfout is ervan uitgaan dat het model een tool alleen gebruikt wanneer de gebruiker dat bedoelt. Een indirecte instructie in een opgehaald document kan juist proberen de agent te laten afwijken. Behandel daarom toolaanroepen als onbetrouwbare verzoeken: controleer ze buiten het model en pas dezelfde autorisatie toe als bij een gewone API-aanroep. Logging moet zowel de aanleiding als de uitgevoerde actie vastleggen, zonder daarbij onnodig gevoelige promptinhoud breed beschikbaar te maken.

Externe documenten veilig verwerken met retrieval en RAG

Retrieval-augmented generation (RAG) voegt relevante passages uit een kennisbank toe aan de context van een taalmodel. Dat maakt antwoorden specifieker, maar introduceert ook inhoud die niet door de toepassing zelf is geschreven. Een document kan verouderde procedures, foutieve instructies of doelbewust geplaatste prompt injection bevatten. Als opgehaalde tekst zonder verdere controle als gezaghebbend wordt behandeld, kan de toepassing die instructies verwarren met de opdracht van de gebruiker.

Leg de herkomst van documenten vast en beheer toegang bij het ophalen, niet alleen bij het indexeren. Verwijderde of gewijzigde documenten moeten ook uit indexen en caches verdwijnen; anders kan oude inhoud antwoorden blijven beïnvloeden. Beperk de opgehaalde context tot passages die nodig zijn voor de taak en gebruik metadata om bronnen, eigenaar en vertrouwelijkheidsniveau te onderscheiden. Een vertrouwde interne bron is niet automatisch veilig: accounts kunnen worden misbruikt en documenten kunnen door gebruikers worden aangepast.

Instructies om opgehaalde tekst als data te behandelen kunnen de interpretatie sturen, maar bieden geen harde isolatie. Ontwerp daarom ook voor het geval dat het model de tekst toch volgt. Laat documenten niet rechtstreeks tools activeren, beperk welke gegevens een antwoord mag bevatten en controleer uitvoer op gevoelige informatie. Voor processen met hoge impact kan menselijke beoordeling nodig zijn voordat inhoud wordt gepubliceerd of als besluit wordt gebruikt. Die controle verhoogt de operationele belasting, dus reserveer haar vooral voor taken waarbij een fout aantoonbare gevolgen heeft.

Invoer- en uitvoervalidatie als verdedigingslaag

Validatie helpt om onverwachte invoer en modeloutput buiten de toegestane grenzen te houden. Aan de invoerkant kunnen bestandstypecontroles, limieten op omvang, URL-beperkingen en detectie van verdachte patronen het aanvalsoppervlak verkleinen. Zulke filters zijn geen volledige prompt-injectiondetector: aanvallers kunnen instructies anders formuleren, verbergen in opmaak of verspreiden over meerdere passages. Een filter dat op trefwoorden vertrouwt, kan bovendien normale inhoud blokkeren terwijl een nieuwe aanval onopgemerkt blijft.

Valideer modeloutput op basis van het gebruiksdoel. Als een model een JSON-object moet teruggeven, controleer dan de structuur, toegestane velden en waardebereiken voordat een ander onderdeel die gegevens verwerkt. Behandel tekst die naar een browser, database of shell gaat volgens de regels van die bestemming; modeloutput is geen veilige code of query. Gebruik parametrisatie en bestaande veilige API’s in plaats van gegenereerde opdrachten rechtstreeks uit te voeren. Een parser kan vaststellen dat output syntactisch geldig is, maar niet dat de voorgestelde actie inhoudelijk toegestaan is.

Combineer syntactische validatie daarom met beleidscontroles. Controleer bijvoorbeeld of een ontvanger binnen een toegestane lijst valt, of een record toegankelijk is en of een bedrag of statuswijziging binnen de bevoegdheid van de gebruiker valt. Bij twijfel kan de toepassing de actie weigeren of om menselijke beoordeling vragen. De juiste controle hangt af van de gevolgen van een fout: strenge regels beperken risico, maar kunnen legitieme variatie in gebruikersvragen ook afwijzen. Meet beide soorten fouten en pas regels aan op basis van concrete testgevallen.

Meerdere verdedigingslagen ontwerpen rond het model

Prompt injection is niet met één promptregel of detectiemodel op te lossen. Een effectieve aanpak verdeelt controles over de volledige keten: gebruikersinterface, gegevensopslag, retrieval, modelaanroep, tooluitvoering en publicatie van het resultaat. Elke laag moet uitgaan van de mogelijkheid dat een eerdere laag is misleid. Zo kan de applicatie de toegang tot documenten al beperken voordat een model ze ziet, en kan een toolserver een ongeldige actie weigeren, zelfs wanneer het model die actie overtuigend formuleert.

Een praktische keuze is om modelgedrag en beveiligingsbeleid van elkaar te scheiden. Het model kan een verzoek classificeren of voorstellen doen, terwijl gewone programmatuur bepaalt of de gebruiker bevoegd is en of een actie is toegestaan. Gebruik waar mogelijk expliciete toestandsmachines voor workflows met meerdere stappen, zodat het model niet zelf de volgorde en rechten van elke stap bepaalt. Dit vraagt meer applicatielogica en kan spontane interacties beperken, maar maakt gedrag beter te testen en te auditen.

Ook foutafhandeling hoort bij het ontwerp. Als een model, filter of externe dienst niet beschikbaar is, mag de toepassing niet ongemerkt terugvallen op ruimere bevoegdheden of een minder gecontroleerde route. Kies expliciet tussen weigeren, uitstellen en beperkte functionaliteit aanbieden. Leg vast welke controles zijn uitgevoerd en welke niet, zodat operators afwijkingen kunnen onderzoeken. Een technische maatregel is pas waardevol wanneer duidelijk is waar hij wordt afgedwongen, welke fout hij moet voorkomen en wat het systeem doet als die controle niet kan worden uitgevoerd.

Prompt injection testen en incidenten analyseren

Beveiligingstests moeten verder gaan dan bekende jailbreakzinnen. Test directe en indirecte aanvallen, verschillende talen, lange contexten, verborgen tekst in documenten en instructies die over meerdere bronnen zijn verdeeld. Neem ook scenario’s op waarin het model een tool gebruikt, een bron citeert of gegevens uit meerdere gebruikerssessies kan combineren. Het doel is niet alleen te meten of het model een verdachte prompt herkent, maar vooral of de toepassing voorkomt dat een aanvaller ongeoorloofde data bereikt of een actie laat uitvoeren.

Maak tests representatief voor de eigen gegevens en functies. Een prompt die een klantenservicemedewerker een e-mail laat samenvatten, heeft andere risico’s dan een agent die databasegegevens kan wijzigen. Controleer zowel ongewenste toegang als onterechte blokkades: een defensie die alle documenten weigert, voorkomt mogelijk aanvallen maar maakt de functie onbruikbaar. Herhaal tests na wijzigingen in prompts, modellen, toolrechten, retrievalinstellingen en documentverwerking. Een modelupdate kan gedrag veranderen zonder dat de applicatiecode is aangepast.

Monitoring kan patronen zichtbaar maken die tests missen, zoals herhaalde pogingen om verborgen instructies te laten uitvoeren of ongebruikelijke combinaties van toolaanroepen. Registreer voldoende context om beslissingen te reconstrueren, maar minimaliseer opslag van persoonsgegevens en geheimen. Bij een incident zijn herkomst van inhoud, gebruikte modelcontext, autorisatiebeslissingen en uitgevoerde tools relevante sporen. Analyseer welke controle faalde en pas de grens in de applicatie aan; alleen een nieuwe promptregel toevoegen kan dezelfde aanvalsvector ongemoeid laten.

Veelgestelde vragen

Wat moet een organisatie doen na een vermoedelijk prompt-injectionincident?

Na een vermoedelijk prompt-injectionincident moet een organisatie eerst de mogelijke schade beperken en daarna vaststellen welke gegevens en acties zijn geraakt. Schakel verdachte agentfuncties zo nodig tijdelijk uit, trek betrokken tokens of sessies in en voorkom dat dezelfde workflow verdere acties uitvoert. Bewaar relevante logs en tijdstempels voordat systemen worden opgeschoond.

• Controleer welke gegevens zijn ingezien, gewijzigd of verstuurd.
• Onderzoek de gebruikte bron, prompt en toolaanroepen.
• Herstel wijzigingen en informeer betrokkenen volgens het incidentbeleid.
• Pas tests en beveiligingsmaatregelen aan op basis van de bevindingen.

Hoe meet je of een AI-toepassing bestand is tegen prompt injection?

Je meet de weerbaarheid door vooraf vastgelegde aanvallen uit te voeren en te controleren of de toepassing ongewenste gegevens of acties daadwerkelijk tegenhoudt. Alleen meten of het model een aanval herkent, is onvoldoende: een weigering in het antwoord helpt niet als een tool ondertussen toch een actie uitvoert.

• Test zowel geslaagde als geblokkeerde pogingen met directe en indirecte invoer.
• Meet ongeoorloofde gegevensblootstelling, ongewenste toolacties en onterechte weigeringen.
• Herhaal tests na wijzigingen aan modellen, prompts, tools en databronnen.
• Leg per test vast welke beveiligingslaag de aanval had moeten stoppen.

Zo worden resultaten vergelijkbaar en kunnen teams zien of een wijziging de beveiliging verbetert zonder normaal gebruik onnodig te hinderen.

Kan prompt injection ook via afbeeldingen, audio of video binnenkomen?

Ja, prompt injection kan ook binnenkomen via afbeeldingen, audio of video wanneer een AI-toepassing die inhoud omzet in tekst of er betekenis uit afleidt. Een afbeelding kan bijvoorbeeld tekst bevatten die door OCR wordt herkend, terwijl gesproken instructies in audio via transcriptie in de modelcontext terechtkomen.

• Behandel OCR-tekst, transcripties en automatisch gegenereerde beschrijvingen als onbetrouwbare invoer.
• Test ook kleine, slecht zichtbare of gedeeltelijk verborgen tekst in mediabestanden.
• Beperk wat het model met herkende inhoud mag doen en controleer acties afzonderlijk.

Dezelfde kernmaatregelen gelden dus ook voor multimodale systemen: herkomst beoordelen, bevoegdheden begrenzen en voorkomen dat herkende instructies zelfstandig gevoelige acties veroorzaken.

Welke gegevens zijn nuttig om te loggen bij prompt-injectionaanvallen?

Nuttige logs leggen vast welke bron en gebruiker betrokken waren, welke beveiligingscontroles plaatsvonden en welke acties de toepassing uitvoerde. Daarmee kunnen onderzoekers de gebeurtenisketen reconstrueren zonder standaard alle vertrouwelijke documentinhoud of volledige prompts breed op te slaan.

• Registreer tijdstippen, sessie- of correlatie-ID’s en de herkomst van opgehaalde inhoud.
• Leg toolaanroepen, gebruikte rechten, validatieresultaten en weigeringen vast.
• Bewaar waar passend hashes of beperkte fragmenten in plaats van volledige gevoelige inhoud.
• Beperk toegang tot logs en stel bewaartermijnen vast.

Welke details nodig zijn, hangt af van het risico en de toepasselijke privacyregels. Zorg dat logs voldoende informatie bevatten voor onderzoek, maar niet onnodig nieuwe kopieën van gevoelige gegevens creëren.

Wie is verantwoordelijk voor de beveiliging tegen prompt injection?

De organisatie die de AI-toepassing bouwt of inzet, blijft verantwoordelijk voor de beveiliging van het volledige systeem, ook wanneer een extern model wordt gebruikt. Een modelleverancier kan beveiligingsfuncties aanbieden, maar kent niet automatisch de toegangsrechten, bedrijfsgegevens en gevolgen van acties binnen de toepassing.

• Ontwikkelaars begrenzen invoer, modelcontext en toolmogelijkheden.
• Beheerders regelen identiteiten, rechten, logging en incidentprocedures.
• Producteigenaren bepalen welke fouten aanvaardbaar zijn en wanneer menselijke controle nodig is.
• Inkoop en beveiliging beoordelen leveranciers, afhankelijkheden en afspraken over incidentmelding.

Leg taken en escalatieroutes vooraf vast. Zo is duidelijk wie een risicovolle functie kan uitschakelen, wie een incident onderzoekt en wie beslist wanneer de toepassing weer veilig kan worden gebruikt.