SecurityTechInsider AI-veiligheid & governance
EN/ NL
Risico

Prompt injection bij AI-agents: architectuur bepaalt blootstelling

Prompt injection vormt een architectuurprobleem dat niet door modelkeuze wordt opgelost. Organisaties moeten gescheiden bevoegdheden, gecontroleerd geheugen en auditeerbare logs implementeren.

24 juli 2026 4 min
Illustratie bij dit artikel: Prompt injection bij AI-agents.
Prompt injection-aanvallen op AI-agents vereisen architecturale verdediging en auditeerbare logs, niet alleen modelkeuze. Beeld: SecurityTechInsider — originele redactionele illustratie

U bent verantwoordelijk voor het aantonen dat prompt injection-aanvallen op uw AI-agents niet onopgemerkt kunnen plaatsvinden en dat gevoelige data niet zonder controle aan modellen wordt blootgesteld. Dit is een architectuurverplichting, niet iets dat modelkeuze oplost.

De aanleiding is een analyse van 24 juli 2026 van prompt injection en tool-hijacking in AI-agents, die stelt dat effectieve verdediging om gelaagde architectuur vraagt: least-privilege credentials, sandboxing, integriteitscontroles en geheugenisolatie. De post-mortem van incidenten in mei 2026 — waaronder de BadHost CVE en Copilot-achtige aanvallen — toont aan hoe agents met toegang tot gevoelige data in praktijk aanvalsdoelen worden. In onze beoordeling betekent dit dat organisaties prompt injection niet kunnen behandelen als een modelprobleem, maar moeten inzien dat het een verificatie- en nalevingskwestie is die rechtstreeks raakt aan artikel 15 van de EU AI Act en aan opkomende meldregimes zoals DORA, NIS2 en SB 53.

Waarom architectuur, niet modelkeuze, het risico bepaalt

Prompt injection wordt vaak voorgesteld als een eigenschap van het taalmodel — iets dat je met een ander model of betere training oplost. De recente incidenten uit voorjaar 2026 laten een ander patroon zien. Wanneer een agent toegang heeft tot interne systemen, gevoelige dossiers of externe tools, verschuift het risico van 'een verkeerd antwoord' naar concrete schade: datalekken, ongewenste acties in backend-systemen en niet-traceerbare fouten. De verdediging zit niet in het model, maar in hoe je de agent bouwt. Zylos AI documenteert hoe aanvallen zich verspreiden via het geheugen en de tools van een agent — en hoe je dat stopt door least-privilege credentials, sandboxing en integriteitscontroles op langetermijngeheugen in te voeren. Elke laag die je toevoegt, maakt het moeilijker voor een aanval om de hele agent onder controle te krijgen.

Welke foutmodi moet u kunnen benoemen?

  • Prompt injection via onvertrouwde inhoud — aanvallers manipuleren documenten of externe invoer om commando's in het model in te voegen.
  • Tool-hijacking en privilege escalation — een geïnjecteerde prompt dwingt de agent om gevoelige API's of backend-systemen aan te roepen met volledige credentials.
  • Datalekken via geheugen — gevoelige informatie uit eerdere interacties blijft in het agentgeheugen staan en wordt later blootgesteld.
  • Ondetecteerde acties — de agent voert schadelijke commando's uit zonder dat logs of controles dit vastleggen.
  • Naleving van meldregimes — u kunt niet aantonen wat er is gebeurd, dus u kunt incidenten niet correct rapporteren onder DORA, NIS2 of SB 53.

Welke controles moet u kunnen aantonen?

  1. Gescheiden bevoegdheden per workflow — document welke credentials elke agent-taak krijgt en waarom; minimaliseer wat elke agent kan doen.
  2. Sandboxing van tools en externe integraties — voer agent-acties uit in een geïsoleerde omgeving die niet rechtstreeks toegang heeft tot productiedatabases of gevoelige systemen.
  3. Gecontroleerd geheugen met integriteitscontroles — implementeer persistentie die alleen geanonimiseerde of geclassificeerde informatie opslaat, en test regelmatig of die controles werken.
  4. Auditeerbare logs van elke prompt en elke output — leg vast welke invoer de agent kreeg, welke tool hij aanriep en wat hij terugstuurde, zodat u incidenten kunt reconstrueren.
  5. Expliciete tests op prompt injection — voer regelmatig red-teaming uit met aanvalsscenario's die specifiek gericht zijn op uw agent en uw tools.

Hoe past dit in regelgeving en incidentrapportage?

Prompt injection wordt niet alleen een beveiligingskwestie, maar ook een nalevingskwestie. Artikel 15 van de EU AI Act verplicht organisaties die hoogrisico-AI-systemen inzetten tot robuustheidsmaatregelen tegen aanvallen. Tegelijk verscherpen DORA, NIS2, de RAISE Act in New York en California SB 53 de meldverplichtingen: u moet incidenten niet alleen detecteren, maar ook kunnen reconstrueren en tijdig rapporteren. Help Net Security documenteert dat prompt injection in 2026 nog steeds het grootste deel van de gedocumenteerde agentic AI-beveiligingsfouten drijft. Dit betekent dat toezichthouders en auditors verwachten dat u kunt aantonen hoe u dit risico hebt beheerst.

Wat kunnen tools doen, wat blijft uw verantwoordelijkheid?

Verificatielagen en multi-model-controles kunnen helpen om zichtbaarheid te geven: welke stappen heeft de agent genomen, welke documenten zijn geanonimiseerd voordat ze aan een model werden aangeboden, waar is de integriteit gebroken? Dit maakt het makkelijker om AI-antwoorden kritischer te beoordelen en om logs voor audits beschikbaar te stellen. Maar verificatie garandeert geen correctheid, elimineert geen hallucinaties en maakt anonimisering niet perfect. Het professionele eindoordeel — welke informatie mag deze agent zien, welke acties zijn toegestaan, hoe interpreteert u de output — blijft altijd bij u. Tooling kan het zichtbaar maken; het kan niet voor u denken.

Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van Clawvard, Frontiers, Aidevdayindia en Helpnetsecurity.

Tobias Lindqvist

Geschreven door

Tobias Lindqvist

Adversarial machine learning en de beveiligingseigenschappen van retrieval-systemen.