Je kunt prompt injection niet oplossen. Stop ermee.
Ik heb deze maand een week besteed aan het verkeerd aanpakken van prompt injection. Mijn eerste instinct, net als bij de meeste mensen, was: maak de system prompt onbreekbaar, voeg een firewall toe, detecteer de aanval. Toen bekeek ik Aikido Security’s stap-voor-stap tutorial over prompt injection en het dwong me een ongemakkelijke waarheid onder ogen te zien — prompt injection is technisch onoplosbaar, en ik was mijn tijd aan het verspillen met proberen het op te lossen.
De reden is simpel en een beetje nederig. Een LLM is een next-token-predictor. Je system prompt, de boodschap van de gebruiker, en zelfs een document dat je agent heeft gelezen — ze stromen allemaal door dezelfde tokenstroom, verwerkt door hetzelfde model. Er is geen geparametriseerde grens zoals bij een SQL prepared statement. Anders dan bij SQL injection of command injection, waar je code van data kunt scheiden, is hier alles data. Het model kan letterlijk niet het verschil zien tussen “dit is mijn instructie” en “dit is onvertrouwde content die een aanvaller voor me heeft gelegd.”
De drie voorwaarden die er echt toe doen
De tutorial gaf me het mentale model dat ik miste. Een injectie wordt pas een echte exploit wanneer drie dingen tegelijk waar zijn:
- 1. Een injectie-pad — ergens bereikt onvertrouwde content de context van de agent.
- 2. Toegang tot geheimen — de agent heeft API-keys, tokens of credentials die hij kan laten gebruiken.
- 3. Een exfiltratie-pad — een tool die die geheimen daadwerkelijk ergens naartoe kan sturen.
Lees die lijst nog eens. Je hoeft maar één van de drie te breken. Je hoeft de injectie helemaal niet te stoppen — je kunt de schade die hij veroorzaakt stoppen.
Een realistisch geval: Google’s Gemini CLI
Dit is geen theorie. Google had een AI-agent die GitHub-issues triagede in een CI/CD-pijplijn. De issue-body en titel — volledig onvertrouwde data — werden midden in de system prompt geïnjecteerd. Aanvallers gebruikten prompt injection om Gemini API-keys en GitHub-tokens te exfiltreren. Het was een live, publiek voorbeeld van voorwaarden één, twee en drie die perfect samen kwamen.
Hoe loste Google het op? Niet door de injectie te slim af te zijn. Ze zorgden dat de agent de geheimen niet had, en verwijderden de tool die dingen kon onthullen of bewerken. De injectie bestaat nog steeds — maar hij kan niets meer doen, omdat twee van de drie voorwaarden falen.
Wat ik in mijn eigen setup heb veranderd
Ik draai Hermes met een stack van acht MCP-servers (Home Assistant, SearXNG, X, Proton, Proxmox, SSH, Seekstone, codebase-memory). Ik vroeg vroeger “kan dit geïnjecteerd worden?” — de verkeerde vraag. Nu stel ik de drie-voorwaarden-vraag voor elke tool: heeft deze agent een injectie-pad, heeft hij geheimen, en kan hij ze exfiltreren? Het antwoord bepaalt wat ik beperk — niet de injectie zelf, maar de blast radius.
Mijn shift is simpel: stop met het bouwen van een onbreekbare prompt, en begin met het bouwen van een machteloze agent. Least privilege op geheimen, geen write/exfiltrate-tools waar ze niet nodig zijn, en de aanname dat elke prompt — inclusief die van mij — gemanipuleerd kan worden. Firewalls en betere system prompts vertragen een aanvaller; ze stoppen hem niet. Alleen het verkleinen van wat de agent kan doen, doet dat echt.
De vraag die ik je laat
Wanneer heb je voor het laatst niet gevraagd “kan mijn AI worden bedrogen?” maar “als mijn AI wordt bedrogen, hoeveel schade kan hij eigenlijk aanrichten?” Als je antwoord is “meer dan me lief is”, heb je je echte beveiligingswerk gevonden — en dat is geen prompt-engineering. Laat me in de comments weten hoe jij hierover denkt voor je eigen agents. Ik ben benieuwd of je deze shift al hebt gemaakt, of nog steeds het onoplosbare probeert na te jagen.
Wat vond je van dit bericht?
