Overzicht van red team-methodologie

Een gestructureerde methodologie voor AI-red team-opdrachten: fasen, deliverables, roldefinities en hoe AI-specifiek testen verschilt van traditionele penetratietesten.

AI-redteaming past traditioneel adversarieel beveiligingstesten aan op de unieke kenmerken van AI-systemen. Waar een traditionele penetratietest zoekt naar softwarekwetsbaarheden en misconfiguraties, evalueert een AI-red team of een systeem gemanipuleerd kan worden via de natural language-interface, de training-datapijplijn, de tool-integraties of de agentic besluitvorming. De methodologie moet rekening houden met stochastisch gedrag, prompt-level aanvalsoppervlakken en schade die semantisch in plaats van technisch is.

Hoe AI-redteaming verschilt

Voordat we de methodologie induiken, helpt het te begrijpen wat AI-redteaming onderscheidt van traditioneel penetratietesten:

Engagement-fasen

Een AI-red team-opdracht volgt een gestructureerde reeks fasen. Elke fase levert specifieke deliverables die de volgende voeden.

Fase 1: Scoping en Rules of Engagement

Doel: Vastleggen wat getest wordt, hoe en welke beperkingen gelden.

Activiteiten:

• Identificeer het te testen AI-systeem: modelprovider, deployment-architectuur, gebruikersinterfaces, tool-integraties, gegevensbronnen
• Definieer scope-grenzen: welke componenten, aanvalsvectoren en schadecategorieën vallen binnen scope
• Stel rules of engagement op: rate limits, verboden technieken, escalatieprocedures, gegevensverwerkingseisen
• Stem met stakeholders succescriteria en ernstclassificatie af

Deliverable: Ondertekend rules of engagement-document en gedetailleerd testplan.

Zie Scoping & Rules of Engagement voor gedetailleerde richtlijnen.

Fase 2: Verkenning

Doel: Het aanvalsoppervlak van het AI-systeem in kaart brengen voor exploitatiepogingen.

Activiteiten:

• Fingerprint de modelprovider en -versie via gedragsanalyse
• Extraheer of leid de systeemprompt af
• Inventariseer beschikbare tools, plugins en externe integraties
• Identificeer gegevensbronnen (RAG-kennisbanken, webtoegang, file uploads)
• Breng vertrouwensgrenzen tussen componenten in kaart
• Ontdek shadow AI-implementaties als de scope organisatorische ontdekking omvat

Deliverable: Kaart van het aanvalsoppervlak waarin alle geïdentificeerde componenten, vertrouwensgrenzen en potentiële aanvalsvectoren zijn gedocumenteerd.

Zie Geavanceerde verkenning voor technieken.

Fase 3: Dreigingsmodellering

Doel: Testen prioriteren op basis van risicoanalyse.

Activiteiten:

• Bouw attack trees voor doelen met hoge waarde
• Koppel ATLAS-tactieken en -technieken aan het geïdentificeerde aanvalsoppervlak
• Analyseer vertrouwensgrenzen en datastromen op injectiemogelijkheden
• Schat kosten en waarschijnlijkheid in voor elk aanvalspad
• Prioriteer paden op basis van risico (waarschijnlijkheid maal impact)

Deliverable: Geprioriteerd testplan afgeleid van het dreigingsmodel.

Zie AI-specifieke dreigingsmodellering voor frameworks.

Fase 4: Exploitatie

Doel: Het geprioriteerde testplan uitvoeren en proberen geïdentificeerde risico's aan te tonen.

Activiteiten:

• Test prompt injection-vectoren (direct, indirect, multi-turn, encoding)
• Probeer bypasses van veiligheids-alignment (jailbreaken)
• Probe tool- en function calling op parameter-injection en niet-geautoriseerde toegang
• Test op data-exfiltratie via modelgemedieerde kanalen
• Evalueer bias, eerlijkheid en het genereren van schadelijke uitvoer
• Test de grenzen van agent-autonomie en escalatiepaden
• Documenteer elke test met inputs, outputs, bypass-percentages en reproduceerbaarheidsdata

Deliverable: Logboek met ruwe bevindingen en volledige bewijsketen voor elke ontdekte kwetsbaarheid.

Fase 5: Bewijsverzameling en documentatie

Doel: Een compleet, reproduceerbaar bewijspakket produceren.

Activiteiten:

