AI Red Teaming uitgelegd: wat een red team test, en wat het achterlaat

De meeste AI-redteamingopdrachten worden beoordeeld op het verkeerde artefact. Een week werk levert een slide deck op, het deck zegt dat de assistent overgehaald kan worden om een phishingmail te schrijven, en niemand kan achteraf zeggen of het gedrag reproduceerbaar was, hoe erg het was, of welke beheersmaatregel het had tegengehouden. De discipline heeft een echte output, en dat is geen deck: het is een set bevindingen die bij heruitvoering standhouden, elk daarvan gekoppeld aan een grens die werd overschreden en aan het bewijs dat die grens overschreed. Dat is ook de vorm van het register dat het AI-incidentenarchief bijhoudt — 400 vermeldingen over december 2024 tot en met oktober 2026, afkomstig uit 743 verschillende bronnen, en voor elk daarvan een oordeel of iemand daadwerkelijk schade heeft geleden.

De verwarring is begrijpelijk, want "red teaming" wordt gebruikt voor twee taken die alleen vocabulaire gemeen hebben en weinig anders. Dit is een gids voor beide, voor het bewijs dat elk zou moeten opleveren, en voor de vier punten waarop AI-red teaming echt afwijkt van de netwerkversie die de meeste securityteams al weten te draaien.

De kernvraag: wie is eigenaar van de test?

Vóór de scope is er de vraag wie de oefening uitvoert en waartegen. Microsoft publiceert een van de completere publieke standpunten hierover, en het is de moeite waard om het als een kaart te lezen in plaats van als een productpagina. De AI Red Team-hub van Microsoft scheidt het concept van AI-red-teaming van de praktische handleiding, en rangschikt de praktijk vervolgens in een volgorde die zelf een argument is: een overzicht, dan een gids voor het opbouwen van een LLM-red team, dan het referentiemateriaal — een bug bar voor het triëren van aanvallen op machine-learning-systemen, een taxonomie voor machine-learning-fouten, een model voor gedeelde verantwoordelijkheid, en richtlijnen voor dreigingsmodellering door ontwikkelaars.

Lees de volgorde en de methodologie volgt eruit. Een taxonomie bepaalt wat als een fout telt. Een bug bar bepaalt welke van die fouten het waard zijn om te repareren. Een gedeeld verantwoordelijkheidsmodel bepaalt wie ervoor verantwoordelijk is zodra er een wordt gevonden. Dreigingsmodellering bepaalt waar je vervolgens moet kijken. Zonder die vier genereert een red team anekdotes met een ernstkolom eraan vastgeschroefd, en die ernstkolom is maar net wat de tester die middag vond.

Microsofts open automatiseringsframework PyRIT staat op dezelfde plank, en juist die plaatsing is het nuttige deel. Een orchestratietoolkit is geen methodologie; het is iets waarmee je op een doelricht zodra de taxonomie en de bug bar bestaan. Teams die met het framework beginnen, eindigen vaak met een groot corpus aan prompts en geen manier om de resultaten te rangschikken.

Twee red teams, twee verschillende vragen

Het nuttigste onderscheid in dit vakgebied is er een dat bijna niemand opschrijft: een red team dat een model test en een red team dat een systeem test, beantwoorden verschillende vragen, met verschillende eenheden onder test, verschillende outputs en verschillende eigenaren. Ze door elkaar halen is hoe een jailbreak als beveiligingsbevinding wordt gerapporteerd, en hoe een echte privilege-escalatiebug wordt ingediend als een klacht over modelkwaliteit.

Veiligheidsevaluatie op modelniveau is een meetprobleem. Je vraagt je af of een model een categorie content zal produceren, en de eerlijke manier om die vraag te beantwoorden is een steekproef die groot genoeg is om iets over een frequentie te kunnen zeggen. De eenheid die wordt getest is het model achter een dunne API, de methode is adversariële prompting — jailbreaks, persona-aanvallen, multi-turn druk — en wat eruit komt is een transcript plus een schadeoordeel. Wanneer de gewichten veranderen of de veiligheidslaag van de leverancier verschuift, is het hele resultaat verouderd. Daarom wordt dit soort tests meestal uitgevoerd door de modelbouwer of door een onafhankelijke evaluator, en daarom sluiten de bevindingen zelden aan bij een specifieke oplossing in je applicatie.

