Purple teaming voor AI

Samenwerkingsoefeningen tussen aanval en verdediging voor AI-systemen: het structureren van purple team-engagements, realtime kennisoverdracht, gezamenlijke aanvalssimulatie en het meten van defensieve verbetering via iteratief testen.

Traditionele redteaming is adversarial: het red team valt aan, het blue team verdedigt en bevindingen worden gedeeld nadat de engagement eindigt. Purple teaming haalt die tijdlijn weg. Aanval en verdediging gebeuren tegelijk, met realtime kennisoverdracht die zowel offensieve ontdekking als defensieve verbetering versnelt.

Voor AI-systemen is purple teaming bijzonder waardevol omdat AI-verdedigingen vaak realtime aan te passen zijn: system prompts kunnen worden herschreven, guardrail-classifiers kunnen worden hertraind en output-filters kunnen worden bijgewerkt zonder dat het onderliggende model opnieuw uitgerold hoeft te worden. Dit maakt een snelle cyclus van itereren en testen mogelijk die de traditionele infrastructuurbeveiliging niet kan evenaren.

Waarom purple teaming voor AI

Het snelheidsvoordeel

AI-verdedigingen zijn vaak binnen enkele minuten aan te passen en te testen:

Deze snelle doorlooptijd maakt realtime samenwerkingstesten praktisch haalbaar. Het red team demonstreert een aanval, het blue team implementeert een verdediging en het red team test direct of de verdediging standhoudt.

Het voordeel van kennisoverdracht

Bij traditionele redteaming worden bevindingen weken na de ontdekking in een rapport opgeleverd. Tegen die tijd is de context verloren, kan het systeem zijn veranderd en moet het verdedigende team het aanvalsscenario reconstrueren op basis van documentatie. Purple teaming elimineert die kloof:

• Verdedigers zien aanvallen realtime en begrijpen de methodologie van de aanvaller
• Aanvallers zien geïmplementeerde verdedigingen en kunnen direct hun effectiviteit beoordelen
• Beide teams ontwikkelen intuïtie voor de aanval-verdedigingsdynamiek die specifiek is voor hun systeem
• Nieuwe defensieve benaderingen kunnen direct worden getest in plaats van theoretisch te blijven

Structuur van oefeningen

Formaatopties

Structuur van een sprintsessie

Een typische sprintsessie van 3 uur:

Uur 1: Baseline-assessment (red team leidt)

1. Het red team demonstreert 3-5 aanvalstechnieken tegen het huidige systeem
2. Het blue team observeert en maakt aantekeningen over welke aanvallen slagen en waarom
3. Beide teams bespreken het aanvalsoppervlak en prioriteren welke bypasses als eerste worden aangepakt

Uur 2: Implementatie van verdedigingen (blue team leidt)

1. Het blue team implementeert verdedigingen voor de bypasses met de hoogste prioriteit
2. Het red team geeft input over de vraag of voorgestelde verdedigingen de aanval daadwerkelijk blokkeren of slechts een kleine variatie afdwingen
3. Verdedigingen worden uitgerold naar de testomgeving

Uur 3: Validatie en iteratie (gezamenlijk)

1. Het red team test opnieuw met de verdedigingen op hun plek
2. Voor elke verdediging: werkt de oorspronkelijke aanval nog steeds? Kunnen simpele variaties hem omzeilen?
3. Het blue team past verdedigingen aan op basis van validatieresultaten
4. Laatste testronde om verbeteringen te bevestigen
5. Beide teams documenteren bevindingen, defensieve verbeteringen en resterende gaten

Structuur van een dagoefening

Een hele dag voegt diepte toe:

Ochtend: verkenning en baseline

• Het red team voert verkenning uit en brengt het huidige aanvalsoppervlak in kaart
• Het blue team licht bestaande verdedigingen, bekende beperkingen en recente wijzigingen toe
• Gezamenlijke threat-modelingsessie om testgebieden te prioriteren

Middag: aanval-verdedigingsronden

• Drie iteratieve rondes van aanval, implementatie van verdediging en validatie
• Elke ronde richt zich op een andere aanvalscategorie (bijv. ronde 1: directe injection, ronde 2: misbruik van tools, ronde 3: data-exfiltratie)
• Volg de metrieken: initiële bypass-rate, bypass-rate na verdediging, implementatietijd van verdedigingen

Late middag: gevorderde scenario's en afronding

• Het red team probeert gecombineerde/geketende aanvallen met technieken uit alle categorieën
• Het blue team beoordeelt of de interactie tussen verdedigingen nieuwe kwetsbaarheden creëert
• Gezamenlijke debrief waarin verbeteringen, resterende gaten en actiepunten worden gedocumenteerd

AI-specifieke oefenscenario's

Scenario 1: system prompt verharden

Doel: Een system prompt iteratief verharden tegen injection-aanvallen.

Ronde 1: Het red team test de baseline-system-prompt met vijf injection-technieken. Leg de bypass-rates vast.

Ronde 2: Het blue team herschrijft de system prompt met anti-override-formuleringen, rolbevestiging en herhaling van instructies. Het red team test opnieuw.

Ronde 3: Het red team past technieken aan (langere payloads, formaat-imitatie, multi-turn). Het blue team voegt input-classificatie toe. Hertesten.

Ronde 4: Het red team combineert encoding met injection om de classifier te ontwijken. Het blue team voegt input-normalisatie toe. Hertesten.

Metriek: Volg de afname van de bypass-rate over de ronden. Een geslaagde oefening laat afnemende bypass-rates per iteratie zien.

Scenario 2: guardrails omzeilen en verharden

Doel: Input-/output-guardrail-classifiers testen en verbeteren.

