Prompt injection is inmiddels de meest besproken aanvalstechniek op grote taalmodellen. De kern van het probleem is verrassend eenvoudig: de meeste LLM-applicaties maken geen onderscheid tussen de instructies die door de ontwikkelaar zijn meegegeven en de data die als input wordt verwerkt. Dat betekent dat kwaadaardige tekst die is ingebed in een document of een gebruikersinvoer de instructies van het systeem kan overschrijven.
Hoe prompt injection werkt in de praktijk
Er zijn twee varianten. Directe prompt injection vindt plaats via de gebruikersinvoer zelf: een aanvaller geeft een prompt die het model instrueert om zijn systeeminstructies te negeren en iets anders te doen. Indirecte prompt injection is subtieler en gevaarlijker voor omgevingen die documenten verwerken. Hier is de kwaadaardige instructie verborgen in een extern document dat het model te verwerken krijgt — een PDF, een webpagina, een e-mail. Het model leest het document, interpreteert de ingebedde instructie als legitieme opdracht en voert die uit.
In een juridische documentomgeving is het indirecte variant bijzonder relevant. Stel dat een strafdossier een document bevat met ingebedde tekst die het AI-systeem instrueert om bepaalde passages te negeren, bepaalde conclusies te trekken of bepaalde informatie te exfiltreren. Als het systeem geen isolatie heeft, kan dit leiden tot manipulatie van de analyseresultaten en in sommige gevallen tot het lekken van vertrouwelijke data.
Data-exfiltratie als aanvalsdoel
Exfiltratie via LLM-kwetsbaarheden kent meerdere paden. Een aanvaller kan via prompt injection het model instrueren om vertrouwelijke informatie te verwerken in uitgaande verzoeken — naar externe API’s, naar webadressen of via rendering-aanvallen die in browsergebaseerde interfaces zichtbaar zijn voor de aanvaller maar niet voor de gebruiker.
Exfiltratievectoren die in onderzoek zijn aangetoond omvatten Markdown-rendering van kwaadaardige links waarbij het model gevoelige data als URL-parameter meestuurt, API-calls naar externe webhooks waarbij de instructie afkomstig is uit een verwerkt document, en samengestelde prompt-ketens waarbij meerdere stappen de beveiliging omzeilen.
De aanvalsmogelijkheden zijn echt en goed gedocumenteerd. Ze zijn geen theoretische oefening.
Technische mitigaties
De mitigaties vallen uiteen in drie categorieën. Architecturele maatregelen zijn het meest effectief. Een volledig geïsoleerde verwerkingsomgeving zonder uitgaande verbindingen naar externe systemen elimineert de meest impactvolle exfiltratiepaden. Als het model geen verbinding kan maken met de buitenwereld, kan het ook geen data exfiltreren via externe verzoeken. Input- en outputvalidatie vormen de tweede categorie: systematische filtering van bekende injectionpatronen in input, het valideren van output op onverwachte externe verwijzingen en het blokkeren van output die niet overeenkomt met het verwachte formaat.
Als derde laag helpt het principe van least privilege ook voor AI-systemen: geef het model toegang tot de minimale dataset die nodig is voor de taak. Compartimentering van context — waarbij het model per analysestap alleen de relevante documenten krijgt in plaats van het volledige dossier — beperkt de schade bij een succesvolle injectieaanval.
Wat dit betekent voor juridische AI-applicaties
Voor een omgeving die strafdossiers verwerkt zijn deze aanvalstechnieken niet hypothetisch. Het gaat om vertrouwelijk materiaal met directe implicaties voor lopende procedures. Een manipulatie van de analyseresultaten — zelfs subtiel — kan de verdedigingslijn beïnvloeden. Een succesvolle exfiltratie lekt de inhoud van een dossier naar een onbekende partij.
Het antwoord is architectureel: een verwerkingsomgeving die structureel is geïsoleerd, zodat zelfs een succesvolle injectieaanval nergens naartoe kan. Dat is de reden waarom CyberSecurity AD heeft gekozen voor isolatie als primair beveiligingsprincipe, en niet voor filtering of detectie als eerste linie.
Standpunt
Prompt injection is het onderwerp in AI-security waar ik persoonlijk het meest door word beziggehouden. Niet omdat het altijd spectaculair is — veel aanvallen zijn vrij eenvoudig en weinig geraffineerd — maar omdat de fundamentele kwetsbaarheid zo moeilijk te repareren is zolang LLM’s instructies en data niet structureel scheiden.
Er zijn mensen die zeggen dat promptinjection een tijdelijk probleem is dat door betere modellen zal worden opgelost. Ik geloof dat niet. De kwetsbaarheid zit niet in een specifieke modelversie maar in het architectureel concept van één taalstroom voor zowel instructies als data. Totdat dat concept fundamenteel verandert, blijft de kwetsbaarheid bestaan.
Wat me bezighoudt in de context van CyberSecurity AD is dat we werken met documentstromen die extreem vertrouwelijk zijn. Strafdossiers bevatten informatie over verdachten, slachtoffers, getuigen en onderzoeksmethoden die in verkeerde handen ernstige schade kunnen aanrichten. De gedachte dat kwaadaardige tekst verborgen in zo’n dossier de analyse kan manipuleren of data kan exfiltreren, is voor mij een concrete reden geweest om isolatie als architectuurprincipe te kiezen.
Een geïsoleerde omgeving lost het injectieprobleem niet technisch op in de zin dat injectieaanvallen niet meer worden geprobeerd. Maar het haalt de meest gevaarlijke uitkomst weg: er is nergens data naartoe te sturen, want er zijn geen externe verbindingen. Dat is de krachtigste mitigatie die beschikbaar is, en het is de reden dat ik de architectuurkeuze van CyberSecurity AD ook vanuit dit specifieke dreigingsperspectief volledig verdedigbaar vind.