Emulatie van tegenstanders op systeemniveau is een engineeringprobleem. Je vraagt je af of een aanvaller het geïmplementeerde systeem kan laten handelen — een bestand lezen dat het niet zou mogen lezen, een tool aanroepen die het niet zou mogen aanroepen, geld uitgeven dat het niet zou mogen uitgeven. De eenheid die wordt getest is de agent met zijn tools, retrieval en inloggegevens eraan gekoppeld. De methoden zijn de bekende, opnieuw gericht: injectie via opgehaalde inhoud in plaats van via de beurt van de gebruiker, misbruik van tools, bevoorrechte ketens die zijn samengesteld uit afzonderlijk redelijke machtigingen, datapaden die over een tenantgrens heen lekken. De uitvoer is een bevinding met een reproductie, een overschreden grens en een eigenaar die de configuratie morgen kan wijzigen.

De twee produceren onverenigbare artefacten, en die onverenigbaarheid is diagnostisch in plaats van hinderlijk. Een resultaat op modelniveau kan door jouw team niet worden 'opgelost', behalve door van model te wisselen. Een resultaat op systeemniveau kan helemaal niet door de leverancier worden opgelost. Als een rapport niet vermeldt welke van de twee het is, kun je geen van de items ervan toewijzen.

Wat het aanvalsoppervlak wordt zodra het model hulpmiddelen heeft

Het oppervlak dat de meeste teams nog steeds testen, is de prompt. Dat is ook het minst interessante, omdat het het oppervlak is waar de modelleverancier de meeste moeite in heeft gestoken om het te harden, en het oppervlak waarop een aanvaller de minste grip heeft. De oppervlakken die daadwerkelijk opleveren, zijn de oppervlakken die de applicatie heeft toegevoegd: de tools die de agent kan aanroepen, de retrieval-index die hij leest, het geheugen dat hij tussen beurten meedraagt, en het uitvoerkanaal zelf.

Hulpmiddelen zijn waar een taalmodel een actor wordt, en de interessante vraag is nooit "kan het de tool aanroepen", maar "welke minimale bevoegdheden deze tool had kunnen hebben". Een ticketopzoektool die een vrije-tekstquery accepteert, kan er meestal toe worden overgehaald de identificatie van een andere klant te accepteren. Ophalen is een inhoudskanaal naar de context van het model, wat betekent dat iedereen die naar het corpus kan schrijven — een gedeelde drive, een supportmacro, een webpagina die de fetcher bereikt — aan de prompt schrijft. Geheugen verandert één enkele beurt in persistentie: een instructie die in beurt twee is geplant, is in beurt veertig nog steeds aanwezig. Uitvoer is waar de tekst van het model ergens terechtkomt waar die wordt geïnterpreteerd, en rendering, markdown, linkpreviews en pipelines die aan de shell grenzen, interpreteren allemaal tekst.

Een opdracht die alleen de prompt test, levert een schoon resultaat op en heeft gelijk over het verkeerde.

Waarom een transcript geen bevinding is

Een bevinding moet aan drie eigenschappen voldoen die een screenshot van een chatvenster niet heeft. De eerste is reproduceerbaarheid: voer het opnieuw uit vanuit een schone staat en het gebeurt weer. Modellen zijn niet-deterministisch, dus reproduceerbaarheid is een percentage in plaats van een boolean — "negen van de tien pogingen" is een bevinding, "het is één keer gebeurd" is een gerucht. De tweede is een overschreden grens: benoem het ding dat niet had mogen gebeuren in termen van de applicatie zelf, niet in die van het model. Niet "het model was onbeleefd", maar "de agent las een document dat toebehoorde aan tenant B". De derde is een ernst die terug te voeren is op impact in plaats van op de intuïtie van de tester, en dat is waarvoor een bug bar dient.

Al het overige — het transcript, de prompt, de redenering van het model — is bewijs dat die drie ondersteunt. Het is niet de bevinding zelf, en daarom is een corpus van tweeduizend jailbreak-prompts minder waard dan vijf reproduceerbare systeembevindingen met bijbehorende benoemde controles.

Vier punten waarop AI-red teaming afwijkt van netwerk-red teaming

Teams die uit netwerk- of applicatiebeveiliging komen, brengen goede instincten en vier verkeerde aannames mee.

