Red teaming van AI-agents wordt een continu proces
Microsofts External Red Team Alliance en nieuw onderzoek tonen dat red teaming van generatieve AI en AI-agents verschuift naar een doorlopend, ecosystemisch proces.
U moet kunnen aantonen dat u red teaming van AI-agents niet als eenmalige test behandelt, maar als doorlopend onderdeel van uw beveiligingsproces — en dat u weet welke lagen van uw agent-workflow kwetsbaar zijn voor aanval.
De aankondiging op 31 juli 2026 van red teaming van generatieve AI en AI-agents als doorlopend, ecosystemisch proces markeert een verschuiving in hoe organisaties AI-veiligheid moeten benaderen. Waar red teaming lange tijd een incidentele, menselijke oefening was, ontstaat nu een gestructureerd systeem met drie lagen: providerprogramma's, onafhankelijke frameworks en taxonomieën, en autonome red-team-agents die aanvallen zelf uitvoeren. Voor professionals die AI inzetten in de buurt van vertrouwelijke informatie betekent dit dat u niet alleen het model hoeft te controleren, maar ook de manier waarop dat model toegang krijgt tot gevoelige data.
In onze beoordeling is dit geen theoretische waarschuwing. Empirische tests tonen aan dat elk van de geteste frontier-modellen ten minste één geslaagde agent-compromittering vertoonde. Autonome red-team-agents zoals AgentXploit bereiken aanvalsuccespercentages van 79 procent op benchmarks en voeren geslaagde aanvallen uit op echte agents in productie. RedAgent identificeerde zeshonderd kwetsbaarheden in zestig applicaties. Dit zijn geen randgevallen; het zijn aanwijzingen dat uw huidige controles onvoldoende zijn.
Welke aanvalsoppervlakken heeft een AI-agent die een klassieke pentest niet raakt?
Een AI-agent is geen monolithisch model. Het bestaat uit lagen: orchestratie, geheugen, toolrechten, externe contentkanalen en de configuratie die bepaalt welke data het model mag aanraken. Dreigingsmodellen zoals MAESTRO brengen deze lagen expliciet in kaart. Een aanvaller kan niet alleen via directe prompt-injectie aanvallen, maar ook via indirecte injectie door documenten, via geheugenmanipulatie of door toolrechten te misbruiken die u aan de agent hebt gegeven.
Dat onderscheid is cruciaal. Een klassieke penetratietest controleert meestal het model zelf en de directe inputkanalen. Maar een agent-specifieke aanval exploiteert de werkstroom eromheen: hoe het geheugen wordt beheerd, welke externe bronnen het mag raadplegen, welke tools het mag aanroepen. Voor advocaten, notarissen, bedrijfsartsen, journalisten en compliance-teams betekent dit dat u niet alleen naar de output hoeft te kijken, maar ook naar de manier waarop die output tot stand is gekomen.
Welke foutmodi moet u in uw risicoregister opnemen?
- Agent-compromittering via toolrechten — een aanvaller misbruikt de rechten die u aan de agent hebt gegeven om gevoelige data op te halen of acties uit te voeren.
- Indirecte prompt-injectie via documenten en geheugen — kwaadwillige inhoud in een document dat de agent raadpleegt, of in het geheugen dat de agent bijhoudt, leidt tot ongewenst gedrag.
- Context-leakage via orchestratielagen — gevoelige informatie lekt via de manier waarop de agent taken coördineert of tools aanroept.
- Hallucinatie onder druk — wanneer een agent wordt aangevallen, genereert het onbetrouwbare of verzonnen antwoorden die u niet kunt onderscheiden van correcte informatie.
- Privilege escalation via agent-configuratie — een aanvaller misbruikt de manier waarop u de agent hebt ingesteld om toegang tot hoger geclassificeerde data te krijgen.
Welke controles moet u kunnen aantonen?
- Documenteer welk model elke workflow gebruikt en welke data het mag aanraken — leg vast welke lawful basis u hebt voor elke gegevensverwerking en welk model dat doet.
- Implementeer anonimisering vóórdat gevoelige inhoud naar AI-modellen gaat — zorg dat alleen geanonimiseerde data de agent bereikt, en dat niets wordt doorgestuurd als de privacycontrole faalt.
- Log alle agent-acties, inclusief toolgebruik en geheugenraadplegingen — u moet kunnen reconstrueren wat de agent heeft gedaan en welke data het heeft aangeraakt.
- Voer regelmatig agent-specifieke red teaming uit, niet alleen modelvalidatie — test indirecte injectie, toolmisbruik en geheugenmanipulatie, niet alleen directe prompt-injectie.
- Beperk toolrechten tot het minimum dat nodig is voor de taak — geef de agent niet meer rechten dan strikt noodzakelijk, en controleer die rechten regelmatig.
- Zet multi-model verificatie in voor kritische outputs — laat verschillende modellen op dezelfde vraag antwoorden, zodat u kunt beoordelen of een antwoord standhoudt.
Hoe ondersteunt tooling uw professionele oordeel?
Tooling kan u helpen om de verificatiestappen inzichtelijk te maken. Een controlelaag rond AI-gebruik kan documenten anonimiseren voordat ze naar modellen gaan, kan logging inzichtelijk maken, en kan multi-model verificatie mogelijk maken. Maar tooling garandeert geen correctheid, elimineert geen hallucinaties en vervangt uw professionele eindoordeel niet. U blijft verantwoordelijk voor de beslissing of u een antwoord vertrouwt en of u het mag gebruiken.
De ontwikkelingen rond red teaming, de Cloud Security Alliance-agenda, het OWASP-landschap en frameworks als AgentXploit wijzen in dezelfde richting: red teaming van AI-agents wordt een continu proces. Voor organisaties die met vertrouwelijke informatie werken betekent dat vooral dat toegangsrechten, logging en menselijk toezicht net zo serieus moeten worden genomen als het model zelf. Tooling kan die controle ondersteunen, maar de verantwoordelijkheid blijft bij u.
Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van Microsoft, Cloud Security Alliance, OWASP, OpenReview en Computer.
Geschreven door
Tobias Lindqvist
Adversarial machine learning en de beveiligingseigenschappen van retrieval-systemen.