AI Red Team Scoping Checklist Walkthrough

Systematic walkthrough of the pre-engagement scoping process for AI red team assessments: stakeholder identification, target enumeration, scope boundary definition, resource estimation, and rules of engagement documentation.

Scoping is the most consequential phase of a red team engagement. A poorly scoped engagement wastes time on low-value targets, misses critical attack surfaces, produces findings the client cannot act on, or creates legal exposure through ambiguous authorization. This walkthrough provides a systematic checklist that ensures nothing is missed.

Work through each section sequentially. Check off items as you complete them. Items marked with a star are critical path items that must be resolved before the engagement can begin.

Phase 1: Stakeholder Identification

Before defining what to test, identify who needs to be involved in the scoping process and who will receive results.

1. 1

   Identify Key Contacts

   Complete this contact matrix:

   # Stakeholder Contact Matrix
    
   | Role | Name | Email | Phone | Availability |
   |------|------|-------|-------|--------------|
   | Engagement sponsor | | | | |
   | Technical point of contact | | | | |
   | ML/AI team lead | | | | |
   | Security team lead | | | | |
   | Legal/compliance contact | | | | |
   | Incident escalation contact | | | | |
   | Report recipient(s) | | | | |

   Checklist:

   • Engagement sponsor identified (person authorizing the work)
   • Technical POC identified (person who can answer architecture questions)
   • ML/AI team lead identified (person who understands model configuration)
   • Security team lead identified (person who knows existing controls)
   • Legal/compliance contact identified (if applicable)
   • Escalation path defined (who to contact if a critical issue is found)
   • Report distribution list confirmed
   • Communication channel established (Slack, email, secure channel)
2. 2

   Clarify Authorization

   Critical path items:

   • * Written authorization obtained from engagement sponsor
   • * Scope of authorization clearly defined (what is authorized, what is not)
   • * Authorization covers all environments being tested (prod, staging, dev)
   • * Time boundaries specified (start date, end date, allowed hours)
   • * Third-party authorization obtained (if testing involves third-party AI services)

   Provider testing policies to review:

   Provider	Testing Policy	Notification Required?
   OpenAI	Terms of use Section 2	No, but rate limits apply
   Azure OpenAI	Azure penetration testing rules	Yes, submit form
   AWS Bedrock	AWS penetration testing policy	No longer required for most services
   Google Vertex AI	GCP penetration testing policy	No longer required
   Anthropic	Acceptable use policy	No, but rate limits apply

Phase 2: Target Enumeration

Systematically enumerate every AI component that could be in scope.

1. 1

   Model Inventory

   Document every model in the system:

   # Model Inventory
    
   | # | Model Name | Provider | Version | Type | Purpose | User-Facing? |
   |---|-----------|----------|---------|------|---------|--------------|
   | 1 | | | | Chat/Completion/Embedding | | Yes/No |
   | 2 | | | | | | |

   Checklist:

   • All production models enumerated
   • Model providers and versions documented
   • Fine-tuned vs. base model status confirmed
   • Model access method documented (API, local, hybrid)
   • Embedding models included (often overlooked)
   • Moderation/classifier models included
   • Models in staging/development that may reach production identified
2. 2

   System Architecture Components

   Map all components that interact with or support the AI models:

   # Component Inventory
    
   ## Input Processing
   - [ ] Frontend interface (web, mobile, API)
   - [ ] Input validation layer
   - [ ] Rate limiting implementation
   - [ ] Authentication/authorization mechanism
   - [ ] Content preprocessing (tokenization, formatting)
    
   ## Model Infrastructure
   - [ ] Model hosting platform (cloud service, self-hosted)
   - [ ] System prompt management (static, dynamic, templated)
   - [ ] Temperature and parameter configuration
   - [ ] Streaming vs. batch inference
   - [ ] Model fallback/failover configuration
    
   ## Data Integration
   - [ ] RAG/knowledge base connections
   - [ ] Database connections
   - [ ] File upload/processing capabilities
   - [ ] External API integrations
   - [ ] Vector store/embedding database
    
   ## Tool Use / Function Calling
   - [ ] Available function definitions
   - [ ] Function permission model
   - [ ] External service connections
   - [ ] Result validation for tool outputs
    
   ## Output Processing
   - [ ] Output filtering/content moderation
   - [ ] PII detection and redaction
   - [ ] Response formatting and truncation
   - [ ] Citation/source attribution
    
   ## Monitoring and Logging
   - [ ] Inference logging configuration
   - [ ] Security alerting rules
   - [ ] Audit trail for model interactions
   - [ ] Cost monitoring and limits

3. 3

   Data Asset Identification

   Identify data assets that could be exposed, poisoned, or exfiltrated:

   # Data Asset Inventory
    
   | Asset | Classification | Location | AI Connection |
   |-------|---------------|----------|---------------|
   | Training data | | | Fine-tuning |
   | Knowledge base docs | | | RAG retrieval |
   | User conversation logs | | | History context |
   | System prompts | | | Model instruction |
   | Embedding vectors | | | Similarity search |
   | Feature store data | | | Model input |

   Checklist:

   • Training data source and classification identified
   • Knowledge base contents inventoried and classified
   • User data in conversation context documented
   • System prompt content documented (for testing purposes)
   • PII in any data assets identified
   • Data retention policies documented
   • Cross-tenant data isolation verified (for multi-tenant systems)

Phase 3: Scope Boundary Definition

Define exactly what is in scope, what is out of scope, and what requires special handling.

1. 1

   In-Scope Definition

   # In-Scope Targets
    
   ## Definitely In Scope
   - [ ] All user-facing AI interaction points
   - [ ] System prompt configurations
   - [ ] Content filtering/guardrail configurations
   - [ ] RAG/knowledge base connections and queries
   - [ ] Function calling/tool use capabilities
   - [ ] Authentication and authorization for AI endpoints
   - [ ] Rate limiting and abuse prevention
   - [ ] Logging and monitoring coverage
    
   ## Conditionally In Scope (requires explicit approval)
   - [ ] Production environment testing
   - [ ] Multi-tenant isolation testing
   - [ ] Training data/pipeline assessment
   - [ ] Model extraction attempts
   - [ ] Denial of service testing
   - [ ] Social engineering of operators

2. 2

   Out-of-Scope Definition

   Explicitly document what is NOT in scope to prevent scope creep:

   # Out-of-Scope Items
    
   - [ ] Third-party model provider infrastructure (e.g., OpenAI's servers)
   - [ ] Network infrastructure not related to AI systems
   - [ ] Physical security
   - [ ] Non-AI application components (unless they interact with AI)
   - [ ] Other client systems not involved in the AI pipeline
   - [ ] [Add client-specific exclusions]

3. 3

   Testing Constraints

   Document constraints on how testing is conducted:

   # Testing Constraints
    
   ## Technical Constraints
   - Maximum requests per minute: ___
   - Maximum tokens per request: ___
   - Maximum concurrent sessions: ___
   - Allowed API endpoints: ___
   - Prohibited API operations: ___
    
   ## Timing Constraints
   - Testing window: ___ to ___ (dates)
   - Allowed hours: ___ to ___ (if restricted)
   - Blackout periods: ___
   - Maintenance windows to avoid: ___
    
   ## Behavioral Constraints
   - [ ] No testing that generates illegal content
   - [ ] No testing against real user data (use test accounts)
   - [ ] No persistence of client data on red team systems
   - [ ] No sharing of findings before report delivery
   - [ ] Immediate notification for critical findings: Yes/No
   - [ ] Critical finding notification path: ___

Phase 4: Engagement Type Selection

Based on the target inventory and client priorities, select the appropriate engagement type.

# Engagement Type Selection
 
## Option A: Prompt-Level Assessment
Focus: Prompt injection, jailbreaking, content policy bypass
Duration: 1-2 weeks
Best for: Initial assessments, applications with strong infrastructure security
Deliverable: Prompt-level vulnerability report
 
## Option B: Application-Level Assessment
Focus: Prompt attacks + API security + data integration testing
Duration: 2-3 weeks
Best for: Production applications with RAG or tool use
Deliverable: Comprehensive application security report
 
## Option C: Full-Stack Assessment
Focus: All layers from prompts to infrastructure to data pipelines
Duration: 3-5 weeks
Best for: Critical systems, pre-launch assessments, compliance requirements
Deliverable: Full security assessment with architecture recommendations
 
## Option D: Continuous Assessment
Focus: Ongoing monitoring with periodic manual testing
Duration: Ongoing (monthly or quarterly cycles)
Best for: Mature systems requiring sustained security posture
Deliverable: Periodic reports with trend analysis
 
Selected: ___
Justification: ___

Phase 5: Resource Estimation

Time Estimation

# Time Estimation
 
| Phase | Option A | Option B | Option C |
|-------|----------|----------|----------|
| Scoping & kickoff | 1 day | 1-2 days | 2-3 days |
| Reconnaissance | 1-2 days | 2-3 days | 3-5 days |
| Active testing | 3-5 days | 5-10 days | 10-15 days |
| Analysis & reporting | 1-2 days | 2-3 days | 3-5 days |
| **Total** | **1-2 weeks** | **2-3 weeks** | **3-5 weeks** |

Tool Requirements

# Tool Checklist
 
## Required for All Engagement Types
- [ ] HTTP proxy (Burp Suite or similar)
- [ ] Python 3.10+ with requests, openai SDK
- [ ] Note-taking and evidence collection system
- [ ] Secure file storage for findings
 
## Required for Application-Level+ Assessments
- [ ] Garak (automated vulnerability scanning)
- [ ] Promptfoo (eval-driven testing)
- [ ] PyRIT (orchestrated attacks) -- if multi-turn testing needed
- [ ] Ollama (local model testing)
 
## Optional / Advanced
- [ ] HarmBench (formal benchmarking)
- [ ] Inspect AI (structured evaluations)
- [ ] Custom automation scripts
- [ ] Cloud CLI tools (aws, az, gcloud) for platform assessments

Cost Estimation

# Cost Estimation
 
## API Costs
- Estimated requests: ___
- Average tokens per request: ___
- Model pricing: $___ per 1K tokens
- Estimated API cost: $___
 
## Tool Costs
- Burp Suite Professional: $449/year (if needed)
- Cloud compute for local model testing: $___
- Other tool licenses: $___
 
## Personnel
- Lead red teamer: ___ days x $___ /day
- Supporting analyst: ___ days x $___ /day
 
## Total Estimated Cost: $___

Phase 6: Rules of Engagement Document

Compile everything into a formal Rules of Engagement (ROE) document.

1. 1

   Draft the ROE

   # Rules of Engagement
   # AI Red Team Assessment
    
   ## 1. Engagement Overview
   - Client: ___
   - Red team lead: ___
   - Engagement type: ___
   - Start date: ___
   - End date: ___
   - Authorization reference: ___
    
   ## 2. Scope
   ### 2.1 In-Scope Targets
   [List from Phase 3]
    
   ### 2.2 Out-of-Scope Items
   [List from Phase 3]
    
   ### 2.3 Testing Constraints
   [Constraints from Phase 3]
    
   ## 3. Communication
   - Primary communication channel: ___
   - Status update frequency: ___
   - Critical finding notification: within ___ hours to ___
   - Emergency contact: ___
    
   ## 4. Testing Methodology
   - Automated scanning tools: [list]
   - Manual testing techniques: [list]
   - Attack categories to test: [list]
   - Evidence collection method: [screenshots, logs, recordings]
    
   ## 5. Data Handling
   - Client data on red team systems: [permitted/prohibited]
   - Evidence retention period: ___
   - Evidence destruction method: ___
   - NDA reference: ___
    
   ## 6. Deliverables
   - Interim findings (if applicable): ___
   - Draft report: ___
   - Final report: ___
   - Debrief meeting: ___
   - Retest (if applicable): ___
    
   ## 7. Signatures
   - Client authorized representative: ___ Date: ___
   - Red team lead: ___ Date: ___

2. 2

   Review and Sign-Off

   Checklist:

   • * ROE reviewed by red team lead
   • * ROE reviewed by client technical POC
   • * ROE reviewed by client legal/compliance (if applicable)
   • * ROE signed by engagement sponsor
   • * ROE signed by red team lead
   • * Signed copy distributed to all stakeholders
   • * Copy stored in engagement documentation system

Phase 7: Environment Preparation

Final preparation before testing begins.

# Environment Preparation Checklist
 
## Access Verification
- [ ] API keys or credentials received and tested
- [ ] VPN access configured (if required)
- [ ] Test accounts created and verified
- [ ] Access to monitoring dashboards confirmed (if provided)
- [ ] Access to relevant documentation confirmed
 
## Tool Setup
- [ ] All required tools installed and configured
- [ ] Target endpoints configured in tools
- [ ] Test connectivity verified
- [ ] Rate limiting tested (to understand limits before active testing)
 
## Documentation Setup
- [ ] Engagement folder created
- [ ] Evidence collection system prepared
- [ ] Time tracking started
- [ ] Initial reconnaissance notes template ready
 
## Team Preparation
- [ ] Team briefed on scope and constraints
- [ ] Escalation procedures reviewed
- [ ] Communication channels tested
- [ ] Kickoff meeting scheduled

Quick Reference: The Complete Checklist

For easy reference, here is the condensed checklist of all critical path items:

# AI Red Team Scoping - Critical Path Items
 
□ Engagement sponsor identified and available
□ Written authorization obtained
□ Authorization covers all environments
□ Third-party provider testing policies reviewed
□ All models enumerated with versions
□ System architecture components mapped
□ Data assets inventoried and classified
□ In-scope and out-of-scope boundaries defined
□ Testing constraints documented
□ Engagement type selected and justified
□ Time and cost estimates approved
□ Rules of engagement drafted
□ ROE signed by all parties
□ Access and credentials verified
□ Tools installed and configured
□ Team briefed and ready

Common Pitfalls

1. Starting testing before the ROE is signed. Even informal testing creates legal exposure. Do not send a single test request until authorization is documented.

2. Forgetting embedding models and classifiers. The primary chat model gets all the attention, but embedding models, moderation classifiers, and routing models are also attack surfaces.

3. Not accounting for API costs in the estimate. Clients are surprised by unexpected API charges from red team testing. Provide cost estimates upfront and set billing alerts.

4. Vague scope boundaries. "Test the chatbot" is not a scope. Specify endpoints, models, data sources, authentication mechanisms, and testing constraints.

5. Missing the third-party authorization step. If the client uses a hosted AI service, the service provider's testing policy may restrict certain test activities.

Related Topics

• Engagement Kickoff -- Detailed walkthrough for the first engagement meetings
• Threat Modeling Workshop -- Running a threat model to inform scope
• Reconnaissance Workflow -- The next phase after scoping is complete
• Platform Walkthroughs -- Platform-specific considerations for scoping