AI Red Teaming vs Blue Teaming: A RACI for Production AI

AI red teaming creates a repeatable failure on purpose. Blue teaming detects and contains hostile or unsafe behavior in production. It handles the incident and restores the service. Purple teaming turns the finding into a named defensive change and a retained retest. Microsoft PyRIT and NIST SP 800-61 Rev. 3 support different parts of that operating model. I would give the purple-team lead authority to reject a release when the finding lacks an owner or the retest lacks evidence. Otherwise, "collaboration" becomes a meeting with no control change.

TL;DR

• Red teams design repeatable adversarial tests and preserve the payload and observed outcome. They also retest the fix.
• Blue teams own production detection and incident response. They also own containment and recovery, including continued operation of the defensive control.
• Purple teams connect each finding to its owner and the relevant policy or code change. They also retain the retest and regression evidence.
• DeepInspect contributes only on authenticated HTTP model traffic deliberately routed through it; hosts and credentials need their own defenders. Stores and local tools do too. Downstream APIs do too.

Red teams produce reproducible findings

Microsoft's PyRIT repository provides current, repeatable tooling for generative AI red teaming. The important word is repeatable. A useful finding includes the target route and test identity, plus the payload or conversation. It records the observed response and expected policy, with enough context to run the case again.

That artifact separates a red-team result from an anecdote. The red team owns attack design and safe execution, plus evidence collection and severity rationale. It should also state the tested boundary. A prompt injection against an HTTP model endpoint says nothing about a local command runner unless the test exercised that component.

The AI red-teaming workflow covers the test-fix-prove loop in detail. In this comparison, the red-team handoff ends only when a defensive owner can reproduce the case. A screenshot with a red box around an unsafe answer is a poor handoff. The exact payload and route, paired with the identity and policy state, make the finding operable when paired with the timestamp.

Blue teams own production defense and incidents

NIST SP 800-61 Rev. 3 covers incident detection and response, followed by recovery and continuous improvement as defensive operating responsibilities. For AI systems, that work spans model requests and several adjacent systems: identity providers and retrieval stores, application hosts and tool brokers, plus downstream APIs and evidence platforms.

The blue team owns the detection and response design on those production surfaces. It configures telemetry and alert routing and establishes containment actions. The same team preserves evidence and coordinates recovery. It also measures whether the control still works after change. A prompt-related incident may begin at the model route and continue through an authorized tool call. The defensive owner follows the complete path.

Blue teams also decide what happens when a control is unavailable. A request filter can fail closed or degrade to a limited route. It can also stop the application. A retrieval store may need access revoked. A compromised host may require isolation. Those are production decisions with service consequences, and the blue team needs approved playbooks before the red team trips the condition at 2:00 p.m. on a Thursday.

The AI incident response playbook provides the wider response structure.

Purple teams convert findings into durable controls

Purple teaming is the operating bridge. It assigns the finding and agrees on the control change. It schedules the retest and preserves evidence that the original payload now produces the expected result. The role can sit with security engineering or product security. A dedicated exercise lead can also own it. The title matters less than the authority to close weak handoffs.

Every purple-team ticket should contain:

• the stable finding and test-case identifiers;
• the affected asset and route;
• the defensive owner;
• the selected code or policy change, or the selected identity or host change, including any process change;
• the acceptance test and expected outcome;
• the evidence location and retention owner;
• the regression cadence.

One concrete detail catches many weak programs: print the unresolved ticket list before the release review. If a high-severity row has an empty owner cell, the release is carrying an accepted risk that nobody has accepted.

Purple teams should also reject category errors. A prompt filter cannot repair an overprivileged database account. A host agent cannot authorize a model request by user role. The control must sit on the path that produced the finding.

The RACI starts with attack surfaces

A practical RACI names one accountable owner per surface. Several teams may be responsible for tasks, but shared accountability usually means delayed closure.

Prompt and response path

The red team designs injection and jailbreak tests, plus data-exposure and output-policy tests. The AI platform or blue-team control owner is accountable for the production rule and event. The purple lead coordinates retest and regression evidence. Compliance may be consulted on data classes and retention.

Identity and delegated authority

The red team tests role boundaries and service identities. IAM or the application identity owner is accountable for verified identity and token scope. The blue team monitors suspicious access and owns containment. The purple lead confirms the original identity fixture produces the intended denial after repair.

Retrieval stores

The red team plants controlled adversarial content and tests unauthorized retrieval. The data platform owner is accountable for repository permissions and indexing controls. The blue team owns detection and evidence preservation. Model-route controls can inspect resulting HTTP content, but repository access remains with the store owner.

Hosts and local tools

The red team tests only under explicit rules of engagement. Endpoint or platform security owns host isolation and process controls, plus credentials and local execution. A model gateway stays informed when the event also crossed its route; it is not accountable for STDIO or shell behavior outside that route.

Downstream APIs and tool calls

The red team tests arguments and authorization boundaries. The tool owner or API team is accountable for server-side authorization. The blue team monitors misuse and revokes access during an incident. A routed policy point may contribute a deny decision, while the downstream service retains final authorization responsibility.

Findings need acceptance criteria

A finding should move through four states. It is reproduced and assigned, then repaired and verified. "Mitigated" is too loose for release evidence. The repair can be a policy change or code fix. It can also be a permission reduction or model configuration. It can also be a data-store change or operating procedure. The expected retest must name the route and result.

For an HTTP prompt-injection finding, the acceptance packet might include the original payload and test identity, plus the target route and policy version. It also needs the denied response and decision event. For a retrieval permission issue, the packet needs the repository ACL change and a failed retrieval attempt. A host compromise requires endpoint evidence. The artifacts should match the control.

Regression belongs in the definition of done. Add the test to the appropriate suite and define when it runs. PyRIT can support repeatable generative AI tests; other surfaces need their own tooling. The purple team records the suite and cadence because one runner cannot cover the whole system.

Production exercises need rules of engagement

Set the target assets and test identities before execution. Set the allowed hours and stop conditions too. Define data fixtures and evidence handling. Name the incident contacts. Use synthetic sensitive data. Coordinate any test that could trigger a real downstream action. A red-team prompt that sends an email or modifies a ticket has crossed into an operational system.

The blue team should know the exercise window without receiving the exact payload. That protects production while preserving a meaningful detection test. Afterward, compare the red-team timeline with alerts. Then compare it with response actions. Record missed signals as findings.

I prefer a short rules-of-engagement document that names ten concrete boundaries over a polished methodology deck. The document gets used during the exercise. The deck usually stays closed.

DeepInspect

DeepInspect can support the prompt and response lane when an application or agent deliberately routes authenticated HTTP model traffic through its proxy. A red-team finding on that route can become an identity-aware policy rule. The rerun can then produce a decision record showing the test identity and route, plus the active policy and action, with the timestamp outside the calling application's write path.

That contribution has a hard edge. DeepInspect cannot isolate a compromised host or rotate a stolen credential. It cannot repair a retrieval ACL or contain a local command. It also cannot enforce authorization inside a downstream API. The RACI should assign those surfaces to their actual defenders and use DeepInspect only for the HTTP request path it receives.

Book a technical deep dive at deepinspect.ai.