# How to scope an AI red team engagement: questions, access and stop conditions

Source: https://airedteamingservices.com/guides/how-to-scope-an-ai-red-team/
Publisher: Excession Labs (airedteamingservices.com)
Last updated: 2026-11-09

How to scope an AI red team engagement: eight questions on purpose, users, models, data, tools and environments, plus test data, rules and stop conditions.

> **Short answer:** To scope an AI red team engagement, answer eight questions: purpose, users, models, data sources, tools, sensitive actions, environments and deadline. Then agree access, fake test data, rules for what testers may do, and stop conditions. A clear written scope lets testers cover the right risks and lets you compare quotes.

An AI red team scope is a short written document. It says what the testers may attack, with what access, with what data, and when they must stop. Eight questions fill most of it, and the [scoping form](/scoping/) asks the same ones. Access, test data, rules and stop conditions come after the questions.

## Why does scope matter more for AI systems?

AI systems have more moving parts than the model. A chat feature may read documents, call tools and render output in a browser, and each part adds attack paths. Microsoft's AI Red Team writes that AI red teaming aims to go beyond model-level benchmarks by emulating real-world attacks against end-to-end systems (arXiv 2501.07238). The scope must therefore name the whole system.

Output also varies: the same input can give different results on two runs. A good scope says how many times each test runs and how to count a success.

## What are the eight scoping questions?

Answer in plain words. A short answer beats a missing one.

| # | Question | Why we ask | Example answer (invented) |
|---|---|---|---|
| 1 | Purpose: What does the AI feature do, and who asked for the test? | Sets what counts as a failure. A refund bot and a code assistant fail in different ways. | "Harbor Notes assistant answers questions about a user's notes. A customer asked for a security review." |
| 2 | Users: Who talks to it? Roles, tenants, anonymous or signed in? | Sets who the attacker can be and which boundaries to test. | "Signed-in members of paid workspaces. Admins and read-only roles." |
| 3 | Models: Which models, versions and providers? Fine-tuned? Fixed or auto-upgraded? | Results hold for one model version. A silent upgrade can change them. | "A hosted general model, pinned version. System prompt in our repo." |
| 4 | **Data sources.** What does it read? Documents, databases, web pages, email, tickets, memory? | Every source of text is a path for indirect prompt injection and a source of leaks. | "Workspace notes, shared files, a help-center index." |
| 5 | Tools: What can it call? APIs, MCP servers, code execution, browsers, email? With whose credentials? | Tools turn text into actions. See [excessive agency](/guides/excessive-agency/). | "Search notes, create note, send share link by email." |
| 6 | **Sensitive actions.** What would hurt most? Money, deletion, sharing, data export, account change? | Sets priorities and the approval rules. | "Sharing a note outside the workspace. Deleting notes." |
| 7 | Environments: Production, staging, or a test copy? Any third-party systems the tools reach? | Sets where testers may act and what must never be touched. | "Staging with fake data. No production. The email tool points to a sandbox mailbox." |
| 8 | Deadline: When do you need the report, and why that date? | Sets the order of work and the retest window. | "Launch on a set date; customer review before it." |

Add anything else the testers should know: past incidents, known weak spots, and parts you want skipped.

## What access do testers need?

Testers need the access a real attacker class would have, plus a few helpers. List each item in the scope:

- Test accounts for each role and for at least two separate tenants. Two tenants let testers check isolation.
- A way to read system settings, if you want a gray-box test: the system prompt, tool definitions, retrieval settings, and model parameters. Say if you want a black-box test instead.
- Logs or traces, so testers can show what the model saw and which tools it called. Ask for read access to your own trace tool, or for exported traces after each session.
- Rate limits and cost caps. AI calls cost money. Agree a limit on calls or spend per day, and say who pays.
- Allowlists. Name the IP ranges or headers the testers will use so your team can tell test traffic from attacks.
- A contact who can answer in working hours and a second contact for urgent stops.

Never send production secrets in the scoping form. Agree a safe channel for any credentials.

## What test data should you prepare?

