Prompt injection is geen bug, het is een architectuurfout

We moeten stoppen met prompt injection te zien als een beveiligingslek dat we kunnen dichten met betere filters of slimmere training. Het is geen bug. Het is een fout in de architectuur. Die fout gedraagt zich op dezelfde manier als de code-dataverwarring die zestig jaar geleden is ingebakken in de Von Neumann-architectuur. En net als toen is de enige echte oplossing geen patch, maar een fundamenteel andere aanpak.

Tijdens een gesprek met een CISO van een Nederlands ziekenhuis moest ik hier weer aan denken. Zijn team had een AI-assistent gebouwd die op basis van patiëntbeschrijvingen een eerste triage-advies geeft. Het model draaide lokaal, volledig binnen de muren van het ziekenhuis. Volgens de DPIA was het systeem AVG-proof. De CISO wilde weten wat nodig was om NIS2-compliant te worden. Zijn idee: een paar extra guardrails, een audit-framework, en klaar. Ik moest hem teleurstellen. Het probleem zit niet in zijn implementatie. Het zit in de architectuur van elk groot taalmodel. Zijn systeem is fundamenteel kwetsbaar voor prompt injection. Niet door een fout van zijn team, maar door de technologie zelf.

De Von Neumann-parallel

Een paper die deze week op arXiv verscheen (2606.25622) maakt een vergelijking die krachtig is in zijn eenvoud. De auteurs tonen aan dat prompt injection in transformer-modellen structureel onoplosbaar is zolang instructies en data dezelfde embeddingruimte delen. Dat is dezelfde fout als de code-dataverwarring in de klassieke Von Neumann-architectuur. Daarin worden programma-instructies en data in hetzelfde geheugen opgeslagen. Die keuze maakte buffer overflows en code-injectie onvermijdelijk. Je kon ze beperken met stack canaries, ASLR en NX-bits, maar nooit helemaal stoppen. Pas de Harvard-architectuur, die instructie- en datageheugen scheidt, bood een echte oplossing.

LLM’s zitten in dezelfde val. Een prompt is een reeks tokens. Of die tokens nu uit een systeemprompt komen, van de gebruiker, of uit externe data, ze komen allemaal in hetzelfde context window terecht. Ze doorlopen dezelfde embedding-lagen en concurreren om aandacht via hetzelfde self-attention mechanisme. Er is geen harde grens tussen “instructie” en “data”. Het model kan het verschil niet weten, alleen denken. En dat is iets heel anders.

Het paper bewijst dit formeel. Voor elke prompt-structuur en elk guardrail-mechanisme in een shared-embedding architectuur bestaat er een invoer die de instructiesemantiek overschrijft. De auteurs herleiden het probleem tot een onbeslisbaarheidstelling. Het detecteren of een invoer de instructiecontext wijzigt is net zo moeilijk als het halting problem voor een klasse van transformatormodellen. Met andere woorden: er is geen algoritme dat voor alle inputs kan bepalen of prompt injection optreedt. Filters, classifiers en zelfs RLHF-training helpen, maar sluiten de aanval niet volledig af.

Wat dit betekent voor NIS2-audits

De NIS2-richtlijn verplicht essentiële en belangrijke entiteiten, ziekenhuizen, energiebedrijven, financiële instellingen, overheidsorganisaties, om passende en evenredige technische en organisatorische maatregelen te nemen. Die maatregelen moeten de beveiliging van netwerk- en informatiesystemen waarborgen. Voor AI-systemen betekent dat onder meer dat risico’s op manipulatie, datalekken en ongeautoriseerde toegang beheerst moeten worden. De BIO2 stelt soortgelijke eisen aan overheidsorganisaties. En de AI Act introduceert een risicoclassificatie die voor hoog-risico AI-systemen extra vereisten oplegt.