Rules of Engagement Template for AI 紅隊 Operations
入門14 分鐘閱讀更新於 2026-03-15
Step-by-step guide to creating comprehensive rules of engagement documents for AI red team assessments, covering authorization, scope, constraints, communication, and legal protections.
Rules of Engagement (ROE) documents serve as the legal and operational foundation for every 紅隊 engagement. For AI 紅隊演練, the standard penetration 測試 ROE template falls short 因為 it does not address AI-specific concerns such as generated content liability, model interaction boundaries, 訓練資料 handling, and third-party AI provider policies. This walkthrough guides you through building an ROE document that covers these gaps while remaining practical and enforceable.
A well-crafted ROE protects everyone involved. It protects the 紅隊 from accusations of unauthorized access. It protects the client from unexpected service disruptions. It protects both parties from regulatory complications. Invest the time to get this document right.
Step 1: Document Header and Engagement 概覽
Start with the administrative information that identifies the engagement and its participants.
# RULES OF ENGAGEMENT
# AI System 安全 評估
## Document Control
- Document ID: ROE-[CLIENT]-[YEAR]-[SEQ]
- Version: 1.0
- Classification: CONFIDENTIAL
- Created: [DATE]
- Last Updated: [DATE]
## Engagement 概覽
| Field | Value |
|-------|-------|
| Engagement Name | [Descriptive name] |
| Client Organization | [Legal entity name] |
| Client Point of Contact | [Name, title, email, phone] |
| 紅隊 Organization | [Legal entity name] |
| 紅隊 Lead | [Name, title, email, phone] |
| Engagement Type | [Prompt-Level / Application-Level / Full-Stack / Continuous] |
| Start Date | [YYYY-MM-DD] |
| End Date | [YYYY-MM-DD] |
| Authorization Reference | [Contract/SOW reference number] |The document ID should follow a consistent naming convention across engagements. This makes it easier to reference during and after the engagement, and during any future legal proceedings.
Step 2: Authorization and Legal Framework
這是 the most important section of the ROE. It establishes who authorized the 測試, what legal framework governs it, and what protections are in place.
Authorization Statement
## 1. Authorization
### 1.1 Authorization Statement
[CLIENT ORGANIZATION] hereby authorizes [RED TEAM ORGANIZATION] to conduct
an AI system 安全 評估 as described 在本 document. This
授權 is granted by [SPONSOR NAME], [SPONSOR TITLE], who has the
authority to approve 安全 測試 of the systems described in Section 2.
### 1.2 Scope of Authorization
This 授權 covers:
- Interaction with AI models and APIs listed in Section 2
- Attempted bypass of content filtering and 護欄
- 測試 of 輸入 validation, 輸出 handling, and data flow controls
- 評估 of 認證 and 授權 mechanisms
- Automated scanning using approved tools listed in Section 4
- Documentation and evidence collection of all findings
This 授權 does NOT cover:
- 測試 of systems not listed in Section 2
- Physical access to client facilities
- Social engineering of client personnel (unless explicitly approved below)
- 測試 outside the approved time window
- Any activity prohibited by applicable law
### 1.3 Third-Party Considerations
The following third-party AI services are used by the target system:
- [Provider 1]: 測試 is permitted under [provider's 測試 policy]
- [Provider 2]: Advance notification submitted on [DATE], reference [REF]
### 1.4 Legal Framework
This engagement is governed by:
- Master Services Agreement dated [DATE]
- Statement of Work [SOW NUMBER] dated [DATE]
- Non-Disclosure Agreement dated [DATE]
- This Rules of Engagement documentAI-Specific Legal Considerations
Traditional ROEs do not address these AI-specific legal questions. Include explicit answers 對每個:
| Question | Default Position | Notes |
|---|---|---|
| Is the 紅隊 authorized to generate harmful/offensive content as part of 測試? | Yes, within 測試 scope | Required for content policy bypass 測試 |
| Who owns content generated during 測試? | Client retains all rights | Include in IP section |
| Can 測試 prompts and responses be used in future research? | No, unless explicitly agreed | Requires separate data use agreement |
| Is the 紅隊 liable for AI-generated outputs during 測試? | No, 測試 is authorized activity | Confirm with legal |
| What happens if 測試 reveals the AI was trained on copyrighted material? | Report finding, no further action | Not in scope to investigate IP claims |
| Does 測試 violate the AI provider's terms of service? | Provider policy reviewed and complied with | Document provider policy review |
Step 3: Scope Definition
The scope section must be precise enough that any team member can determine whether a specific action is in scope or out of scope without asking for clarification.
## 2. Scope
### 2.1 In-Scope Systems
#### AI Models and Endpoints
| ID | System | Endpoint | Model | Environment |
|----|--------|----------|-------|-------------|
| T1 | Customer chatbot | https://api.example.com/v1/chat | GPT-4o (Azure) | Production |
| T2 | Internal assistant | https://internal.example.com/assist | Claude 3.5 Sonnet | Staging |
| T3 | Document analyzer | https://api.example.com/v1/analyze | Custom fine-tuned model | Production |
#### Supporting Infrastructure
| ID | Component | Description | 測試 Permitted |
|----|-----------|-------------|-------------------|
| S1 | RAG 知識庫 | Pinecone vector store | Query-level 測試 only |
| S2 | Function calling layer | Internal tool orchestration | Full 測試 |
| S3 | Content filter | Custom moderation pipeline | Bypass 測試 permitted |
| S4 | Authentication | OAuth 2.0 + API keys | Standard auth 測試 |
### 2.2 Out-of-Scope Systems
- 雲端 infrastructure (AWS/Azure/GCP management plane)
- Third-party AI provider infrastructure (OpenAI, Anthropic servers)
- Client corporate network (unless AI-related)
- Mobile applications (web API only in scope)
- Physical 安全
- [Additional client-specific exclusions]
### 2.3 測試 Boundaries
#### Permitted Activities
- Prompt injection and 越獄 attempts
- Content policy bypass 測試
- 系統提示詞 extraction attempts
- RAG 投毒 simulation (staging environment only)
- Function calling abuse 測試
- Authentication and 授權 bypass
- Rate limit 測試 (up to 2x documented limit)
- Data exfiltration 測試 via model outputs
#### Prohibited Activities
- Denial of service attacks against production systems
- Data modification in production databases
- 測試 against real customer data or sessions
- Exfiltration of actual customer PII
- Activities that violate applicable laws
- Model weight extraction (unless explicitly approved)
- 供應鏈 attacks against dependenciesStep 4: 測試 Methodology and Constraints
Document the approach, tools, and constraints that govern how 測試 is conducted.
## 3. 測試 Constraints
### 3.1 Technical Constraints
| Constraint | Value | Enforcement |
|-----------|-------|-------------|
| Maximum requests per minute | [N] | Client-side rate limiting + 紅隊 self-enforcement |
| Maximum 符元 per request | [N] | Red team self-enforcement |
| Maximum concurrent sessions | [N] | Red team self-enforcement |
| Maximum daily API cost | $[N] | Red team monitors, client alerts at threshold |
| 測試 hours | [HH:MM] to [HH:MM] [TZ] | Red team self-enforcement |
| Blackout dates | [List] | Red team calendar blocks |
### 3.2 Behavioral Constraints
- No generation of CSAM or content depicting real minors in harmful contexts
- No generation of content that constitutes a true threat against real persons
- No generation of content that could constitute defamation of real persons
- No submission of generated content to any external service or platform
- All generated content remains within the 測試 environment
### 3.3 Approved Tools
| Tool | Version | Purpose | Configuration |
|------|---------|---------|---------------|
| Garak | Latest stable | Automated 漏洞 scanning | Default probes |
| Promptfoo | Latest stable | Eval-driven 測試 | Custom 測試 suite |
| Burp Suite Pro | Latest | HTTP proxy and analysis | Standard config |
| Custom scripts | Engagement-specific | Targeted 測試 cases | Reviewed by lead |Cost Management Framework
AI 紅隊演練 can incur significant API costs. Include explicit cost management provisions:
### 3.4 Cost Management
#### API Cost Responsibilities
- Red team API costs for 測試: [Client / 紅隊] responsibility
- Client provides API keys with billing to: [Client / 紅隊 account]
- Cost ceiling for engagement: $[AMOUNT]
- If cost ceiling is reached: [pause and consult / continue at 紅隊 cost]
#### Cost 監控
- Red team monitors daily API usage and costs
- Client receives daily cost summary (if requested)
- Automated alerts configured at 50%, 75%, and 90% of cost ceiling
- 測試 pauses automatically at 100% until client approves additional budgetStep 5: Communication and Escalation Protocols
## 4. Communication
### 4.1 Regular Communication
| Type | Frequency | Channel | Participants |
|------|-----------|---------|-------------|
| Status update | Daily | Email | Red team lead + client POC |
| Progress review | Weekly | Video call | Full team + client POC |
| Finding discussion | As needed | Secure messaging | Red team lead + client tech POC |
### 4.2 Escalation Protocol
#### Critical Finding (Severity: Critical)
Definition: 漏洞 that allows unauthorized access to sensitive data,
complete bypass of 安全 controls, or poses immediate risk of harm.
1. Red team lead notifies client escalation contact within 2 HOURS
2. Notification via: Phone call + encrypted email
3. Client acknowledges receipt within 4 hours
4. Joint decision on immediate 緩解 within 24 hours
5. Finding documented in interim report within 48 hours
#### High Finding (Severity: High)
Definition: Significant 漏洞 with limited 利用 prerequisites.
1. Red team lead notifies client POC within 24 HOURS
2. Notification via: Encrypted email
3. Client acknowledges receipt within 48 hours
#### Emergency Stop Procedure
Either party may invoke an emergency stop at any time:
1. Contact other party via phone immediately
2. All 測試 ceases upon notification
3. Emergency meeting within 4 hours to 評估 situation
4. 測試 resumes only after written agreement from both partiesStep 6: Data Handling and Evidence Management
## 5. Data Handling
### 5.1 Data Classification
| Data Type | Classification | Handling Requirements |
|-----------|---------------|---------------------|
| 測試 prompts and responses | Confidential | Encrypted storage, engagement team only |
| Screenshots and recordings | Confidential | Encrypted storage, engagement team only |
| System prompts (if extracted) | Highly Confidential | Encrypted, engagement lead only |
| Client source code (if shared) | Highly Confidential | Encrypted, no copies |
| PII encountered during 測試 | Restricted | Minimize collection, redact in reports |
### 5.2 Evidence Retention
- During engagement: All evidence retained in encrypted storage
- Report delivery to final report acceptance: Full evidence retained
- After acceptance: Evidence retained for [90 / 180 / 365] days
- After retention period: Secure destruction with certificate of destruction
### 5.3 Data Destruction
- Method: Secure deletion (DoD 5220.22-M or equivalent)
- Scope: All engagement data including local copies, 雲端 storage, backups
- Verification: Certificate of destruction provided to client
- Timeline: Within [30] days of retention period expirationStep 7: Deliverables and Reporting
## 6. Deliverables
### 6.1 Deliverable Schedule
| Deliverable | Due Date | Format | Recipients |
|-------------|----------|--------|------------|
| Daily status updates | Each 測試 day | Email | Client POC |
| Interim critical findings | As discovered | Encrypted email | Escalation contacts |
| Draft report | [DATE] | PDF, encrypted | Client POC |
| Client review period | [N] business days | N/A | N/A |
| Final report | [DATE] | PDF, encrypted | Distribution list |
| Executive debrief | [DATE] | Presentation | Leadership team |
| Retest (if applicable) | [DATE] | PDF addendum | Distribution list |
### 6.2 Report Contents
- Executive summary with risk rating
- Methodology description
- Finding details with reproduction steps
- Evidence (screenshots, logs, sanitized prompts)
- Severity classification per agreed framework
- Remediation recommendations
- Technical appendix with raw dataStep 8: Signature and Acceptance
The final section formalizes acceptance by both parties.
## 7. Acceptance
### 7.1 Agreement
Both parties agree to the terms described 在本 Rules of Engagement
document. Any modifications must be agreed in writing by both parties.
### 7.2 Signatures
CLIENT:
Name: ___________________________
Title: ___________________________
Organization: ___________________________
Signature: ___________________________
Date: ___________________________
RED TEAM:
Name: ___________________________
Title: ___________________________
Organization: ___________________________
Signature: ___________________________
Date: ___________________________
### 7.3 Distribution
Signed copies distributed to:
- [ ] Client engagement sponsor
- [ ] Client legal department
- [ ] Client 安全 team lead
- [ ] Red team lead
- [ ] Red team organization legal/complianceStep 9: Review Checklist
Before sending the ROE for signature, verify that every section is complete and accurate.
# ROE Completeness Checklist
## Document Quality
- [ ] All placeholders replaced with actual values
- [ ] Dates are correct and consistent throughout
- [ ] Names and titles are accurate
- [ ] Contact information verified
- [ ] No conflicting statements between sections
## Legal Coverage
- [ ] Authorization statement is clear and specific
- [ ] Third-party provider policies addressed
- [ ] AI-specific legal considerations documented
- [ ] Liability limitations defined
- [ ] Data handling and destruction terms specified
## Technical Accuracy
- [ ] All in-scope systems listed with correct details
- [ ] Out-of-scope items explicitly stated
- [ ] 測試 constraints are realistic and achievable
- [ ] Approved tools list matches planned methodology
- [ ] Cost management terms are clear
## Operational Completeness
- [ ] Communication plan is detailed and actionable
- [ ] Escalation procedures specify timeframes and channels
- [ ] Emergency stop procedure is defined
- [ ] Deliverable schedule is realistic
- [ ] Retest provisions are included (if applicable)Common ROE Mistakes
-
Vague scope language. "測試 the AI chatbot" is not sufficient. Specify endpoints, models, environments, and exactly which types of 測試 are authorized. Ambiguity creates legal risk.
-
Missing third-party provider section. If the client uses hosted AI services, the ROE must address the provider's 測試 policies. Omitting this can lead to service termination or legal action from the provider.
-
No cost ceiling. AI 紅隊演練 can rack up thousands of dollars in API costs. Without a cost ceiling and 監控 plan, the client receives an unexpected bill and the relationship suffers.
-
Outdated contact information. People change roles and phone numbers. Verify all contact information within 48 hours of engagement start.
-
No emergency stop procedure. If 測試 causes an unexpected production issue, both parties need a clear, immediate procedure to halt 測試. Without it, confusion during a crisis makes the situation worse.
Knowledge Check
Which of the following is an AI-specific concern that traditional penetration 測試 ROEs typically do not address?
相關主題
- Pre-Engagement Checklist -- Using the ROE as the foundation for engagement preparation
- Scoping Checklist Walkthrough -- The scoping process that feeds into ROE creation
- Evidence Collection Methods -- Detailed evidence handling procedures referenced in the ROE
- Responsible Disclosure for AI -- Disclosure procedures that complement the ROE