How often should the red-team suite run against a production deployment?

The continuous re-test runs on every policy version change, which happens on the deployment's normal policy cadence (typically weekly to daily). A full red-team engagement with human testers running new scenarios happens on a slower cadence (quarterly for most deployments). The two run at different rates because they catch different classes of issue.

Does the workflow require access to production data or just staging?

The workflow runs against staging by default. Production access is required only for tests that probe the identity, policy, and audit configuration in force in production. Those tests run with a designated red-team identity and produce audit records tagged as test executions, which the SIEM excludes from normal alerting.

How does the workflow handle findings that cannot be closed at the inspection layer?

Some findings require model-level or application-level changes. A finding that requires a system-prompt update is a model-configuration fix, not an inspection-layer fix. The workflow tracks the finding through the same record chain, with the fix category recorded as external. The re-test still runs against the deployment, and the evidence artifact still shows the fix in force.

What does the audit record retention look like for red-team tests?

The audit records for red-team tests follow the same retention rules as production audit records. The tests produce records identical in structure to production records, with a test-execution tag. The six-month floor under EU AI Act Article 19 applies, and deployments often extend the retention for red-team records to preserve the evidence chain longer.

Can the workflow ingest findings from external penetration tests?

Yes. External findings enter the fix phase through the same record structure as internal findings. The workflow requires the finding to include the specific input, the observed response, the identified violation, and the severity. Findings that meet the structure translate to policy rules the same way internal findings do.

How does the workflow integrate with the OWASP AISVS verification checklist?

The AISVS 514 requirements include a subset that the workflow evidences directly (the request-layer, tool-call, and response-layer requirements). Each requirement maps to one or more test categories, and the audit records for those tests satisfy the requirement's evidence expectation. Requirements outside the request-layer scope (training data, model supply chain, fine-tuning) require evidence from other source

AI Red Teaming Workflow: The Test-Fix-Prove Loop for Enterprise AI Deployments

AI red teaming produces three artifacts. The finding: a documented vulnerability in prompt handling, tool-call authorization, or response classification. The fix: a policy change, a scope reduction, or an inspection rule that closes the gap. The evidence: a re-test that confirms the fix works and a control that keeps the fix in force. Deployments that treat red teaming as a one-time exercise get the finding and stop there. Deployments that treat it as a workflow get all three artifacts and can present them to an auditor.

The OWASP AISVS 1.0 requirements chapter 14 codifies the pattern. The requirements assume the red-team findings feed a policy layer that turns them into enforcement, and the enforcement produces the evidence for the re-test. The workflow ties the three artifacts to a single record chain.

I want to walk through the test-fix-prove loop for enterprise AI red teaming and the inspection-layer architecture that turns findings into policy the enforcement layer executes.

Scope of AI red teaming

AI red teaming targets three surfaces inside an enterprise deployment.

Prompt handling. The tests probe how the deployment handles inputs designed to break the intended usage: prompt injection, indirect injection through retrieval-augmented content, prompt leakage, and system-prompt disclosure. The finding is a specific input pattern that produces a policy violation, and the fix is the input-side classification or the policy rule that catches the pattern.

Tool-call authorization. The tests probe which tools the AI agent will call for a given identity and whether the tool-call arguments are constrained by scope. The findings are specific identity + tool-call combinations that produce unauthorized activity, and the fix is the scope reduction or the per-tool authorization rule at the inspection layer.

Response classification. The tests probe how the deployment handles responses that contain personal data, sensitive business information, or content that violates the enterprise's content policy. The finding is a response pattern that leaves the boundary without the required classification, and the fix is the response-side rule that catches or redacts the pattern.

The three surfaces map to the enforcement points at the inspection layer. Every finding translates to a rule at one of the three points, and the rule is the fix.

Test phase

The test phase produces the findings. The tests fall into four categories aligned to the OWASP AISVS chapters.

Category 1: Adversarial prompt tests

Prompt-injection payloads that attempt to override the system prompt, extract the system prompt, or trigger tool calls the caller is not authorized to make. The tests draw from public prompt-injection corpora and from internal red-team payloads specific to the deployment's system prompt.

Category 2: Retrieval-augmented content tests

Payloads embedded in retrieval sources that trigger the AI to act on instructions the retrieval content carried, not the user's prompt. The tests inject payloads into staged retrieval documents and observe whether the AI treats the payloads as instructions or as data.

Category 3: Tool-call scope tests

Prompts designed to elicit tool calls that exceed the caller's authorization scope. The tests attempt to escalate scope by asking the AI to call tools on the caller's behalf that the caller cannot call directly.

Category 4: Response classification tests

Prompts designed to elicit responses that contain personal data, sensitive business information, or content that violates policy. The tests observe whether the response-side classification catches the leaks.

Each test produces a finding record with a fixed structure: the test category, the prompt or payload, the observed response, the policy violation identified, and the severity classification.

Fix phase

The fix phase translates each finding into a rule at the inspection layer.

An adversarial-prompt finding produces an input-side classification rule. The rule declares the pattern that triggered the violation and the enforcement action (block, redact, or route to review). The rule enters the policy configuration.

A tool-call scope finding produces a per-tool authorization rule. The rule declares the identity constraint and the tool-call constraint. The rule enters the tool-call authorization configuration.

A response classification finding produces a response-side classification rule. The rule declares the response pattern and the enforcement action (redact or block on delivery).

The three rule types map to the three inspection points the layer already enforces. The fix is a policy change, not a code change. The policy change is versioned, reviewed, and rolled out through the same pipeline that manages the rest of the policy configuration.

Prove phase

The prove phase runs the original test against the deployed fix and produces evidence that the fix works.

The test suite re-executes the failed test against the deployment. The expected outcome is that the inspection layer now catches the pattern and enforces the action the rule declared. The audit record for the re-test shows the rule fired, the enforcement action, and the caller's identity.

The audit record is the evidence artifact. The auditor reviewing the deployment sees the finding, the rule that closed it, and the test execution that confirmed the closure. The chain from finding to fix to evidence is preserved in a single record set keyed by the test execution ID.

Continuous re-test

A one-time re-test is not sufficient. The rule that closed the finding today can be inadvertently modified tomorrow by a policy change unrelated to red teaming. The workflow includes a continuous re-test that runs the full test suite on every policy version.

The re-test runs against the candidate policy version before the version deploys. A regression in a previously closed finding blocks the deploy. The workflow makes the enforcement layer's policy pipeline the gate that keeps closed findings closed.

Compliance implications

The three-artifact chain satisfies multiple compliance obligations.

The EU AI Act Article 15 requirement on accuracy, resilience, and cybersecurity expects the provider to test the high-risk AI system for known vulnerabilities and document the mitigation. The red-teaming workflow produces the test records, the mitigation records, and the re-test records the article expects.

The OWASP AISVS 1.0 chapter 14 (Testing and Verification) requires evidence that testing has been performed, findings have been remediated, and remediation has been verified. The three-artifact chain produces the evidence artifact.

The NIST AI RMF MEASURE 2.6 requires evidence that the AI system has been tested for identified risks. The red-team findings and the enforcement rules that close them are the artifact.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between your users or agents and the LLM APIs they call. Red-team findings translate to inspection-layer rules through the same policy pipeline that manages the rest of the enforcement configuration. The audit record for every test execution captures the finding, the rule, and the outcome.

The workflow is not a one-time engagement. The rules that close findings today stay in force through the continuous re-test that runs on every policy version. The evidence chain is the artifact an auditor reviews.

Book a demo today.