• Leg volledige gesprekslogs vast voor elke bevinding
• Registreer API-requests en responses met timestamps
• Documenteer bypass-percentages over meerdere pogingen (minimaal 10 trials per techniek)
• Bewaar modelversie, temperature-instellingen en andere configuratiedetails
• Maak proof-of-concept-payloads die opnieuw uitvoerbaar zijn voor verificatie

Deliverable: Bewijspakket dat voldoet aan chain-of-custody-eisen.

Zie Bewijsverzameling voor standaarden.

Fase 6: Rapportage

Doel: Bevindingen op actionable wijze communiceren aan stakeholders.

Activiteiten:

• Classificeer bevindingen op ernst volgens het afgesproken framework
• Schrijf bevindings-beschrijvingen met duidelijke impactstatements
• Geef remediatie-aanbevelingen voor elke bevinding
• Produceer een management-samenvatting voor niet-technische stakeholders
• Voer een bevindingen-walkthrough uit met het technische team

Deliverable: Eindrapport met management-samenvatting, gedetailleerde bevindingen en remediatie-roadmap.

Teamsamenstelling

Effectieve AI-redteaming vereist een combinatie van vaardigheden die zelden in één persoon bestaat:

Opdrachttypes

Verschillende opdrachttypes vragen om verschillende methodologische accenten:

Veiligheidsevaluatie

Focus op alignment-bypasses, generatie van schadelijke content en bias-testen. Sterke nadruk op creatieve prompt engineering en het ontdekken van edge cases. Wordt vaak uitgevoerd vóór modeldeployment.

Application security-beoordeling

Focus op prompt injection, data-exfiltratie, toolmisbruik en privilege escalation in een uitgerolde applicatie. Combineert AI-specifiek testen met traditioneel application security-testen.

Beoordeling van agentic systemen

Focus op grenzen van tool use, autonome besluitvorming, vertrouwen tussen meerdere agents en escalatiepaden. Vereist begrip van de agent-architectuur en tool-integraties. Zie Misbruik van agents voor technieken.

Continue redteaming

Doorlopend testprogramma in plaats van een opdracht op een vast moment. Geautomatiseerd testen gecombineerd met periodieke handmatige beoordelingen. Zie Continue redteaming voor programmaopzet.

Methodologische anti-patronen

Veelvoorkomende fouten die de effectiviteit van een AI-red team verminderen:

Ad-hoc testen zonder dreigingsmodellering. Direct beginnen met "wat prompts proberen" zonder de systeemarchitectuur, vertrouwensgrenzen of paden met het hoogste risico te begrijpen. Dit leidt tot oppervlakkige dekking en gemiste kritieke kwetsbaarheden.

Binaire geslaagd/gefaald-rapportage. Rapporteren dat een techniek "niet werkt" na een paar mislukte pogingen. AI-systemen zijn stochastisch; een techniek die 9 keer faalt en 1 keer slaagt vertegenwoordigt een echte kwetsbaarheid die met het bypass-percentage gerapporteerd moet worden.

De applicatielaag negeren. Je uitsluitend richten op het model en traditionele webkwetsbaarheden in de omhullende applicatie missen. API-authenticatie, rate limiting, input-validatie en sessiebeheer beïnvloeden allemaal de beveiligingshouding van het AI-systeem.

Alleen het happy path van aanvallen testen. De meest gangbare injectietechnieken proberen en stoppen zodra ze falen. Geavanceerde aanvallers in de praktijk combineren technieken, passen zich aan verdedigingen aan en houden vol ondanks mislukkingen.

Verkenning overslaan. Proberen te exploiteren zonder eerst te begrijpen welk model, welke versie, welke systeemprompt en welke tools in gebruik zijn. Verkenningsbevindingen veranderen drastisch welke aanvalstechnieken het meest effectief zijn.

Probeer het zelf

Gerelateerde onderwerpen

• Scoping & Rules of Engagement - Gedetailleerde scoping-richtlijnen
• Geavanceerde verkenning - Verkenningstechnieken voor AI-doelwitten
• AI-specifieke dreigingsmodellering - Dreigingsmodellerings-frameworks
• Bewijsverzameling - Bewijsstandaarden
• Continue redteaming - Opzet van een doorlopend programma

Referenties

• MITRE (2024). ATLAS - Adversarial Threat Landscape for AI Systems
• NIST (2024). AI Risk Management Framework (AI RMF 1.0)
• OWASP (2025). OWASP Top 10 for LLM Applications
• Anthropic (2024). "Challenges in Red Teaming AI Systems"
• Microsoft (2024). "AI Red Team Best Practices"