AI Red Team Plan and Report: [System name] [version]

Combined plan and report for an adversarial test ("red team") of an AI system or LLM application: scope, threat model, attack categories, test cases, methodology, severity rating, findings, mitigations, retest and sign-off. Attack categories are mapped to the OWASP Top 10 for LLM Applications 2025 (LLM01:2025 to LLM10:2025) and to tactics of MITRE ATLAS. Replace every [bracketed] value and every row marked Example. Worked examples use a retrieval-augmented support assistant with tool access. Authorised testing only: run these tests only against systems you own or have written permission to test.

Document control

Approvals

Revision history

Contents

1. Scope and system under test
2. Objectives and success criteria
3. Threat model
4. Attack categories (OWASP LLM Top 10 2025)
5. MITRE ATLAS tactic coverage
6. Test cases
7. Methodology
8. Severity rating
9. Results summary
10. Findings
11. Mitigations
12. Retest
13. Sign-off
14. Glossary and references

1. Scope and system under test

1.1 System description

[System name] is a [customer support assistant] that answers questions using [retrieved help-centre articles and the customer's order history] and can call tools to [look up orders, issue refunds up to a limit and open tickets]. It is used by [about 40,000 customers per day] through [web chat and mobile app].

1.2 Components in scope

1.3 Out of scope

• Denial-of-service against shared provider infrastructure.
• Social engineering of employees.
• Production customer accounts; testing uses [synthetic accounts RT-ACC-001 to RT-ACC-050].

1.4 Authorisation and rules of engagement

Testing is authorised by [system owner] in writing on YYYY-MM-DD ([reference]). Testers use the [staging] environment with synthetic data, stop and report immediately if they reach real personal data, respect provider usage policies, rate-limit automated tests to [5] requests per second, and keep all evidence in [evidence store]. Harmful-content testing follows [content handling procedure], including wellbeing support for testers.

2. Objectives and success criteria

3. Threat model

3.1 Threat actors

3.2 Assets

Customer personal data, order and payment metadata, refund budget, system prompt and business rules, brand reputation, service capacity.

3.3 Data flow and trust boundaries

The diagram shows where untrusted text enters the model context.

4. Attack categories (OWASP LLM Top 10 2025)

5. MITRE ATLAS tactic coverage

6. Test cases

7. Methodology

7.1 Manual testing

Experienced testers explore each category for [2] days, following the threat model and recording every successful and unsuccessful attempt with timestamp, model version and full transcript reference. Testers vary phrasing, persona, language and formatting.

7.2 Automated testing

An automated harness ([tool name and version]) runs the payload library of [1,200] prompts across categories, with [20] samples per case at temperature [production setting]. A classifier plus human review of all flagged and [10%] of unflagged outputs decides success.

7.3 Multi-turn testing

Multi-turn cases build context over [3 to 10] turns (gradual escalation, role play, context poisoning through earlier answers). Each conversation is replayed [10] times from the first turn.

7.4 Reproduction rate

For each finding the reproduction rate is the share of attempts in which the attack succeeded:

where $k$ is the number of successful attempts and $n$ the number of attempts. Report a 95% Wilson interval when $n < 100$, for example $k = 7$, $n = 20$ gives $r = 0.35$ with interval about $[0.18, 0.57]$.

8. Severity rating

Severity combines impact $I$ (1 to 4) and exploitability $E$ (1 to 4):

Impact 4 means harm to people or unauthorised money movement or bulk data exposure; exploitability 4 means a single unauthenticated prompt with reproduction rate above 50%.

9. Results summary

[Number] test cases were run over [n] attempts between YYYY-MM-DD and YYYY-MM-DD. [n] findings were raised: [n] critical, [n] high, [n] medium, [n] low. Example: "The most serious issue allows splitting refunds to exceed the 50 EUR limit (RT-F-001, critical). Release is recommended only after the server-side cumulative limit is deployed and retested."

10. Findings

For each critical or high finding, add a detail block:

• Description: [what happens and why]
• Prompt or evidence: [redacted excerpt, reference EV-NNN]
• Steps to reproduce: [numbered steps, account, environment]
• Root cause: [for example "limit enforced in prompt only, not in the refund API"]

11. Mitigations

12. Retest

Residual risk: [statement of what remains and why it is acceptable].

13. Sign-off

14. Glossary and references

References: OWASP Top 10 for LLM Applications 2025 (https://genai.owasp.org/llm-top-10/); MITRE ATLAS (https://atlas.mitre.org/); [internal threat model]; [LLM evaluation plan].

Standard and licence note

Based on the OWASP Top 10 for LLM Applications 2025 by the OWASP GenAI Security Project (https://genai.owasp.org/llm-top-10/), licensed under Creative Commons Attribution-ShareAlike 4.0 (https://creativecommons.org/licenses/by-sa/4.0/). The category IDs and names are used for mapping; descriptions are original text. Because this template adapts that structure, the adapted structure is shared under CC BY-SA 4.0. MITRE ATLAS tactic names are cited for reference only (the ATLAS licence was not verified for this template, so no ATLAS content is reproduced). Use for authorised testing only.