Red teaming van AI-agents moet de monitor aanvallen

U moet vóór implementatie de volledige gedragsketen van onbetrouwbare invoer tot externe actie doortoetsen, inclusief aanvallen op de monitor zelf. Een losse payloadtest of één controlelaag bewijst niet dat een AI-agent bestand is tegen promptinjectie.

Een analyse van 27 oktober 2026 van promptinjectie bij AI-agents en de beproeving van monitoringsystemen stelt dat monitoring alleen verdedigbaar is als onderdeel van een gestructureerde beoordeling van de hele gedragsketen. Een onafhankelijke red-teambeoordeling vond onbewaakte contextovergangen, mogelijkheden om de monitor zelf te misleiden en kwetsbaarheden door serialisatieverschillen. In onze beoordeling betekent dit dat u een monitor niet langer als bewezen beheersmaatregel in een risicobeoordeling mag opvoeren zonder aantoonbare red teaming van de monitor zelf.

Waarom een losse test niet volstaat

Promptinjectie voltrekt zich zelden op één plek. Een kwaadaardige instructie kan binnenkomen via een document, e-mail of toolresultaat, vervolgens worden opgehaald via retrieval, meelopen in een samenvatting, worden doorgegeven aan een andere agent en pas veel later een toolcall met echte bevoegdheid activeren. Een test die alleen de ingang controleert, mist die keten volledig.

De onderzoeksorganisatie en Redwood Research publiceerden op 22 oktober 2026 een red-teambeoordeling van een intern monitoringsysteem. De onderzoekers vonden onbewaakte compaction-events (momenten waarop een agent zijn gespreksgeschiedenis samenvat), mogelijkheden om de monitor zelf via geïnjecteerde instructies te misleiden, agenttools die buiten het toezicht vielen en kwetsbaarheden door serialisatieverschillen. Dezelfde dag publiceerde het Anthropic Fellows Program vergelijkbaar werk over controlelagen tegen kwaadaardige coding agents. Ook daar bleken monitorinjectie, aanvallen over meerdere contexten en dekkingsgaten reële routes om een onafhankelijke controlelaag te omzeilen.

Welke faalvormen moet u gericht zoeken?

• Onbewaakte contextovergangen — momenten waarop een agent zijn gespreksgeschiedenis samenvat of inkort zonder controle.
• Monitorinjectie — geïnjecteerde instructies die de monitor zelf misleiden of omzeilen.
• Tools buiten het toezicht — agenttools die niet worden gedekt door de controlelaag.
• Serialisatieverschillen — kwetsbaarheden door verschillende manieren waarop gegevens worden verwerkt.
• Latente exploits — kwaadaardige instructies die pas veel later, bij een late toolcall, schade aanrichten.

Hoe moet u de volledige keten doortoetsen?

Gebruik een achtfasige workflow als ruggengraat: volg de volledige gedragsketen én test de controlelaag zelf. Red teaming mag niet eindigen bij een geslaagde exploit, maar moet doorlopen tot persistentie, impact, rapportage en herstel.

1. Documenteer welke invoervlakken bestaan — alle punten waar onbetrouwde gegevens het systeem kunnen binnenkomen.
2. Traceer de volledige gedragsketen — hoe gegevens door retrieval, samenvatting, agentoverdracht en toolcalls stromen.
3. Test de monitor onder alle omstandigheden — inclusief compaction-events, serialisatieverschillen en multi-context aanvallen.
4. Demonstreer herstel en hertest — een geslaagde demo vormt geen vrijgave; vóór go-live moet ook herstel zijn aangetoond.
5. Leg dekkingsoverzicht vast — reproduceerbare red-teamresultaten en aantoonbare dekking van alle kritieke routes.

Wat moet u in het contract met de leverancier vastleggen?

Omdat een injectie volgens onderzoek pas bij een late toolcall schade kan aanrichten, moet u trajectbewijs over de hele keten en reproduceerbare red-teamresultaten verplicht stellen. Omdat betere detectie latency en kosten verhoogt, moet de directie die afweging expliciet beslissen en dateren, in plaats van die impliciet aan een engineeringteam over te laten. Omdat een agent die buiten zijn taakgrenzen handelt tijdig moet worden opgemerkt, moet incidenttriage en hertest vóór go-live zijn aangetoond.

Dit soort assurance-eis sluit aan bij de documentatie-eisen die onder meer uit regelgeving voortvloeien voor systemen met hoog risico. Wat tooling kan dragen — de systematische doorgang van invoervlakken, omgevingen en gedragsroutes — en wat uw eigen professionele oordeel blijft, is de weging van welke routes werkelijk kritiek zijn en welke acceptabele risico's zijn in uw specifieke context. Geen framework kan die keuze voor u maken.