Prompt injection bij AI-agents is een architectuurfout, geen modelbug

U moet uw AI-agents behandelen als potentieel onbetrouwbare identiteiten binnen uw architectuur en architectonische controles implementeren — niet alleen input-filters — om prompt injection en geheugenvergiftiging tegen te gaan.

De aanleiding is een analyse van 20 augustus 2026 van prompt injection bij AI-agents als architectuurfout, die stelt dat injecties niet langer alleen een model-filtering-probleem zijn, maar een structurele kwestie in systeemontwerp. De analyse steunt op onderzoek van de University of Washington uit juli 2026, beveiligingsbevindingen van Microsoft uit mei 2026, en NIST-normen uit 2026 die indirecte prompt injection expliciet als aanvalsklasse voor agenten benoemen. In onze beoordeling betekent dit dat organisaties met gevoelige informatie hun agenten niet kunnen beveiligen door alleen het model beter in te stellen; zij moeten hun gehele architectuur herontwerpen.

Waarom is prompt injection bij agents geen modelbug?

Prompt injection is lang gezien als een probleem van input-filtering: een agent krijgt een kwaadaardige instructie, weigert die, klaar. Maar onderzoek toont aan dat agents schadelijke instructies kunnen weigeren en toch in hun persistente geheugen opslaan, waarna die instructies in latere sessies alsnog gedrag beïnvloeden. Dit is geen fout in het model zelf, maar een architecturale zwakheid: zodra een agent externe content leest en tegelijk toolrechten, data-toegang of code-uitvoering heeft, ontstaat een aanvalsoppervlak dat een enkel filter niet afdekt.

Microsoft toonde in mei 2026 aan hoe ernstig dit kan worden. Twee kritieke kwetsbaarheden in het Semantic Kernel-framework, waaronder CVE-2026-26030, maakten het mogelijk dat een enkele prompt injection tegen een agent met bepaalde plug-ins kon uitlopen op remote code execution op hostniveau. De tekst die de agent leest, wordt dan feitelijk een commando dat op het onderliggende systeem wordt uitgevoerd. Dit is een verschuiving van "verkeerde antwoorden" naar directe systeemcompromittering.

Welke aanvalsvormen moet u onderscheiden?

Prompt injection komt in minstens drie vormen voor, en ze versterken elkaar:

• Directe prompt injection — kwaadaardige instructies rechtstreeks in de invoer van de agent.
• Indirecte prompt injection — kwaadaardige instructies verborgen in externe content die de agent leest (webpagina's, documenten, e-mails).
• Agent data injection (ADI) — manipulatie van data waarop de agent vertrouwt (naamvelden, knop-ID's, metadata) zonder herkenbare instructietekst.
• Agent memory poisoning — kwaadaardige instructies die in het persistente geheugen van de agent blijven hangen en toekomstig gedrag beïnvloeden.
• Tool-misbruik — escalatie van injectie naar code-uitvoering via toolbinding zonder voldoende sandboxing of privilege-beperking.
• Geheugenvergiftiging via retentie — onvoldoende beleid voor verwijdering van gevoelige of gemanipuleerde gegevens uit agentengeheugen.

Welke architectonische controles moet u kunnen aantonen?

1. Scheiding van vertrouwde en niet-vertrouwde kanalen — instructies komen alleen uit gecontroleerde bronnen; externe data wordt als onbetrouwbaar behandeld.
2. Sandboxing van code-uitvoering — toolcalls en code-uitvoering vinden plaats in een geïsoleerde omgeving met minimale systeemtoegang.
3. Least-privilege toolbinding — agents krijgen alleen de minimaal noodzakelijke rechten per workflow, en credentials zijn per-agent en sessie-gebonden.
4. Expliciet geheugen- en retentiebeleid — gevoelige of gemanipuleerde gegevens worden actief verwijderd; retentie is gedocumenteerd en auditeerbaar.
5. Multi-laag detectie en tamper-evidente logging — alle toolcalls, geheugenmutaties en afwijkingen van verwacht gedrag worden geregistreerd en kunnen worden geïnspecteerd.

Hoe helpt verificatie en zichtbaarheid?

Verificatie en zichtbaarheid zijn geen vervangers voor architectonische controles, maar aanvullingen die het geheel controleerbaar maken. Een verificatieconsole kan helpen inzichtelijk te maken welke externe bronnen in een workflow zijn betrokken en welke stappen zijn gezet, zodat professionals afwijkingen makkelijker opmerken. Voor documentworkflows kan voorbewerking en anonimisering op EU-infrastructuur plaatsvinden, waarbij gevoelige waarden worden vervangen door synthetische, sessiegebonden equivalenten. De workflow is fail-closed: mislukt de privacycontrole, dan wordt het document niet doorgestuurd.

De NIST-normen van 2026 positioneren verdediging tegen indirecte prompt injection als een architecturale control-eis, niet als iets wat je met fine-tuning of red-teaming alleen afvangt. Voor organisaties met governanceverplichtingen betekent dit dat de attack surface van agents thuis hoort in het beveiligings- en compliance-ontwerp.

Wat kan tooling doen, wat niet?

Tooling kan controle ondersteunen en meer zicht geven, maar het professionele eindoordeel blijft bij u. Een verificatielaag kan afwijkingen zichtbaar maken en inspectie mogelijk maken, maar garandeert geen juistheid of waarheid. Logging kan helpen detecteren dat iets mis is gegaan, maar kan niet voorkomen dat het gebeurt. Sandboxing kan escalatie beperken, maar alleen als de architectuur eromheen goed is ontworpen. De bronnen van dit voorjaar en deze zomer wijzen dezelfde kant op: prompt injection bij AI-agents is in 2026 alleen beheersbaar binnen een expliciet ontworpen, auditeerbare architectuur. Uw taak is die architectuur in te richten en te handhaven.