Red teaming van AI-agents moet ook de monitor zelf aanvallen, blijkt uit METR-beoordeling

Een losse payloadtest of één monitor bewijst niet dat een AI-agent bestand is tegen promptinjectie, want een recente red-teambeoordeling van METR en Redwood vond onbewaakte contextovergangen, monitorinjectie en bypasses. Toets daarom vóór implementatie de volledige keten van onbetrouwbare invoer tot externe actie, en val ook de monitor zelf aan.

Op 22 oktober 2026 publiceerde onderzoeksorganisatie METR, samen met Redwood Research, een onafhankelijke red-teambeoordeling van het interne systeem waarmee OpenAI het gedrag van zijn AI-agents bewaakt. De onderzoekers vonden onder meer onbewaakte compaction-events (momenten waarop een agent zijn gespreksgeschiedenis samenvat en inkort), mogelijkheden om de monitor zelf te misleiden via geïnjecteerde instructies, agenttools die buiten het toezicht vielen en kwetsbaarheden door verschillen in hoe gegevens werden geserialiseerd. Kort gezegd: de controlelaag die onveilig gedrag zou moeten tegenhouden, bleek zelf aanvalbaar.

Dezelfde dag publiceerde het Anthropic Fellows Program vergelijkbaar werk over blocking classifiers tegen kwaadaardige coding agents. Ook daar bleken monitorinjectie, aanvallen over meerdere contexten en dekkingsgaten reële routes om een onafhankelijke controlelaag te omzeilen. De gedeelde les is onwelkom maar nuchter: monitoring is geen bewezen controle totdat je de monitor zelf hebt aangevallen.

Wat vonden METR, Redwood en Anthropic precies in hun red-teambeoordelingen?

METR en Redwood rapporteerden concrete, operationele tekortkomingen in een intern agentmonitoringsysteem: onbewaakte compaction-events, injecties die de monitor beïnvloedden, tools die niet werden gedekt en serialisatieverschillen die als opening dienden. Anthropic liet zien dat meer context, het meelezen van toolresultaten en agentische monitorstappen de detectie verbeteren, maar latency en kosten verhogen.

Belangrijk is dat deze bevindingen uit specifieke interne systemen en experimentele opstellingen komen. Ze leveren geen universeel kwetsbaarheidspercentage op en zijn geen bewijs dat elk product deze zwakke plekken heeft. Wat ze wél aantonen: deze faalvormen zijn realistisch en blijven onzichtbaar zolang je ze niet gericht opzoekt.

Waarom volstaat één monitor of losse payloadtest niet om promptinjectie uit te sluiten?

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

De academische studie ASPIRE, gepubliceerd op arXiv, beschrijft daarom een verschuiving van het optimaliseren van afzonderlijke aanvalsteksten naar open-ended vulnerability discovery: het systematisch doorzoeken van combinaties van invoervlakken, omgevingen, gedragsroutes en gevolgen. De gerapporteerde resultaten zijn benchmarkresultaten en geen bewijs van productveiligheid, maar ze onderbouwen wel dat gestructureerd zoeken bredere dekking geeft dan vaste payloadtests.

Hoe ziet een verdedigbare pre-deploymentbeoordeling van een AI-agent eruit?

Een verdedigbare beoordeling volgt de volledige gedragsketen én test de controlelaag zelf. Het OWASP GenAI Security Project beschrijft hiervoor een achtfasige workflow die red teaming niet laat eindigen bij een geslaagde exploit, maar doorloopt tot persistentie, impact, rapportage en herstel. Gebruik die fasering als ruggengraat:

• Inventarisatie (reconnaissance): breng modellen, prompts, retrievalbronnen, tools, credentials, geheugen, contextcompressie, agent-handoffs en externe effecten in kaart.
• Gedragsgrafiek: leg per test vast welke onbetrouwbare bron binnenkomt, welke lees- en redeneerstappen volgen, welke bevoegdheid wordt aangesproken en welke toestand of actie bereikbaar is.
• Explore-fase: zoek onbekende invoervlakken en gevolgen; test niet alleen directe injecties maar ook metadata, bestanden, e-mails, toolresultaten, samenvattingen, compaction, gedeelde werkruimten en agent-naar-agentcommunicatie.
• Exploit-fase: reproduceer bijna-geslaagde aanvallen, repareer ze en generaliseer het patroon.
• Monitor-aanval: kan de agent transcriptstructuren vervalsen, de monitor uitschakelen, informatie over meerdere contexten verspreiden of een ongedekte tool gebruiken?
• Beoordeling: noem iets pas een kwetsbaarheid als de volledige causale keten aantoonbaar is — bron, retrieval, beïnvloeding, toolcall en externe of persistente impact.
• Dekkingsoverzicht: bewaar ook mislukte tests als bewijs van wat is onderzocht, niet als bewijs van veiligheid.

De OWASP-handleiding benadrukt reproduceerbare bevindingen en meetbare resultaten. Bij agents die met vertrouwelijke documenten werken, raakt dit ook aan hoe retrieval gevoelige gegevens kan lekken, en past het binnen de bredere beheersing van agentic AI en AI-agents.

Wat betekent dit voor bestuurders, juristen en CISO's die een AI-agent in gebruik nemen?

Onze analyse: omdat METR en Redwood aantoonden dat zelfs een intern monitoringsysteem bypassbaar is, kan een CISO een monitor niet langer als bewezen beheersmaatregel in een risicobeoordeling opvoeren; daarom moet het acceptatiecriterium vóór productie worden aangescherpt tot aantoonbare red teaming van de monitor zelf, met vastgelegd dekkingsoverzicht. Onze aanbeveling is dat, omdat Anthropic laat zien dat betere detectie latency en kosten verhoogt, de directie die afweging expliciet besluit en dateert, in plaats van die impliciet aan een engineeringteam over te laten. Onze aanbeveling is ook dat, omdat een injectie volgens ASPIRE pas bij een late toolcall schade kan aanrichten, een jurist in het leverancierscontract trajectbewijs over de hele keten en reproduceerbare red-teamresultaten verlangt. Ten slotte is onze beoordeling, in lijn met OWASP’s nadruk op persistentie en impact, dat een geslaagde demo geen vrijgave vormt en dat vóór go-live ook herstel en hertest moeten zijn aangetoond, zodat een agent die buiten zijn taakgrenzen handelt tijdig wordt opgemerkt — zie ook incidenttriage als een agent buiten zijn taakgrenzen handelt.

Naar onze inschatting zou de gewenste assurance-eis moeten verschuiven: niet alleen de red teamer moet aantonen dat een agent onveilig kan zijn, maar de leverancier moet aantonen dat de hele keten én de monitor zijn beproefd. Dat sluit aan bij het denken over AI-beveiliging als eigen dreigingslaag en bij de documentatie-eisen die onder meer uit de EU AI Act voortvloeien voor systemen met hoog risico.

Praktisch samengevat voor beslissers:

1. Eis trajectbewijs over de volledige keten, niet alleen een payloadtest bij de ingang.
2. Laat de monitor zelf aanvallen en bewaar het dekkingsoverzicht.
3. Besluit de afweging detectie versus latency en kosten op bestuursniveau.
4. Verbind elke vrijgave aan aangetoond herstel en hertest, niet aan een demo.

Bronnen: Het artikel steunt op red-teambeoordelingen van METR en Redwood Research en van het Anthropic Fellows Program, op de GenAI Red Teaming Manual van het OWASP GenAI Security Project en op de ASPIRE-studie op arXiv.