AI Red Teaming Delivery and Execution Framework

Release status · Approved for publication.

Purpose and scope

AI red teaming is an authorized, risk-driven exercise that uses adversarial testing to discover how an AI system can be manipulated or misused, what harm could follow, and whether safeguards prevent, detect, or contain that harm. The exercise produces evidence for release, remediation, and ongoing oversight decisions.

The framework applies to enterprise AI applications, including generative AI assistants, retrieval-augmented generation (RAG) systems, and agents that can use tools or take actions. The test boundary should reflect how the system is intended to operate, including the model, application, data, integrations, identities, permissions, and human oversight. Coverage can include model behavior and system-level outcomes such as data disclosure, unauthorized actions, and failures of monitoring or human approval.

Relationship to the Hiroshima AI Process

The Institute draws selectively on the Hiroshima Process International Code of Conduct and the Japan AI Safety Institute (J-AISI) Guide to Red Teaming Methodology on AI Safety v1.10. The Code supplies governance principles for organizations developing advanced AI systems. The J-AISI guide supplies a practical reference for planning, scenario design, test execution, and improvement. The Institute adapts both to enterprise delivery, including organizations that integrate or deploy models from third parties.

Reference	Application in this framework
Hiroshima Code, Action 1	Evaluate and mitigate risks across the lifecycle. Select an appropriate mix of internal and independent external testing based on risk. Preserve traceability from evidence to decisions.
Hiroshima Code, Action 2	Monitor for vulnerabilities, incidents, emerging risks, and misuse after deployment. Use those signals to trigger reassessment.
J-AISI guide, Chapter 6	Plan and authorize the exercise. Prepare the test environment and establish escalation.
J-AISI guide, Chapter 7	Develop risk and attack scenarios, execute them, and record evidence.
J-AISI guide, Chapter 8	Analyze and report findings, implement improvements, and follow up through retesting as needed.

The six phases, deliverables, and release decision below are proposed Institute practices. The crosswalk identifies selected influences.

Delivery and execution lifecycle

Phase	Core activity	Deliverable
1. Scope and authorize	Identify the decision the exercise will inform. Establish system boundaries, authorized access, permitted actions, stop conditions, escalation contacts, and the degree of tester independence. Prepare a controlled environment and representative test data.	Approved engagement charter and rules of engagement
2. Design scenarios	Identify credible harms and affected parties. Translate each priority risk into one or more testable attack scenarios with an actor, prerequisites, attack path, expected safeguards, and observable success criteria.	Prioritized risk and attack scenario matrix
3. Execute and capture evidence	Combine repeatable scripted tests with exploratory testing. Record system versions, configurations, identities, inputs, outputs, tool calls, and relevant telemetry. Repeat material cases where behavior varies and report the number of trials and observed outcomes.	Execution log and evidence package
4. Triage and report	Confirm findings and assess impact, exploitability, and exposure in context. Distinguish observed effects from plausible downstream harm. Escalate critical discoveries promptly and document coverage gaps.	Findings report and AI risk register entries
5. Remediate and retest	Assign owners and target dates. Verify mitigations against the original attack path and credible variants. Present unresolved risks, compensating controls, and retest results to the accountable release authority.	Retest evidence and documented decision to approve, restrict, or hold release
6. Monitor and reassess	Convert material scenarios into regression tests and monitoring signals. Reassess after relevant incidents or material changes to models, system instructions, data sources, tools, permissions, or deployment context.	Monitoring plan and reassessment triggers

Accountability and traceability

The engagement sponsor commissions the exercise and authorizes its scope. The red team lead owns test design, execution, evidence quality, and escalation. The system and control owners implement mitigations. The accountable release authority records the release decision and any acceptance of residual risk within its delegated authority. For higher-risk systems, use a separate review function or external testing where warranted by the system’s potential impact and the need for independence.

Each priority risk should have a traceable record connecting the risk scenario, attack scenario, tested safeguards, evidence, finding, remediation owner, retest status, and release or follow-up decision. Record which configurations and scenarios were exercised so reviewers can judge the scope of the evidence.

Worked example

An enterprise assistant retrieves internal documents and can send email. The risk scenario is unauthorized disclosure of a restricted record. The attack scenario tests whether instructions embedded in a retrieved test document can induce the assistant to send a restricted synthetic record to a controlled external mailbox.

The team traces the retrieval identity and permissions, the proposed tool call, any approval or policy decision, the monitoring alert, and the mailbox outcome. An assistant proposing an attachment, a mail tool blocking the action, and a mailbox receiving the record represent distinct outcomes. Each points to a different safeguard or control owner. After a fix, the team repeats the original scenario and credible variants and records the results in the risk register.

Primary references

Revision history

Version	Date	Status	Changes
v0.1	November 5, 2026	Initial draft	Established the six-phase methodology, reference crosswalk, and worked example.
v0.2	November 5, 2026	Published	Added Institute branding, review status, revision history, and disclaimer. Retained the v0.1 methodology.