An external AI red teaming assessment tests one named AI system or workflow and returns four things: expert-validated findings with severity and business impact, a reproducible trace from test vector to system response, remediation guidance your engineers can act on, and an assessment record that stays inside your own environment. Everything else in a proposal is packaging.
This is a buyer and procurement guide. If you are a CTO, CISO, security lead, technical evaluator, or procurement lead comparing offers, what follows covers the engagement method, the evidence layer, access models, timing, deployment prerequisites, and what the statement of work (SOW) has to specify.
One boundary before the detail. An assessment of this kind produces testing evidence. It doesn’t certify compliance, stand in for a conformity assessment, or replace legal advice. Vendor language that blurs those lines is a reason to ask a harder question, not a reason for confidence. For the definition and the attack surfaces this testing covers, start with our primer on AI red teaming for production AI systems.
The Seven Stages of an External AI Red Teaming Assessment
The market uses the same phrase for a two-day automated scan and a multi-week adversarial engagement. The way to tell them apart is to ask what decision each stage of the engagement produces, not what activity it performs.
1. Scope and Rules of Engagement
Define the system under test, its intended use, the boundary, the exclusions, the access model, the environment, data constraints, the escalation path, and the decision the assessment supports.
Output: a written scope record and signed rules of engagement. Until both exist, there is no engagement, only an intention.
2. System Review and Threat Model
Review architecture, prompts, model configuration, data flows, retrieval sources, tools, permissions, guardrails, and logging. A retrieval-augmented customer-support assistant, an internal document summariser, and a tool-connected agent with write access are three different systems and produce three different threat models.
Output: a system-specific threat model naming the attack paths worth testing and the ones deliberately out of scope.
3. Adversarial Test Plan
Map attack classes to the actual system. A plan drawn from a generic attack library rather than the threat model produces findings that look plausible and land nowhere near the parts of the system that matter.
Output: an agreed test plan with coverage stated openly, including what will not be tested and why.
4. Active Testing
Manual adversarial testing supported by tooling: prompt injection, jailbreaks, indirect injection through retrieved content, tool misuse, data leakage, guardrail bypass, model and data attacks, and runtime weaknesses. Manual work reasons about your specific system. Tooling gives breadth across known patterns. Neither replaces the other.
Output: execution records for every test run, including the vector, the input, the system response or tool action, and the conditions under which it was reproduced.
5. Expert Validation, Severity, and Remediation Guidance
This stage is a gate, not a formality. Automated scores and binary safe or unsafe labels can support triage. None of them becomes a final finding without expert review of repeatability, exploitability, context, and business impact.
Output: validated findings, each with a severity decision, the rationale behind that decision, the affected component, the control that failed, and a recommended fix.
6. Evidence Handoff and Final Readout
The evidence record is handed over inside your environment and reviewed with your team. Security, engineering, and governance readers all work from the same record rather than three different summaries of it.
Output: an evidence record your teams can inspect, portable exports for people outside the instance, and a readout that ends with owners against findings.
7. Optional Retest or Evidence Refresh
Retesting is triggered by something specific: remediation you want validated, a material change to the model, prompts, data sources, tools or permissions, your release cadence, a monitoring plan, or a risk decision that needs current evidence.
Output: a dated comparison between runs showing what was fixed, what remains, and what residual risk is being accepted.
What the Rules of Engagement Must Cover
The rules of engagement carry most of the operational risk, so treat them as a contractual artefact rather than an email thread. At minimum they should record written authority to test, target identifiers and system boundaries, exclusions, the access model, the testing environment, permitted and prohibited techniques, testing windows, rate and cost limits, data handling and permitted test data, the communication cadence, the threshold that defines a critical finding, the disclosure path for critical findings found mid-engagement, stop conditions, deconfliction with real security incidents, and who authorises a scope change or a resumption of testing.
Two of those carry weight. A vendor that holds a critical finding for four weeks and reveals it at the readout is running on the wrong incentives, and a scope-change route left undefined becomes a commercial argument at the worst moment.
For the client-side work that precedes all of this, see our guide to preparing for an external AI red teaming assessment.
Where the Evidence Lives
The older model of this service was three PDF documents delivered at the end. It is easy to sell and hard to use, because a PDF can’t show which test produced which response, and can’t be updated when a finding is remediated.
Provion delivers the assessment through a customer-resident evidence workspace, deployed in your environment. The workspace is the system of record and holds:
- Test vectors and execution records.
- System responses and tool actions.
- Expert validation rationale for each finding.
- Severity and business impact.
- Remediation status and owner.
- Applicable framework mappings.
- Assessment and retest history across runs.
PDF and supported machine-readable exports are portable outputs for people who need the evidence but can’t access your instance: a board, a customer’s security team, external counsel, a procurement reviewer. They are first-class deliverables, but not the primary evidence layer, and a vendor should be clear about which is which.
The data boundary is worth stating precisely: system responses, final findings, evidence, and reports remain inside your environment. Provion Cloud may receive the minimum metadata needed to generate test vectors, such as system type and attack category. Any vendor claiming that no customer-derived information of any kind leaves your perimeter should be asked for a field-by-field data-flow description before you accept it. We provide ours during procurement review.
An Illustrative Finding, Traced End to End
The following is an illustrative method example, not a real client result. It uses the retrieval-augmented customer-support assistant from our other articles: read access to an internal knowledge base, a customer-record lookup tool, and an intended use limited to account and billing questions for the authenticated customer.
| Evidence record field | Entry |
|---|---|
| Attack vector | Indirect prompt injection through retrieved content, mapped to LLM01:2025 Prompt Injection and LLM06:2025 Excessive Agency. |
| Test input | A support article submitted through the public content channel carries hidden text instructing the assistant to look up and summarise the most recent account it can reach. Ingested to the knowledge base, then retrieved as context for an unrelated billing query. |
| System response and tool action | The assistant follows the embedded instruction, calls the customer-record tool, and returns the name, email, and last three transactions of a different customer. Reproduced 7 times in 10 attempts on build 4.2.1. |
| Expert validation rationale | Repeatable across two phrasings and two retrieval paths. No privileged access needed: the attacker only has to submit a document that reaches the index. The retrieval layer treats document content as instructions, and the tool runs under a broad service identity with no per-request check on whose record is requested. |
| Severity | High. Low attacker capability, high impact, no compensating control observed at the tool boundary. |
| Business impact | Cross-tenant personal data disclosure triggered by content any user can plant, with direct privacy exposure and a plausible breach-notification path. |
| Remediation | Scope the tool identity to the authenticated customer, add an authorisation check in the downstream record service, and separate retrieved content from instructions in the prompt construction. Owner: application team. |
| Retest result | Retest on build 4.3.0 repeats both vectors. The tool refuses the cross-customer lookup in all attempts. Residual risk documented for two adjacent tools not in the agreed scope. |
| Evidence export | Finding, trace, severity rationale, and retest comparison exported to PDF for the customer’s data protection lead, with the full run history retained in the workspace. |
That is the level of detail a system owner needs to act. A finding that says “the system is vulnerable to prompt injection” supports no decision at all.
Access Models: Black Box, Grey Box, and White Box
How much the assessor can see determines what they can find. The choice depends on the assessment objective, not on a general rule about which model is best.
| Access model | What the assessor sees | Use it when the objective is | Limits |
|---|---|---|---|
| Black box | Application programming interface (API) or user interface only. No architectural knowledge. | External attacker realism. What an outsider could reach without inside knowledge. | Shallow. Misses issues that require understanding of prompts, data flows, or tool graphs. |
| Grey box | Scoped access: architecture, system prompts, selected logs, limited data-flow documentation. | Deeper component coverage while keeping some discovery pressure on the assessor. | Requires explicit scoping of what is and isn’t shared, and when. |
| White box | Full access: architecture, prompts, data flows, training data, sometimes weights. | Targeted validation of specific controls or components. | Heavier data-handling controls. Less representative of an external attacker. |
Access can also be staged. The assessment lead takes the full register of known weaknesses, prior evaluations, and open defects, then decides what testers see before blind exploration and what they use during targeted validation. That keeps discovery value without spending engagement time rediscovering issues you already documented.
Timeline and Deployment Prerequisites
Provion’s delivery hypothesis for the AI System Robustness Assessment is two to four weeks for one named system or workflow. That is a working range, not a guarantee, and it moves with system complexity, the agreed access level, reporting depth, and deployment readiness.
Deployment readiness is the variable buyers underestimate. The evidence workspace runs in your environment, so the following need answers before a delivery window means anything:
- Ability to run a versioned Open Container Initiative (OCI) image.
- Identity and access ownership.
- Networking and permitted outbound connectivity.
- Secrets management and storage.
- A local scoring endpoint where the configuration requires one.
- Backup, upgrade, and environment ownership.
- Availability of a production-representative test environment.
If those are unresolved, the honest answer is a separate technical-readiness step before the delivery timeline starts. A vendor who quotes a fixed window without asking these questions is quoting a number, not a plan.
What an External AI Red Teaming Assessment Maps To, and What It Doesn’t
Current mapping scope is deliberately narrow:
- Applicable EU AI Act requirements and documentation logic, based on your role and your system’s classification. Not every system is high-risk and not every organisation is a provider, so the mapping starts with classification rather than assuming obligations.
- The OWASP Top 10 for Large Language Model Applications, 2025 edition, from the OWASP GenAI Security Project, where the categories are relevant to the agreed scope. Verified 24 July 2026.
This is mapping and evidence support, not certification, proof of compliance, or a conformity assessment. One finding can support more than one mapping, but a generic assessment doesn’t produce defensible coverage of multiple frameworks without additional scope, tests, and expert interpretation. Mappings to MITRE ATLAS, the NIST AI Risk Management Framework, ETSI EN 304 223, ISO/IEC 42001, OWASP agentic guidance, and dedicated Model Context Protocol testing are later-scope work. We don’t contract for them today.
Where the EU AI Act applies to you, testing records can inform an internal evidence file rather than satisfy an obligation on their own:
- Article 9 requires a risk management system for high-risk systems. Adversarial findings with severity and remediation status are inputs to it.
- Article 15 requires appropriate accuracy, robustness, and cybersecurity. Article 15(5) requires high-risk systems to be resilient against attempts by unauthorised third parties to alter their use, outputs, or performance by exploiting system vulnerabilities, and names data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks, and model flaws.
- Article 11 and Annex IV set out technical documentation, including testing and validation records.
- Article 72 requires providers of applicable high-risk systems to establish a post-market monitoring system proportionate to the technology and its risks, and to collect, document, and analyse performance data throughout the system’s lifetime. It sets no testing cadence. Anyone citing Article 72 as a reason you need recurring scans is reading something into it that isn’t there.
- Article 43(4) requires a new conformity assessment after a substantial modification to a high-risk system that has already been assessed. It also states that changes pre-determined by the provider at the initial conformity assessment, and documented under Annex IV point 2(f), do not count as a substantial modification. It is not a general trigger for continuous testing.
A report of this kind supports an internal evidence file and can inform technical documentation. It isn’t something you hand to a notified body without translation, interpretation, and legal review. For classification logic, the detailed obligations, and penalties, see what the EU AI Act requires from high-risk AI systems.
Legal status last verified: 24 July 2026. The Digital Omnibus on AI (procedure 2025/0359(COD)) was adopted by the Council on 29 June 2026 and signed on 8 July 2026. On that date it was awaiting publication in the Official Journal, and enters into force three days after publication. Once in force it moves stand-alone Annex III high-risk obligations to 2 December 2027 and high-risk systems embedded in regulated products to 2 August 2028. Until then the AI Act’s existing calendar remains the law in force. Check the Council’s AI Act timeline before relying on these dates.
What to Require in the Statement of Work
Treat the following as contractual, not aspirational. Each item maps to a stage above.
- The named system or workflow under test, its boundary, and its exclusions.
- The assessment objective and the decision it supports.
- The access model, black box, grey box, or white box, with what is shared and when.
- The testing environment and its documented differences from production.
- Permitted and prohibited techniques, testing windows, and rate or cost limits.
- Data handling: permitted test data, evidence handling, retention, and the data-flow description for any component deployed in your environment.
- The escalation path, the critical-finding threshold, and the disclosure route during the engagement.
- Expert validation as a gate, stated explicitly, so no automated score becomes a final finding on its own.
- The evidence handoff: what stays in your environment, which exports are provided, and in which formats.
- The final readout, its audience, and its date.
- Optional retest or evidence refresh terms, including scope, trigger, and price.
- The named engagement lead accountable for testing quality.
What shouldn’t be in there: a promise of certification, a claim of audit-readiness without a named audience and stated limits, or mappings to frameworks the vendor hasn’t implemented and validated.
Scope One System
Five questions are worth answering before you sign anything: what gets tested, how the engagement runs, what evidence stays in your environment, what you receive at the end, and what the SOW commits to. A proposal that can’t answer all five in writing is not yet a proposal.
Provion’s public offer is the AI System Robustness Assessment: one named AI system or workflow, tested through the seven stages above, with expert-validated findings, remediation guidance, and an evidence record retained in your environment.
The most useful first step is to look at the output rather than the offer. Review a Provion sample report to see how a finding is built, from test vector through expert validation and severity to remediation and retest. If you have one named system and a decision that needs evidence, book a scoping call to define what the assessment should cover.
