Cryptographic evidence that your AI systems were adversarially tested, vulnerabilities were tracked, and remediations were verified.
Who this is for: AI security teams, CISOs, compliance officers, and red team leads governing adversarial testing programs for production AI systems.
Automated red teaming achieves 84% attack success vs 13% for human testers (OpenAI GPT-Red, July 2026). Regulators increasingly require evidence that adversarial testing was performed before deployment.
Automated adversarial testing is powerful but creates its own governance burden. Organizations must prove five things to regulators, auditors, and internal risk committees:
Without cryptographic evidence, red teaming is just a checkbox exercise. SWT3 Witness Anchors make each of these five requirements independently verifiable.
| Regulation | Requirement | Effective |
|---|---|---|
| Illinois SB 315 | Annual independent third-party safety audits for frontier AI systems. Mandatory incident reporting within 72 hours of discovering a safety-critical vulnerability. | Jan 1, 2028 |
| EU AI Act Art. 9 | Risk management measures must include adversarial testing for high-risk AI systems. Testing must be documented and retained for the lifetime of the system. | Aug 2, 2026 |
| EU AI Act Art. 15(4) | High-risk AI systems shall be resilient against attempts by unauthorized third parties to alter their use, outputs, or performance by exploiting system vulnerabilities. | Aug 2, 2026 |
| NIST AI RMF MEASURE 2.7 | AI system resilience and robustness are evaluated, including adversarial testing, stress testing, and performance under degraded conditions. | Voluntary |
| NIST AI RMF MEASURE 2.9 | Confidence calibration testing to evaluate whether the AI system's stated confidence levels reflect actual performance under adversarial conditions. | Voluntary |
Each of these requirements demands evidence, not just assertions. SWT3 Witness Anchors satisfy the documentation and retention requirements across all five mandates simultaneously.
The AI-REDTEAM.1 procedure witnesses adversarial test campaigns. Each campaign execution produces a Witness Anchor that records three factors:
Which attack category was tested. AI-REDTEAM.1 recognizes 10 coverage categories:
What type of perturbation was applied during testing:
The number of test cases executed in this campaign run. Combined with Factor A and Factor B, this gives auditors a quantitative measure of test coverage.
Red teaming hardens a model before deployment. Runtime defense witnessing proves that the hardened defenses remain active in production.
AI-SEC.1 (Adversarial Threat Detection) witnesses detection events during production inference. When a prompt injection is detected or a jailbreak attempt is blocked, AI-SEC.1 mints a Witness Anchor recording the event type, detection method, and outcome.
AI-SEC.2 (Input Validation and Sanitization) witnesses input preprocessing. Every sanitization action, from encoding normalization to content filtering, produces an anchor proving that input validation controls were active.
Together, AI-SEC.1 and AI-SEC.2 complement AI-REDTEAM.1 by providing continuous evidence that defenses hardened by red teaming remain operational. A declining rate of AI-SEC.1 detections after a red teaming cycle is a positive signal: it indicates that the attack surface was reduced.
Discovering a vulnerability is only the first step. Regulators require evidence that every discovered vulnerability was tracked through remediation to verified closure. SWT3 v6.0 lifecycle chains provide this evidence through linked anchors sharing a common cycle_id.
INITIATED: A vulnerability is discovered during red teaming. The first anchor in the chain records the attack category, perturbation type, and severity. This anchor's timestamp proves when the vulnerability was identified.
MONITORING: Remediation is in progress. This stage covers patch development, model retraining, guardrail updates, or other mitigation work. Additional anchors may be minted at this stage to record intermediate progress. Each shares the same cycle_id.
RESOLVED: The fix has been applied, the model has been re-tested, and the vulnerability is confirmed closed. The final anchor in the chain records the re-test results and links back to the original discovery via cycle_id.
Auditors can query the chain endpoint with a cycle_id to retrieve the complete remediation history. A chain missing its RESOLVED stage means the vulnerability remains open. This is the same lifecycle chain infrastructure used by AI-EMRG.1 for emergency overrides, applied here to vulnerability management.
Automated red teaming tools are uncovering entirely new attack classes that manual testers miss. One example is the fake chain-of-thought attack, where adversaries insert spoofed reasoning steps into a model's chain of thought. The model appears to reason correctly, but the intermediate steps have been manipulated to steer the final output.
SWT3's AI-INF.1 procedure captures inference provenance independently of the model's own reasoning. The Witness Anchor records SHA-256 hashes of both input and output at each inference step. If the chain of thought is manipulated after the fact, the fingerprint diverges from the expected pattern, providing a tamper-evident baseline that exists outside the model's own reasoning process.
This independence is critical. A model cannot attest to its own integrity. An external witness can.
Purpose: Witnesses the execution of adversarial test campaigns against AI systems. Records which attack categories were tested, what perturbation types were applied, and how many test cases were executed.
SWT3 witnesses: Each campaign run produces a Witness Anchor with Factor A (coverage category), Factor B (perturbation type), and Factor C (test result count). The anchor's timestamp proves when testing occurred relative to deployment.
Verify all 10 attack categories were tested by filtering AI-REDTEAM.1 anchors by Factor A. Gaps in coverage indicate incomplete red teaming. Cross-reference anchor timestamps against deployment dates to confirm testing preceded production release.
Purpose: Witnesses runtime detection of adversarial activity during production inference. Records prompt injection detections, jailbreak blocks, and other threat events as they occur.
SWT3 witnesses: Each detection event produces a Witness Anchor recording the event type, detection method, and whether the threat was blocked or flagged for review.
Sort AI-SEC.1 anchors by timestamp to observe detection rate over time. A decreasing detection rate after a red teaming cycle indicates that hardening is working. A sudden spike may indicate a new attack vector requiring investigation.
Purpose: Tracks the full remediation cycle from vulnerability discovery through verified closure using lifecycle chains. Each stage (INITIATED, MONITORING, RESOLVED) mints a separate anchor linked by a shared cycle_id.
SWT3 witnesses: The chain provides a complete, tamper-evident timeline from discovery to resolution. Each anchor in the chain is independently verifiable. The chain endpoint returns all anchors for a given cycle_id.
Query the chain endpoint with cycle_id to retrieve the full remediation history. A missing RESOLVED stage means the vulnerability remains open. Compare the INITIATED timestamp against the RESOLVED timestamp to calculate time-to-remediation.
Purpose: Witnesses model robustness evaluation under adversarial conditions. Records robustness scores, test configurations, and performance degradation metrics.
SWT3 witnesses: Each robustness evaluation produces a Witness Anchor recording the test configuration, perturbation parameters, and resulting performance metrics.
Compare AI-ROBUST.1 anchors before and after red teaming cycles to quantify hardening improvement. A robustness score that increases after remediation provides concrete evidence that the red teaming program is effective.
| Examiner Question | Where to Look |
|---|---|
| Was this model adversarially tested before deployment? | AI-REDTEAM.1 anchors. Compare anchor timestamps against deployment date. Anchors must predate production release. |
| Which attack categories were covered? | AI-REDTEAM.1 Factor A values. Filter by model ID and list distinct coverage categories. All 10 categories should be present for comprehensive testing. |
| Were discovered vulnerabilities remediated? | AI-EMRG.1 lifecycle chains. Query by cycle_id. Every chain should reach the RESOLVED stage. Open chains indicate unresolved vulnerabilities. |
| Are runtime defenses still active after hardening? | AI-SEC.1 and AI-SEC.2 anchors in the production ledger. Continuous anchors prove that detection and sanitization controls remain operational. |
| How effective was the red teaming program? | AI-ROBUST.1 anchors before and after remediation. Compare robustness scores across red teaming cycles to quantify improvement. |
| Can you prove the fixed model was re-tested? | AI-REDTEAM.1 anchors with timestamps after the AI-EMRG.1 RESOLVED anchor. Same attack category, same model, later timestamp. |
SWT3 is vendor-neutral. It witnesses the results of adversarial testing regardless of which tool performs the testing. Compatible tools include:
The SWT3 witness layer sits below the testing tool. It does not perform adversarial testing. It records that testing was performed, what was tested, and what was found. The testing tool generates the results. SWT3 makes those results independently verifiable.
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup