AI 紅隊 Scoping Checklist 導覽

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 紅隊 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 授權. 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 測試, 識別 who needs to be involved in the scoping process and who will receive results.

1. 1

   識別 Key Contacts

   Complete this contact matrix:

   # Stakeholder Contact Matrix
    
   | Role | Name | Email | Phone | Availability |
   |------|------|-------|-------|--------------|
   | Engagement sponsor | | | | |
   | Technical point of contact | | | | |
   | ML/AI team lead | | | | |
   | 安全 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)
   • 安全 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 授權 obtained from engagement sponsor
   • * Scope of 授權 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 授權 obtained (if 測試 involves third-party AI services)

   Provider 測試 policies to review:

   Provider	測試 Policy	Notification Required?
   OpenAI	Terms of use Section 2	No, but rate limits apply
   Azure OpenAI	Azure penetration 測試 rules	Yes, submit form
   AWS Bedrock	AWS penetration 測試 policy	No longer required for most services
   Google Vertex AI	GCP penetration 測試 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 系統:

   # Model Inventory
    
   | # | Model Name | Provider | Version | Type | Purpose | User-Facing? |
   |---|-----------|----------|---------|------|---------|--------------|
   | 1 | | | | Chat/Completion/嵌入向量 | | 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)
   • 嵌入向量 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
    
   ## 輸入 Processing
   - [ ] Frontend interface (web, mobile, API)
   - [ ] 輸入 validation layer
   - [ ] Rate limiting 實作
   - [ ] Authentication/授權 mechanism
   - [ ] Content preprocessing (分詞, formatting)
    
   ## Model Infrastructure
   - [ ] Model hosting platform (雲端 service, self-hosted)
   - [ ] 系統提示詞 management (static, dynamic, templated)
   - [ ] Temperature and parameter configuration
   - [ ] Streaming vs. batch 推論
   - [ ] Model fallback/failover configuration
    
   ## Data Integration
   - [ ] RAG/知識庫 connections
   - [ ] 資料庫 connections
   - [ ] File upload/processing capabilities
   - [ ] External API integrations
   - [ ] Vector store/嵌入向量 資料庫
    
   ## Tool Use / Function Calling
   - [ ] Available function definitions
   - [ ] Function 權限 model
   - [ ] External service connections
   - [ ] Result validation for tool outputs
    
   ## 輸出 Processing
   - [ ] 輸出 filtering/content moderation
   - [ ] PII 偵測 and redaction
   - [ ] Response formatting and truncation
   - [ ] Citation/source attribution
    
   ## 監控 and Logging
   - [ ] Inference logging configuration
   - [ ] 安全 alerting rules
   - [ ] Audit trail for model interactions
   - [ ] Cost 監控 and limits

3. 3

   Data Asset Identification

   識別 data assets that could be exposed, poisoned, or exfiltrated:

   # Data Asset Inventory
    
   | Asset | Classification | Location | AI Connection |
   |-------|---------------|----------|---------------|
   | 訓練資料 | | | 微調 |
   | 知識庫 docs | | | RAG retrieval |
   | User conversation logs | | | History context |
   | System prompts | | | Model instruction |
   | 嵌入向量 vectors | | | Similarity search |
   | Feature store data | | | Model 輸入 |

   Checklist:

   • 訓練資料 source and classification identified
   • 知識庫 contents inventoried and classified
   • User data in conversation context documented
   • 系統提示詞 content documented (for 測試 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
   - [ ] 系統提示詞 configurations
   - [ ] Content filtering/護欄 configurations
   - [ ] RAG/知識庫 connections and queries
   - [ ] Function calling/工具使用 capabilities
   - [ ] Authentication and 授權 for AI endpoints
   - [ ] Rate limiting and abuse prevention
   - [ ] Logging and 監控 coverage
    
   ## Conditionally In Scope (requires explicit approval)
   - [ ] Production environment 測試
   - [ ] Multi-tenant isolation 測試
   - [ ] 訓練資料/pipeline 評估
   - [ ] Model extraction attempts
   - [ ] Denial of service 測試
   - [ ] 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 安全
   - [ ] Non-AI application components (unless they interact with AI)
   - [ ] Other client systems not involved in the AI pipeline
   - [ ] [Add client-specific exclusions]

3. 3

   測試 Constraints

   Document constraints on how 測試 is conducted:

   # 測試 Constraints
    
   ## Technical Constraints
   - Maximum requests per minute: ___
   - Maximum 符元 per request: ___
   - Maximum concurrent sessions: ___
   - Allowed API endpoints: ___
   - Prohibited API operations: ___
    
   ## Timing Constraints
   - 測試 window: ___ to ___ (dates)
   - Allowed hours: ___ to ___ (if restricted)
   - Blackout periods: ___
   - Maintenance windows to avoid: ___
    
   ## Behavioral Constraints
   - [ ] No 測試 that generates illegal content
   - [ ] No 測試 against real user data (use 測試 accounts)
   - [ ] No persistence of client data on 紅隊 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 評估
Focus: Prompt injection, 越獄, content policy bypass
Duration: 1-2 weeks
Best for: Initial assessments, applications with strong infrastructure 安全
Deliverable: Prompt-level 漏洞 report
 
## Option B: Application-Level 評估
Focus: Prompt attacks + API 安全 + data integration 測試
Duration: 2-3 weeks
Best for: Production applications with RAG or 工具使用
Deliverable: Comprehensive application 安全 report
 
## Option C: Full-Stack 評估
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 安全 評估 with architecture recommendations
 
## Option D: Continuous 評估
Focus: Ongoing 監控 with periodic manual 測試
Duration: Ongoing (monthly or quarterly cycles)
Best for: Mature systems requiring sustained 安全 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 測試 | 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 漏洞 scanning)
- [ ] Promptfoo (eval-driven 測試)
- [ ] PyRIT (orchestrated attacks) -- if multi-turn 測試 needed
- [ ] Ollama (local model 測試)
 
## Optional / Advanced
- [ ] HarmBench (formal benchmarking)
- [ ] Inspect AI (structured evaluations)
- [ ] Custom automation scripts
- [ ] 雲端 CLI tools (aws, az, gcloud) for platform assessments

Cost Estimation

# Cost Estimation
 
## API Costs
- Estimated requests: ___
- Average 符元 per request: ___
- Model pricing: $___ per 1K 符元
- Estimated API cost: $___
 
## Tool Costs
- Burp Suite Professional: $449/year (if needed)
- 雲端 compute for local model 測試: $___
- Other tool licenses: $___
 
## Personnel
- Lead 紅隊員: ___ 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 紅隊 評估
    
   ## 1. Engagement 概覽
   - 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 測試 Constraints
   [Constraints from Phase 3]
    
   ## 3. Communication
   - Primary communication channel: ___
   - Status update frequency: ___
   - Critical finding notification: within ___ hours to ___
   - Emergency contact: ___
    
   ## 4. 測試 Methodology
   - Automated scanning tools: [list]
   - Manual 測試 techniques: [list]
   - 攻擊 categories to 測試: [list]
   - Evidence collection method: [screenshots, logs, recordings]
    
   ## 5. Data Handling
   - Client data on 紅隊 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 紅隊 lead
   • * ROE reviewed by client technical POC
   • * ROE reviewed by client legal/compliance (if applicable)
   • * ROE signed by engagement sponsor
   • * ROE signed by 紅隊 lead
   • * Signed copy distributed to all stakeholders
   • * Copy stored in engagement documentation system

Phase 7: Environment Preparation

Final preparation before 測試 begins.

# Environment Preparation Checklist
 
## Access Verification
- [ ] API keys or credentials received and tested
- [ ] VPN access configured (if required)
- [ ] 測試 accounts created and verified
- [ ] Access to 監控 dashboards confirmed (if provided)
- [ ] Access to relevant documentation confirmed
 
## Tool Setup
- [ ] All required tools installed and configured
- [ ] Target endpoints configured in tools
- [ ] 測試 connectivity verified
- [ ] Rate limiting tested (to 理解 limits before active 測試)
 
## 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 紅隊 Scoping - Critical Path Items
 
□ Engagement sponsor identified and available
□ Written 授權 obtained
□ Authorization covers all environments
□ Third-party provider 測試 policies reviewed
□ All models enumerated with versions
□ System architecture components mapped
□ Data assets inventoried and classified
□ In-scope and out-of-scope boundaries defined
□ 測試 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 測試 before the ROE is signed. Even informal 測試 creates legal exposure. Do not send a single 測試 request until 授權 is documented.

2. Forgetting 嵌入向量 models and classifiers. The primary chat model gets all the 注意力, but 嵌入向量 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 紅隊 測試. Provide cost estimates upfront and set billing alerts.

4. Vague scope boundaries. "測試 the chatbot" is not a scope. Specify endpoints, models, data sources, 認證 mechanisms, and 測試 constraints.

5. Missing the third-party 授權 step. If the client uses a hosted AI service, the service provider's 測試 policy may restrict certain 測試 activities.

相關主題

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