Use fake data that looks real. Real data adds legal risk and tells you nothing extra. Prepare these items:

1. Two tenants with seeded records. Give each record a unique marker string, such as `TENANT-A-0042`. If that marker shows up in tenant B's chat, you have proof of a leak.
2. Documents with different access levels in the retrieval index: public, team-only, admin-only. Testers check that the model respects each level.
3. Fake secrets. Plant canary values, such as a fake API key, in places where a secret should not be: a system prompt, a note, a tool response. Testers check whether the model reveals them.
4. Fake customers and orders for any bot that handles accounts. Mark them as test data.
5. A sandbox for tool actions. Email goes to a test mailbox. Payments use a test mode. Deletes hit a copy.

## What rules should the scope set?

Write the rules as a short list. They protect both sides.

- Allowed: prompt attacks, indirect injection through content the testers place in test data, retrieval boundary tests, tool misuse tests, output handling tests, repeated attempts within the call limit.
- Not allowed unless named: attacks on the model provider, denial of service, social engineering of your staff, tests on production data, tests on third-party systems that did not give permission.
- Evidence: keep prompts, responses, tool calls, timestamps, and the number of attempts for each finding.
- Authorization: the system owner signs the scope. We test only with written authorization from the system owner. If a model provider or a tool vendor owns part of the stack, check their terms before testing it.

## What are good stop conditions?

A stop condition is an event that makes testers pause and call you. Agree on them before testing. Common ones:

1. A tool action reaches a real customer, mailbox or payment, not a test one.
2. Real personal data or a real secret appears in an output.
3. The system slows down or fails in a way that affects real users.
4. A cost cap is reached.
5. A finding is severe enough that you want to fix it before testing goes on, for example a cross-tenant leak.
6. Testers find evidence that someone else has already attacked the system.

Write who gets the call, how fast you expect an answer, and who can restart the work.

## How do you turn the answers into a plan?

Use the answers to pick test areas. A system with retrieval needs boundary and poisoning tests. A system with tools needs permission and approval tests. A public chatbot needs abuse, policy and data leak tests. The pages on [LLM application assessments](/llm-application-security-assessment/) and [AI agent assessments](/ai-agent-security-assessment/) list the checks for each, and the [methodology page](/methodology/) shows how we record conditions, evidence and impact.

If you are unsure whether you need an AI red team or a classic pentest, read [AI red teaming vs penetration testing](/guides/ai-red-teaming-vs-penetration-testing/). For a support bot, read [testing customer support chatbots](/guides/testing-customer-support-chatbots/).

When your answers are ready, send them through the [scoping form](/scoping/). We reply with a written scope and a proposal. We cannot promise to find every flaw or to prevent prompt injection. The report states what we tested, under which conditions, and what we saw.

## Questions

### How long does scoping take?

It depends on how many components the system has and how fast you can answer. A single chat feature with one data source is quick to describe. An agent with many tools and several environments takes more questions. We do not publish fixed times. Gather the eight answers before the call to save the most time.

### Do I need to give testers production data?

No. Use a test tenant with fake records that look like real ones. Never put production secrets or real customer data into the scoping form. Agree a safe channel for test credentials during scoping.

### Can I scope only the model?

Yes, but say so. Some teams want model safety evaluations only. Most security risk sits in the application around the model: retrieval, tools, output rendering and permissions. If you scope only the model, the report cannot say anything about those parts.

### What if my system changes during the test?

Tell the testers about planned changes and freeze windows in the scope. Model, prompt and tool changes can alter results. The report should name the model version, prompt version and date of each test so you can retest after a change.

## Sources

- [NIST AI 600-1: Generative AI Profile (AI red-teaming, Appendix A.1.5)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)
- [OWASP GenAI Red Teaming Guide (22 January 2025)](https://genai.owasp.org/resource/genai-red-teaming-guide/)
- [Microsoft AI Red Team: Lessons From Red Teaming 100 Generative AI Products (arXiv 2501.07238)](https://arxiv.org/abs/2501.07238)
- [OWASP Top 10 for LLM Applications 2026 (README)](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/README.md)