Red teaming van AI-agents inrichten: de drie lagen die u vanaf 2026 nodig heeft

U moet red teaming voor generatieve AI en agents in drie gelaagde lagen organiseren: geautomatiseerde tests in uw CI-pipeline, periodieke oefeningen tegen tools en data, en autonome scans die productie continu monitoren. Per werkstroom moet u vastleggen welke tests zijn uitgevoerd, welke kwetsbaarheden zijn gevonden en welke mitigaties zijn doorgevoerd.

De aanleiding is een analyse van 14 september 2026 van autonome AI-red-team-agents, die stelt dat organisaties zelf agentic red-teamcapaciteit moeten opbouwen gericht op continue in plaats van periodieke tests. De analyse beschrijft een autonome agent die in de eerste maand ruim 17.000 unieke bevindingen deed in ongeveer 1.000 klantomgevingen, waaronder een BOLA-kwetsbaarheid in een airline-API die jaren aan passagiersdata blootlegde. In onze inschatting betekent dit voor beveiligingsteams dat red teaming verandert van een losse pentest naar een doorlopende beveiligingslaag, vooral voor organisaties die met vertrouwelijke informatie werken.

Wat verandert in de praktijk van testen?

De kern van deze verschuiving is niet dat AI kwetsbaarheden vindt — dat doen scanners al langer — maar dat de test zelf autonoom, herhaald en breed inzetbaar wordt. Dit verandert de vraag voor beveiligingsteams van wanneer testen we opnieuw naar hoe houden we de testlaag zelf onder controle. Red teaming wordt volgens de beschikbare kaders een gestructureerde, lifecycle-brede discipline met eigen taxonomie en tooling, gericht op gecoördineerde adversarial testing, defensieve validatie en feedback-loops.

Welke risico's ontstaan specifiek bij agents?

Classieke LLM-tests dekken risico's zoals jailbreaks en het lekken van persoonsgegevens. Ze dekken echter niet automatisch de risico's die ontstaan wanneer een model tools bedient en autonoom handelt. Agent-specifieke red teaming stelt andere vragen: kan een agent worden misleid door een instructie verstopt in een geüpload document? Kan hij een goedkeuringsstap omzeilen of zich via gedeeld geheugen naar andere agents verspreiden?

De adversarial-ML-taxonomie van NIST moet in agentische context worden toegepast. Red-teamoefeningen voor agents moeten expliciet testen of aanvallende instructies in documenten, e-mails, agenda's en webcontent het gedrag van een agent kunnen sturen. Dit is een andere testvraag dan bij een chatbot.

Welke foutmodi en risico's moet u adresseren?

• Jailbreaks en prompt-injectie — directe aanvallen op modelgedrag via tekstinvoer.
• Instructies in documenten en content — aanvallende commando's verstopt in geüploade bestanden of externe bronnen.
• Omzeiling van goedkeuringsstappen — agents die controles proberen te omzeilen of autorisatielogica te manipuleren.
• Laterale verspreiding via gedeeld geheugen — agents die zich via cache of persistente opslag naar andere agents verspreiden.
• Ongeautoriseerde toolgebruik — agents die integraties op onbedoelde wijze inzetten.
• Lekkage van vertrouwelijke data — persoonsgegevens of bedrijfsinformatie gereproduceerd in modeloutput.

Hoe richt u de drie lagen in?

De eerste laag is geautomatiseerde LLM-tests in uw CI-pipeline, uitgevoerd bij elke modelupdate. Deze tests controleren op standaardrisico's en kunnen snel schalen.

De tweede laag bestaat uit periodieke agent-oefeningen tegen tools en data. Deze oefeningen simuleren realistische aanvalsscenario's en testen of agents zich gedragen zoals bedoeld wanneer ze met integraties werken.

De derde laag is autonome red-team-agents die productie continu scannen. Dit zijn zelf gevoelige systemen: beperk hun rechten, log hun acties en behandel ze als onderdeel van uw aanvalsvlak.

Welke controles moet u per werkstroom kunnen aantonen?

1. Documenteer welk model en welke tools elke werkstroom gebruikt — leg vast welke versie van welk model actief is en welke integraties het bedient.
2. Voer geautomatiseerde tests uit en registreer de resultaten — zorg dat elke CI-pipeline-run zijn testresultaten vastlegt.
3. Voer periodieke agent-oefeningen uit en documenteer bevindingen — houd bij welke scenario's zijn getest en welke kwetsbaarheden zijn gevonden.
4. Zet autonome scans in en log hun activiteit — registreer welke autonome agent welke tests heeft uitgevoerd en wat daaruit volgde.
5. Traceer mitigaties van bevindingen naar productie — documenteer welke beveiligingsmaatregelen zijn doorgevoerd en wanneer.

Hoe houdt u zichtbaarheid over het geheel?

De kernvraag verschuift van hebben we getest naar kunnen we per werkstroom aantonen wat we hebben getest en wat daaruit volgde. Dit is cruciaal voor audits en interne risk-committees. Een verificatielaag kan functioneren als zichtlaag boven de red-teamarchitectuur: een manier om per werkstroom zichtbaar te maken welke tests zijn uitgevoerd, welke kwetsbaarheden bij modellen en agents zijn gevonden en welke mitigaties zijn doorgevoerd.

Zoeken tooling kan de administratie dragen en patronen herkennen. Het professionele eindoordeel over bevindingen, mitigaties en risicoacceptatie blijft echter bij uw beveiligings- en risicoteam. Tooling vervangt die verantwoordelijkheid niet.