What your team needs before an assessor can test one AI system and produce findings you can defend.
An independent assessor arrives for kickoff. The team cannot say which model deployment is in scope. The staging environment is missing the tool permissions the live assistant uses in production. The test accounts all share one administrator role. When the assessor asks who can authorise continued testing after a critical finding, nobody in the room is certain. This engagement is not ready to start: in its current form, it cannot support reliable claims about the production system.
Knowing how to prepare for an AI red teaming assessment is what separates that scene from a useful one. Preparation creates a stable, inspectable, authorised, and traceable target that an external test can measure. Get it right and findings attach to a defined system state, cover the paths that matter, and hold up when an engineer, an auditor, or a customer asks how you know.
This article assumes you already understand what AI red teaming is and why it matters for a production system. If you need that grounding first, start with our primer on AI red teaming and adversarial testing. Here the focus is narrower: the client-side handoff that makes one named system testable. A single running example runs through each area, a customer-support assistant that uses retrieval-augmented generation (RAG) over an internal knowledge base and can call a customer-record tool. The five preparation areas move in sequence, from defining the target to preserving the evidence.
The Assessment Preparation Pack at a Glance
Use this as an AI red teaming assessment checklist for one system. Each area has a minimum set of client artefacts, a readiness check you should be able to answer yes to, and a failure that follows if it is missing.
| Preparation Area | Minimum Client Artefacts | Readiness Check | Failure If Missing |
|---|---|---|---|
| System baseline and boundary | Intended-use statement, system owner, version or observable configuration manifest, in-scope and excluded components, user types, deployment context | Can both parties point to the same system state and name which claims the assessment can support? | Findings cannot be tied to a stable target, and scope disputes surface after testing starts. |
| System map | Architecture diagram, trust boundaries, data-flow diagram, prompt and guardrail inventory, retrieval sources, tool and API map, identities, permissions, human approval points | Can the assessor follow input, retrieval, reasoning, tool use, output, and downstream action across the workflow? | The test plan overweights generic prompt attacks and misses application-level failure paths. |
| Controlled execution setup | Named environment, parity statement, test accounts and roles, permitted data, tenant fixtures, rate limits, network access, tool permissions, backup, rollback, access expiry | Can the assessor exercise realistic paths without reaching unapproved systems or data? | The team creates operational risk, or receives findings that apply only to a simplified test harness. |
| Rules and owners | Signed rules of engagement, authorised testers, schedule, permitted and prohibited techniques, critical-finding threshold, stop conditions, call tree, scope-change authority, resume authority, risk-acceptance owner | Can each person state who decides during a critical finding, system impact, real incident, or scope change? | Testing pauses at the wrong time, an incident is confused with test activity, or nobody owns the decision. |
| Evidence and known issues | Log schema and retention, clock synchronisation, correlation identifiers, prior tests, open findings, incident history, change log, known-issue register, disclosure procedure | Can the team reproduce a finding and show which configuration, identity, retrieved source, tool action, and control produced it? | Severity becomes harder to defend, retesting loses comparability, and concealed issues waste assessment time. |
1. Define the Tested System State
A finding applies to a defined system state, so the first task is to fix that state in writing. Record the intended use, the users, the deployment environment, the system boundary, the in-scope components, the explicit exclusions, and the decision the assessment should support. The Open Worldwide Application Security Project (OWASP) GenAI Red Teaming Guide, published 22 January 2025, recommends that an engagement define the models and systems under test, the permitted test types, explicit exclusions, objectives, and success criteria (OWASP GenAI Red Teaming Guide). A finding against an unidentified or shifting configuration cannot support a defensible remediation or deployment decision.
Hosted and frequently changing systems make versioning harder, so capture every observable component that can change a result. For the support assistant, a useful baseline records the model provider and identifier, the deployment or endpoint identifier, the API version, the system-prompt version or a cryptographic hash where policy prevents sharing the prompt, the guardrail and evaluator configuration, the retrieval index or corpus snapshot, the embedding model, the tool definitions and permission scopes, the environment manifest, and the test window with timestamps. Where a provider can change an upstream model without notice, record the exposed identifiers, the configuration, and the timestamps rather than claim a level of version certainty the platform doesn’t provide. This documentation discipline mirrors the technical-documentation logic in EU AI Act Annex IV, which for applicable high-risk systems covers intended purpose, system and software versions, interfaces, and third-party components (Annex IV).
The artefact to produce here is a one-page assessment scope record: the system under test, its boundary, what is excluded, and the decision it informs. For the wider organisational evidence gate before a production decision, see whether your AI system is ready for production review.
2. Build the System Map the Assessor Needs
The assessor needs a system map that defines the attack surface. Architecture, trust boundaries, data flows, prompts, guardrails, retrieval sources, tools, application programming interfaces (APIs), service identities, permissions, human approval points, third-party components, and monitoring together define the attack surface. For the support assistant, the map should let the assessor follow a request from user input through retrieval, model inference and orchestration, the customer-record tool call, the response, and any downstream action. Without it, a test plan overweights generic prompt attacks and misses the application-level failure paths that matter.
Give the assessor the access the objective requires. The parties should select an access model that fits the assessment goal and record what the assessor can and cannot inspect. The detailed comparison of black-box, grey-box, and white-box access belongs to the engagement itself; for that scope and deliverable detail, see what an external AI red teaming assessment actually includes.
Sensitive material needs a controlled path. Do not email unrestricted prompts, secrets, customer records, or production credentials to an assessor. Agree a secure review route, an access level, permitted storage, and a deletion or retention rule. A redacted document set supports planning, and controlled in-environment access covers the sensitive details the assessor needs during execution. The primer covers the attack classes; the map is the job here.
3. Agree the Execution Environment and Access
The test environment determines how far the findings generalise. Decide whether testing runs in production or in a representative non-production environment, then document every material difference in a parity statement. A non-production environment should reproduce the model configuration, prompts, retrieval behaviour, tool interfaces, identities, permission boundaries, guardrails, logging, and human approval paths that carry the risk under test. OWASP recommends realistic test environments that reflect user types, usage patterns, and plausible adversaries (OWASP GenAI Red Teaming Guide). A safe but unrealistic environment can produce findings that are correct on paper that do not answer the production question.
Design accounts and data to exercise real paths without creating uncontrolled risk. Provide test accounts that represent the roles and tenant boundaries the assessor needs, set rate and cost limits, define network routes and permitted outbound connections, and specify backup, reset, and access revocation. Access should follow least privilege where that doesn’t invalidate the test, expire after the engagement, and stay auditable, so broad administrator access is the wrong default. Synthetic or sanitised data reduces exposure, but a weak fixture set that strips away the tenant, retrieval, identity, and tool conditions removes the very risk you are testing. Seeded canary records let the assessor test exposure and exfiltration without using real customer data. Decide in advance whether security monitoring knows the test is running and how it will separate test traffic from a real attack.
4. Sign the Rules and Name the Decision Owners
Written authority and named owners keep the test controlled. The National Institute of Standards and Technology (NIST) defines rules of engagement as detailed testing guidelines and constraints, set before a security test, that authorise the team to carry out defined activities without seeking permission for each action (NIST CSRC). NIST Special Publication 800-115 recommends that every third-party technical security assessment have a plan answering scope, authorised assessors, logistics, sensitive-data handling, and incident response, with explicit authorised and excluded systems, permitted and prohibited actions, testing windows, contacts, escalation procedures, and the authority to stop and resume testing (NIST SP 800-115). That publication predates generative AI, so treat its planning logic as sound groundwork rather than an AI testing standard. A good set of AI red team rules of engagement adds cost and rate constraints, evidence handling, communication cadence, critical-finding thresholds, real-incident deconfliction, scope-change authority, and who may resume testing.
Separate contacts from owners: a contact relays information, an owner can authorise action or accept risk. Name six roles before kickoff:
- The system owner, who confirms the target and intended use.
- The technical owner, who can restore the environment, rotate credentials, or explain system behaviour.
- The security or incident owner, who decides whether a detected event is part of the test and can trigger incident response.
- The data or privacy owner, who approves permitted data and evidence handling.
- The risk owner, who can pause deployment, accept residual risk, fund remediation, and authorise a retest.
- The assessment lead, who controls tester access, staged disclosure, scope interpretation, and critical-finding escalation.
The assessor’s decision boundary is the point to close on. The NIST AI Risk Management Framework (AI RMF) Playbook recommends involving independent assessors and documenting roles, responsibilities, and delegated authority (NIST AI RMF Playbook), which is voluntary guidance under revision rather than a fixed control set. Applied here it sets a clear boundary: the assessor identifies and grades a finding, recommends remediation, and retests a control, while the client owns the deployment and accepts residual risk. The assessor must not become the unnamed owner who authorises production.
5. Preserve Evidence and Disclose Known Weaknesses
Share existing evidence to raise the value of the test. Decide before testing which events the environment can record, because a finding is only as defensible as the trace behind it. A useful trace may include timestamps, correlation identifiers, test-account identity, role and tenant, the input, retrieved source identifiers, the model and configuration identifier, the response, the guardrail decision, the tool call and result, the approval state, any error, the downstream effect, and any related alert, with clocks synchronised across components. The NIST AI RMF Playbook recommends documenting test sets, metrics, tools, methods, and outcomes to support repeatability and consistent risk decisions, and EU AI Act Article 12 requires, once the relevant high-risk provisions apply, automatic event logging over the lifecycle for applicable high-risk systems (Article 12).
Hand the assessment lead the full picture. Provide prior evaluations, automated test runs, incidents, open defects, known limitations, mitigations, accepted risks, and any changes made before the engagement. The naive instruction to “show the assessor everything at the start” isn’t the goal. Give the lead the complete known-issue register, then let the lead use staged disclosure: reserve an initial blind test segment where independent discovery has value, then direct validation of the known findings. That design preserves independent discovery while stopping the team from withholding material risk information. Concealing a known weakness to test whether the assessor rediscovers it wastes assessment time.
Handle pre-test fixes honestly. A team may make legitimate fixes before testing, but it should version and disclose them: record the old issue, the change, the new baseline, and the reason, so the test can validate the fix or assess the current state. Temporary hardening that exists only for assessment week should be labelled as such and excluded from any claim about the ordinary deployment. For the documentation and logging requirements that shape what applicable high-risk systems must keep, see what the EU AI Act requires from high-risk AI systems.
A Ten-Minute Go or No-Go Check
Before you confirm the assessment window, run five questions, one for each area:
- Can we identify the exact system state and the decision under test?
- Can the assessor follow the relevant data, retrieval, tool, and permission paths?
- Can the environment exercise those paths without reaching unapproved systems or data?
- Can named owners stop, change, resume, remediate, and accept risk?
- Can the logs and evidence reproduce a result against the recorded baseline?
If any answer is no, you have a scoping task before the assessment window opens. It’s a readiness gate that tells you whether the assessment can start.
How well you prepare sets the ceiling on finding quality. A vague boundary produces ambiguous coverage, an unrealistic environment produces findings that do not answer the production question, and missing logs make credible findings hard to reproduce. Good preparation reduces access delays, scope disputes, and environment rework, although total duration still depends on system complexity and access. An independent assessment depends on scope integrity and honest disclosure. Withholding useful context or building a clean configuration for test week undermines both.
Provion’s AI System Robustness Assessment begins with scope and rules of engagement for one named system or workflow, and the preparation above is the input that makes it work. If you are scoping an assessment, book a scoping call for one named system and review the preparation requirements before you agree the window. To see the evidence this work has to support, review a Provion sample report for the findings format, severity logic, and evidence trace.