Ronde 1: Red team identificeert technieken om guardrails te omzeilen
         (encoding, parafrasering, indirecte verwijzing)
  ↓
Ronde 2: Blue team hertraint de classifier met de bypass-voorbeelden
         van het red team als trainingsdata
  ↓
Ronde 3: Red team genereert nieuwe bypass-varianten die niet door de
         hertraining gedekt zijn
  ↓
Ronde 4: Blue team voegt structurele detectie toe (niet alleen content)
         om nieuwe varianten te vangen
  ↓
Herhaal tot de bypass-rate zich stabiliseert op een acceptabel niveau

Scenario 3: testen van tool-autorisatie

Doel: Valideren dat tool-autorisatiecontroles voorkomen dat injection misbruik veroorzaakt.

• Het red team probeert via prompt injection ongeautoriseerde tools aan te roepen
• Het blue team implementeert en tunet de regels voor tool-autorisatie
• Beide teams brengen de volledige set tool-acties in kaart die via injection bereikbaar is
• Herhaal totdat alle ongeautoriseerde toegangspaden voor tools zijn geblokkeerd of menselijke goedkeuring vereisen

Scenario 4: oefening rond vertrouwensgrenzen in multi-agent

Doel: Vertrouwensgrenzen in multi-agent-architecturen testen.

• Het red team probeert privileges te escaleren via overdrachten tussen agents
• Het blue team implementeert contextsanitatie tussen agents
• Test of sanitatie naast aanvallen ook legitieme informatieoverdracht blokkeert
• Itereer om de balans te vinden tussen veiligheid en functionaliteit

Verbetering meten

Kwantitatieve metrieken

Volg deze metrieken over purple team-oefeningen om voortgang te meten:

Kwalitatieve metrieken

• Score voor kennisoverdracht: Kan het blue team uitleggen waaróm elke aanval werkt, niet alleen dát hij werkt?
• Defensieve creativiteit: Ontwikkelt het blue team nieuwe verdedigingen of patcht het alleen specifieke aanvalspatronen?
• Aanvalsdiversiteit: Breidt het red team techniekcategorieën uit of herhaalt het bekende benaderingen?
• Kwaliteit van samenwerking: Delen beide teams productief inzichten of werken ze parallel langs elkaar?

Voortgang volgen in de tijd

Oefening 1 (januari):
  Directe injection-baseline:   85% bypass-rate
  Na oefening:                  40% bypass-rate
  Verbetering:                  45 procentpunten

Oefening 2 (februari):
  Directe injection:            35% bypass-rate (gehandhaafd uit O1)
  Multi-turn injection:         70% bypass-rate (nieuwe categorie)
  Multi-turn na oefening:       30% bypass-rate
  Verbetering:                  40 procentpunten

Oefening 3 (maart):
  Directe injection:            30% bypass-rate (verdere verbetering)
  Multi-turn injection:         25% bypass-rate (gehandhaafd uit O2)
  Encoding-bypass:              60% bypass-rate (nieuwe categorie)
  Encoding na oefening:         20% bypass-rate
  Algemene trend:               Afnemende baseline-bypass-rates
                                in alle categorieën

Teamsamenstelling en rollen

Rollen in een purple team

Communicatieprotocollen

Effectieve purple teaming vereist gestructureerde communicatie:

Realtime narratie. Het red team verwoordt zijn aanpak: "Ik ga een delimiter-escape proberen met XML-tag-closure. De hypothese is dat de system prompt user input in XML-tags wikkelt."

Onderbouwing van verdediging. Het blue team legt zijn defensieve logica uit: "Ik voeg input-sanitatie toe die afsluitende XML-tags uit user input strippt. Dit zou de tag-closure-techniek moeten voorkomen, maar kan legitieme XML-content breken."

Eerlijke beoordeling. Beide teams moeten openhartig zijn. Voelt een verdediging broos? Zeg het. Steunt een aanval op een onrealistische randvoorwaarde? Erken dat.

Veelvoorkomende anti-patronen

Verdediging op één specifieke patch. Het blue team fixt alleen de exacte payload die het red team toonde. De fix zou moeten generaliseren naar de aanvalscategorie, niet alleen die specifieke payload.

Tunnelvisie bij het red team. Het red team blijft variaties van één techniek proberen in plaats van te wisselen naar andere aanvalscategorieën. Breedte is even belangrijk als diepte.

De "waarom"-discussie overslaan. Een verdediging implementeren zonder te bespreken waarom de aanval werkte. Begrip van de root cause levert robuustere verdedigingen op.

Geen baseline-meting. De oefening starten zonder de initiële bypass-rate te meten. Zonder baseline is verbetering niet kwantificeerbaar.

Overfilteren. Zulke agressieve verdedigingen implementeren dat legitieme gebruikersverzoeken geblokkeerd worden. Meet altijd de false positive-rate naast de bypass-rate.

Probeer het zelf

Verwante onderwerpen

• Red team-methodologie - Het overkoepelende engagement-framework
• Continue redteaming - Purple teaming-principes toegepast op doorlopende programma's
• Bewijsverzameling - Bevindingen vastleggen tijdens oefeningen
• Guardrails en filtering - Verdedigingen die in purple-oefeningen worden getest en verbeterd

Referenties

• Oakley, C. (2019). "Purple Team Field Manual" - Fundamentele purple team-methodologie
• MITRE (2024). ATLAS - Adversarial Threat Landscape for AI Systems
• Anthropic (2024). "Challenges in Red Teaming AI Systems"
• Microsoft (2024). "Planning Red Teaming for Large Language Models and Their Applications"
• OWASP (2025). OWASP Top 10 for LLM Applications