• Er is geen perimeter om te verdedigen. Een netwerkopdracht heeft een doelenlijst; een agentopdracht heeft een contextvenster dat op het moment van het verzoek wordt samengesteld uit bronnen die je mogelijk niet hebt geïnventariseerd. Scope moet worden uitgedrukt als databronnen en toolmachtigingen, niet hostnamen.

• Het doel is niet-deterministisch. Dezelfde invoer kan op dinsdag slagen en op woensdag mislukken. Dit doorbreekt de bewijsstandaard van "één schone reproductie" en dwingt je om percentages te rapporteren.

• De exploit is taal, en taal heeft geen patch. Je kunt een ontbrekende autorisatiecontrole repareren. Je kunt "het model kan worden overgehaald" niet patchen. De mitigatie voor een zwakte op taalniveau is een controle ergens anders — een filter, een scopelimiet, een machtigingsgrens — daarom moeten bevindingen de controle benoemen, niet alleen het gedrag.

• De leverancier zit in de cyclus. Je doel verandert wanneer iemand anders een versie uitbrengt. Een resultaat op modelniveau is alleen geldig voor de build die je hebt getest, en als je de versie en de datum niet hebt vastgelegd, heb je geen resultaat.

Hoe je een eerste opdracht afbakent

Opdrachten die slecht aflopen, hebben bijna altijd 'test de AI' als scope. Een scope die het contact met een planning overleeft, ziet er meer zo uit: één agent, in een stagingomgeving, met data en rechten die de vorm van productie hebben; een lijst van de vijf grenzen die ertoe doen (tenantisolatie, toegang tot inloggegevens, bestedingen, data-egress, bereik van tools); spelregels die benoemen wat buiten de grenzen valt; stopcondities die aangeven wie de run mag stilleggen; en een gedefinieerd bewijsformaat dat is afgesproken vóór de eerste poging, zodat het rapport wordt samengesteld uit artefacten in plaats van uit het geheugen te worden gereconstrueerd.

Autorisatie verdient een eigen zin, want het is het enige punt dat teams overslaan wanneer het doel hun eigen product is en de tools van iemand anders zijn. Een model testen dat je niet zelf beheert, op infrastructuur die niet van jou is, met prompts die zijn ontworpen om een veiligheidslaag te doorbreken, is een andere activiteit dan je eigen deployment testen — en de schriftelijke scope is wat de twee scheidt. De verificatiepoort waarop onze eigen cyberafdeling draait, bestaat om dezelfde reden: geautoriseerd beveiligingswerk op modelniveau vereist een benoemde, verantwoordelijke partij aan beide kanten.

Wat het incidentrecord toevoegt

Een red team-run vertelt je wat je doelwit doet. Het kan je niet vertellen wat er in het veld gebeurt, en het veld is waar het argument voor een beheersmaatregel daadwerkelijk wordt gemaakt. Dat is de kloof die een incidentenregister vult — en de discipline die het oplegt is het nuttige deel: een registratie zonder ten minste één bron bestaat niet, en een registratie zonder een schadeoordeel is geen incident.

Lees de twee artefacten samen, en de lus sluit zich. Het red team produceert een reproduceerbare bevinding en benoemt de beheersmaatregel die deze zou hebben tegengehouden. Het verslag vertelt je of iemand in het veld die grens al heeft geraakt, wat de schade was, en of de beheersmaatregel elders standhield. Een bevinding zonder precedent in het veld is een hypothese die het waard is om te verhelpen; een incident in het veld zonder reproduceerbare bevinding is een bug die je nog niet kunt sluiten. Teams die dit goed doen, behandelen 'we hebben het model door een red team laten testen' niet langer als een op te leveren product, maar als één invoer voor een eigen register.

Wat ons bij de eerlijke slotopmerking brengt. AI-redteamingswerk levert geen veiligheidsgarantie op, en elk traject dat als zodanig wordt verkocht, verkoopt het verkeerde. Het levert een reeks grenzen op waarvan je nu weet dat ze worden overschreden, met bewijs dat je opnieuw kunt uitvoeren, geordend naar wat er gebeurt wanneer ze worden overschreden. Dat is genoeg om beslissingen op te baseren — en aanzienlijk meer dan een presentatie.