Scoping en rules of engagement
Scope, rules of engagement, autorisatiegrenzen en succescriteria definiëren voor AI-redteamopdrachten, met sjablonen en checklists voor veelvoorkomende opdrachttypes.
Scoping en rules of engagement (ROE) bepalen wat een AI-red team mag testen, hoe ze dat mogen doen en welke beperkingen er gelden. Slechte scoping leidt óf tot onvolledig testen (te smal) óf tot operationele incidenten (te breed). Voor AI-systemen moet scoping aandachtspunten adresseren die in traditionele pentesten niet bestaan: het stochastische karakter van modelgedrag, het risico dat je tijdens het testen daadwerkelijk schadelijke content genereert, rate limits op inference-API's en het onderscheid tussen testen op modelniveau en op applicatieniveau.
Scope-definitie
Scope-componenten
Een scope voor een AI-red team moet elk van de volgende punten specificeren:
| Component | Wat te definiëren | Voorbeeld |
|---|---|---|
| Doelsysteem | De specifieke AI-applicatie, het model en de versie die getest worden | "Klantgerichte chatbot op support.example.com die GPT-4o gebruikt via Azure OpenAI" |
| Aanvalsvectoren | Welke injectietypes, jailbreak-categorieën en exploitatietechnieken binnen scope vallen | "Directe injectie, indirecte injectie via RAG, misbruik van tools; gradient-based aanvallen buiten scope" |
| Schadecategorieën | Welke typen schadelijke output het team mag proberen te ontlokken | "CSAM, geweld, zelfbeschadiging, PII-lekken, bias — volgens OWASP LLM Top 10" |
| Infrastructuur | Of onderliggende infrastructuur (API's, databases, cloudservices) binnen scope valt | "Alleen applicatielaag; cloudinfrastructuur buiten scope" |
| Datagevoeligheid | Of echte gebruikersdata, PII of productiedata mag worden benaderd of gegenereerd | "Alleen synthetische testdata; geen echte klantdata in prompts" |
| Gebruikersrollen | Welke gebruikersrollen en toegangsniveaus getest worden | "Anonieme gebruiker, ingelogde standaardgebruiker, admin-gebruiker" |
| Integraties | Welke tool-integraties, plugins en externe services binnen scope vallen | "Kennisbank-RAG, ticket-aanmaak-API; e-mailintegratie buiten scope" |
Scope-niveaus
AI-redteamopdrachten vallen doorgaans in een van drie scope-niveaus:
Niveau 1: Model-assessment. Testen van de veiligheidsalignment en gedragsgrenzen van het model. Richt zich op prompt injection, jailbreaken en het genereren van schadelijke content. Test geen controls op applicatieniveau.
Niveau 2: Applicatie-assessment. Testen van de volledige applicatie inclusief het model, de system prompt, input/output-filters, tool-integraties en gebruikersinterface. Dit is het meest voorkomende opdrachttype.
Niveau 3: Full-stack-assessment. Testen van de complete AI-systeemstack van infrastructuur tot model tot applicatie. Omvat naast testen op modelniveau ook API-beveiliging, authenticatie, infrastructuurconfiguratie, trainingspijplijn en deployment-beveiliging.
Rules of engagement
AI-specifieke ROE-overwegingen
Naast standaard ROE voor pentesten vraagt AI-redteaming om aanvullende regels:
Rate limiting en kostenbeheersing. API-inferencecalls kosten geld. Definieer:
- Maximum aantal API-calls per uur/dag
- Maximum aantal tokens dat per opdracht verbruikt mag worden
- Wie de inferencekosten betaalt (klant of testorganisatie)
- Of throttling of batching verplicht is
Omgang met schadelijke content. Testen op het genereren van schadelijke content levert een dilemma op: het red team moet de schade aantonen, maar de gegenereerde content ook verantwoord verwerken. Definieer:
- Hoe schadelijke output wordt vastgelegd en opgeslagen
- Wie toegang heeft tot bewijsmateriaal dat schadelijke content bevat
- Bewaar- en vernietigingsschema's voor schadelijke content
- Of schadelijke content in rapporten opgenomen mag worden (geredigeerd of volledig)
- Specifieke contentcategorieën die zelfs tijdens testen niet gegenereerd mogen worden
Grenzen aan modelinteractie. Definieer:
- Of het team modelgedrag mag proberen aan te passen (fine-tuning, RLHF-manipulatie)
- Of adversarial trainingsdata of poisoning-pogingen binnen scope vallen
- Of weight-extractie of pogingen tot modeldiefstal geautoriseerd zijn
- Maximum gesprekslengte en aantal gelijktijdige sessies
Productie versus staging. Definieer:
- Of testen op productie- of stagingsystemen plaatsvindt
- Of echte gebruikers tijdens het testen geraakt mogen worden
- Tijdvensters voor testen (kantooruren, daarbuiten)
- Rollback-procedures als testen onverwachte gedragsveranderingen veroorzaakt
Autorisatieketen
Autorisatie voor AI-redteaming vraagt om akkoord van meer stakeholders dan bij traditionele pentesten:
| Stakeholder | Wat zij autoriseren | Waarom ze nodig zijn |
|---|---|---|
| Systeemeigenaar | Algemene testautorisatie | Standaard pentest-autorisatie |
| AI/ML-teamlead | Testen op modelniveau, sonderen van veiligheidsgrenzen | Begrijpt de modelcapaciteiten en risico's |
| Juridische afdeling | Genereren van schadelijke content, dataverwerking | Aansprakelijkheid voor het genereren/opslaan van schadelijke content |
| Privacy officer | PII-verwerking, datastromen tijdens testen | Gebruikersdata kan door de geteste AI-systemen stromen |
| API-provider (indien van toepassing) | Testen tegen hun API | Provider-ToS kan adversarial testen beperken |
| CISO / security lead | Infrastructuurscope, escalatieprocedures | Security-governance |
Escalatieprocedures
Definieer duidelijke escalatietriggers:
| Trigger | Actie | Wie informeren |
|---|---|---|
| Kritieke kwetsbaarheid (data-exfiltratie, codeuitvoering via tools) | Direct stoppen en melden | Opdrachtleider, systeemeigenaar, CISO |
| Schadelijke content gegenereerd die echt risico oplevert | Stop met testen in die categorie, stel bewijs veilig | Opdrachtleider, juridische afdeling |
| Onverwacht modelgedrag (persistente persoonlijkheidsveranderingen, recursieve tool-calls) | Pauzeren en beoordelen | AI/ML-teamlead |
| Rate limit overschreden of onverwachte kostenstijging | Pauzeer het testen | Systeemeigenaar, opdrachtleider |
| Toegang tot echte gebruikersdata tijdens testen | Direct stoppen, blootstelling documenteren | Privacy officer, systeemeigenaar, juridisch |
Succescriteria
"Succes" definiëren voor AI-redteaming
Anders dan bij traditionele pentesten, waar succes vaak binair is (heb je het doelwit overgenomen?), werkt AI-redteaming op een glijdende schaal. Definieer succescriteria langs meerdere dimensies:
Dekkingsmetrics:
- Percentage van de OWASP LLM Top 10-categorieën dat getest is
- Aantal aanvalsvectoren dat per scope-component getest is
- Aantal unieke technieken dat per vector geprobeerd is
Bevindingenmetrics:
- Aantal en ernst van de bevindingen
- Bypass-percentages voor elke techniekcategorie
- Percentage veiligheidsgrenzen dat met succes is doorbroken
Kwaliteitsmetrics:
- Alle bevindingen reproduceerbaar met gedocumenteerd bewijs
- Mitigatie-aanbevelingen voor elke bevinding
- Severity-classificaties afgestemd op de bedrijfsimpact
Severity-framework
Spreek de severity-classificatie af voordat het testen begint:
| Severity | Criteria | Voorbeeld |
|---|---|---|
| Kritiek | Betrouwbare exploitatie met hoge impact; data-exfiltratie, codeuitvoering of een veiligheidsbypass die alle gebruikers raakt | System prompt injection waardoor de chatbot betrouwbaar willekeurige tool-calls uitvoert en klantdata exfiltreert |
| Hoog | Matige betrouwbaarheid met aanzienlijke impact, of hoge betrouwbaarheid met matige impact | Jailbreak-techniek die in 60% van de gevallen contentfilters omzeilt en schadelijke instructies genereert |
| Gemiddeld | Lage betrouwbaarheid met aanzienlijke impact, of matige betrouwbaarheid met beperkte impact | Encoding-bypass die in 20% van de gevallen werkt om de system prompt te extraheren |
| Laag | Lage betrouwbaarheid en beperkte impact; informatieve bevindingen | Het model onthult zijn provider en versie als je er direct naar vraagt |
| Informatief | Geen directe exploitatie maar wijst op een verdediging-zwakte | System prompt bevat geen anti-override-taal |
Opdrachtdocumentatie
Sjabloon voor testplan
Een testplan moet het volgende bevatten:
- Opdrachtoverzicht: doelsysteem, scope-niveau, planning, teamsamenstelling
- Scope-details: componenten binnen scope, uitsluitingen buiten scope, geautoriseerde aanvalsvectoren
- Rules of engagement: rate limits, omgang met schadelijke content, escalatieprocedures
- Testmatrix: specifieke testcases geordend per aanvalsvector en doelcomponent
- Succescriteria: dekkings-, bevindingen- en kwaliteitsmetrics
- Bewijsvereisten: wat per bevinding vastgelegd moet worden
- Rapportage-deliverables: rapportageformaat, doelgroep, leveringsplanning
Pre-engagement-checklist
Verifieer voordat het testen begint:
- Autorisatiedocument ondertekend door alle vereiste stakeholders
- Servicevoorwaarden van de API-provider beoordeeld en nageleefd
- Testaccounts en credentials klaargezet
- Stagingomgeving beschikbaar (indien van toepassing)
- Rate limits en kostenplafonds ingesteld
- Opslag voor bewijsmateriaal met passende toegangscontroles ingericht
- Escalatiecontacten gecontroleerd en bereikbaar
- Communicatiekanaal opgezet met de systeemeigenaar
- Procedures voor omgang met schadelijke content gedocumenteerd en bevestigd
- Team gebriefed over scope-grenzen en verboden handelingen
Probeer het zelf
Gerelateerde onderwerpen
- Redteam-methodologie - De algehele opdrachtcyclus
- AI-specifieke dreigingsmodellering - Dreigingsmodellen die de scope onderbouwen
- Bewijsverzameling - Standaarden voor het vastleggen en bewaren van bevindingen
- Continue redteaming - Hoe scoping zich aanpast voor doorlopende programma's
Referenties
- NIST (2024). AI Risk Management Framework (AI RMF 1.0)
- OWASP (2025). OWASP Top 10 for LLM Applications
- PTES (2024). Penetration Testing Execution Standard - Pre-Engagement
- CREST (2024). CREST Penetration Testing Guide
Waarom vereist AI-redteamscoping naast autorisatie van de systeemeigenaar ook autorisatie van een API-provider?