Autonomous AI agents are now attack vectors, not just targets. Cryptographic witnessing transforms incident response.
Who this is for: Security teams, incident response professionals, CISOs, SOC analysts, and compliance officers responsible for AI systems that use tools, access data, or take autonomous actions.
The threat model has changed. AI agents no longer just process text. They execute code, call APIs, query databases, and take autonomous actions. When a malicious dataset, compromised tool, or poisoned model enters the supply chain, the agent becomes the attack vector. Without governance records, forensic reconstruction requires weeks. With SWT3, it takes minutes.
Traditional AI security focused on protecting models from adversarial inputs: prompt injection, jailbreaking. The threat surface was the model boundary. A bad input came in, a bad output went out. The containment perimeter was clear.
Autonomous AI agents expand the threat surface to the entire supply chain: datasets, tools, MCP servers, API integrations, container images, model weights, and the orchestration layer itself. Each component is a potential entry point. Each integration is a trust boundary that must be defended and attested.
When an agent can take 17,000 actions without human intervention, each action is a potential attack step. The agent's capability is the attacker's capability. An agent that can read a database, call an external API, and write to a file system is an agent that an attacker can use to do exactly those things, if any link in the supply chain is compromised.
Key insight: The traditional security perimeter does not contain autonomous agents. They operate across network boundaries, access credentials, invoke tools, and chain actions together. Governance must exist at the action level, not the perimeter level. Every inference, every tool call, every access decision is a governance event that should be witnessed independently of the application's own logging.
SWT3 is the notary for these events. It does not enforce security policy. It creates an independent, tamper-evident record that security policy was applied and what the outcome was. This record exists outside the compromised system and cannot be altered after the fact.
The following table maps each stage of a supply chain attack against an AI agent to the SWT3 evidence that would exist if witnessing was active before the incident.
| Attack Stage | What Happens | Traditional Detection | SWT3 Evidence |
|---|---|---|---|
| Dataset poisoning | Malicious data injected into training or fine-tuning datasets | Post-hoc analysis, if detected at all | AI-SUPPLY.1 records dataset provenance, hash, and source |
| Model compromise | Weights modified via backdoor, trojan, or supply chain attack | Weights hash comparison (manual) | AI-MDL.1 cryptographic hash per deployment, automated drift detection |
| Tool exploitation | Compromised MCP server or API returns malicious payloads | Application logs (if they exist) | AI-TOOL.1 records every tool call, arguments hash, result hash |
| Code execution | Agent executes generated code with production credentials | Runtime monitoring, maybe | AI-CHAIN.1 links every action in the execution chain |
| Credential harvesting | Agent accesses secrets, API keys, database credentials | SIEM correlation (hours or days) | AI-ACC.1 records every access decision in real time |
| Lateral movement | Agent uses harvested credentials to access other systems | Network monitoring, NDR | AI-CHAIN.1 lifecycle chain shows the full action sequence |
| Autonomous deviation | Agent takes actions outside its defined boundaries with no human checkpoint | Hope someone notices | AI-AUTO.2 records boundary violations as they occur |
Seven SWT3 procedures cover the AI agent supply chain attack surface. Each card describes the security context, what SWT3 witnesses, and how assessors use the evidence.
Security context: Every component in the AI stack is a supply chain risk: model weights, training data, serving frameworks, container images, MCP servers, tool libraries. A single compromised component can turn the entire agent into an attack tool. Recent incidents demonstrate that model distribution platforms themselves can be targeted, not just the models they serve.
SWT3 witnesses: AI-SUPPLY.1 records the provenance of every component: weights hash, framework version, dependency manifest hash, container image digest. Creates a verifiable bill of materials that can be audited after an incident. The anchor exists before the incident occurs, establishing the known-good baseline.
AI-SUPPLY.1 anchors create the baseline for incident investigation. If any component changes between assessments, the hash changes and the discrepancy is visible. Compare against known-good manifests from the most recent clean deployment. A hash mismatch between assessments is a finding that requires explanation.
Security context: Agents use tools to interact with the world: MCP servers, database connectors, API clients, file system access, code interpreters. Each tool invocation is an action taken by the AI system outside its language generation boundary. Without witnessing, there is no forensic record of what tools were called or what they returned. Application logs are not sufficient because they can be tampered with by an attacker who controls the application layer.
SWT3 witnesses: wrap_tool() records every tool invocation with the tool name, arguments hash, result hash, and execution time. In a multi-step attack, the tool call graph reveals the exact sequence of actions the agent took. The record is independent of the application and cannot be altered retroactively.
AI-TOOL.1 anchors are the forensic backbone for agent incidents. The tool call graph shows which tools were called, in what order, and whether the results matched expected patterns. Look for calls to tools outside the agent's defined scope, or argument patterns that do not match normal usage profiles.
Security context: Agents often run with service account credentials that have broad access. When an agent is compromised, those credentials become the attacker's credentials. Without access witnessing, there is no record of what the agent accessed during the attack window. Application-level logs are insufficient because an attacker who controls the agent can also suppress or alter those logs.
SWT3 witnesses: wrap_access() records every access decision: who requested access, what resource was targeted, what permissions were checked, and whether access was granted. Creates a real-time access log that survives even if application logs are tampered with. The access record is immutable from the moment it is minted.
AI-ACC.1 anchors prove the access pattern during any time window. Compare the recorded access decisions against the agent's permitted scope to identify unauthorized access. Any access to resources outside the defined scope is a finding, regardless of whether application-level access controls blocked it.
Security context: Security events in AI systems are different from traditional application security events. Model behavior anomalies, guardrail bypasses, unexpected tool outputs, and inference pattern changes are all security-relevant but rarely captured by traditional SIEM systems. These systems were not designed for the event types that AI agents generate.
SWT3 witnesses: AI-SEC.1 records security-relevant events from the AI system: guardrail failures, anomalous inference patterns, tool execution errors, and boundary violations. These events are witnessed independently of the application's own logging, providing a second source of truth that survives application-layer tampering.
AI-SEC.1 anchors provide a security event timeline that is independent of the application under investigation. This is critical for forensics when application logs may be unreliable. Cross-reference AI-SEC.1 events with AI-INF.1 inference anchors to identify inferences that produced security events versus those that completed normally.
Security context: Autonomous agents chain actions together: query database, process results, call API, generate code, execute code. Each step depends on the previous step. In an attack scenario, the chain reveals the attacker's progression through the system. Without chain witnessing, investigators must reconstruct this sequence from disparate log sources across multiple systems, each with their own timestamp formats and retention policies.
SWT3 witnesses: AI-CHAIN.1 links every action in a sequence using lifecycle chains with shared cycle IDs. The complete chain is queryable from any single anchor in the sequence. Forensic investigators can trace the full attack path from any point of detection, forward to the full impact scope, or backward to the initial compromise.
AI-CHAIN.1 lifecycle chains show the complete action sequence. Start from the detection point and trace backward to the initial compromise, or forward to the full impact scope. A chain that terminates unexpectedly may indicate an action that the agent took but did not witness, which is itself a finding.
Security context: Autonomous agents can take thousands of actions without human checkpoints. The EU AI Act Art. 14 requires human oversight for high-risk AI systems. When an agent operates autonomously and causes harm, the first question from regulators and legal counsel is: was anyone supposed to be watching, and if so, what were they watching for? Without governance records, this question cannot be answered with evidence.
SWT3 witnesses: AI-AUTO.2 records the autonomy boundaries for each inference: what actions are permitted, what requires human approval, and whether the agent operated within its defined boundaries. A boundary violation is witnessed as it occurs, not discovered weeks later during a forensic investigation.
AI-AUTO.2 anchors answer the "was anyone watching?" question with cryptographic evidence. Shows whether human oversight policies were active and whether the agent stayed within its boundaries. Any anchor with a boundary violation flag is a finding that requires an associated remediation record.
Security context: Agent configuration defines the agent's behavior envelope: system prompts, tool permissions, model selection, temperature settings, context window management. Unauthorized configuration changes can expand the agent's capabilities without any model change or weight modification. This is one of the lowest-effort, highest-impact attack vectors against deployed agents.
SWT3 witnesses: AI-BASE.1 records the configuration at attestation time. Configuration drift from the approved baseline produces a new anchor with different values. The delta between anchors reveals exactly what changed, when it changed, and what the configuration was before and after the change.
Compare current AI-BASE.1 anchors against the approved baseline. Any discrepancy indicates configuration drift that may have expanded the agent's attack surface. Pay particular attention to changes to system prompt content, tool permission lists, and autonomy boundary settings.
The difference between a 2-minute evidence export and a 6-week forensic investigation is whether the governance records existed before the incident.
With SWT3: Query lifecycle chains by time window. Export the complete action sequence, tool call graph, access decisions, and configuration state. The evidence package is self-contained and independently verifiable. No vendor log requests. No manual correlation across systems. No reliance on the compromised system's own records.
Without SWT3: Collect application logs from multiple services. Request API logs from providers (response time: days to weeks). Correlate timestamps across systems with different time zones, formats, and retention policies. Reconstruct the action sequence manually. Interview operators. Hope the attacker did not tamper with logs. Produce a report that opposing counsel can challenge because it relies on logs controlled by the organization under investigation.
The following example shows how to export a forensic evidence package for a compromised agent:
from swt3_ai import SWT3Witness
witness = SWT3Witness(api_key="axm_live_your_key", tenant_id="your_tenant_id")
# Export all anchors for the compromised agent within the incident window
evidence = witness.export(
agent_id="compromised-agent-prod",
start="2026-07-15T00:00:00Z",
end="2026-07-16T23:59:59Z"
)
# The evidence package contains every inference, tool call, access decision,
# and configuration change. Self-contained. Independently verifiable.
# No vendor log requests. No manual correlation.The export returns a signed JSON package containing all anchors within the time window, sorted by timestamp, with lifecycle chain links resolved. The package can be shared directly with IR teams, legal counsel, regulators, and insurance carriers without any additional processing.
The SWT3 evidence package produced by a forensic export contains the following components:
| Component | Procedure | Contents |
|---|---|---|
| Inference anchors | AI-INF.1 |
Every inference: prompt hash, response hash, model identity, timestamp, clearing level |
| Tool call graph | AI-TOOL.1 |
Every tool invocation: tool name, arguments hash, result hash, execution time, order in chain |
| Access decisions | AI-ACC.1 |
Every access event: resource, permissions checked, decision (grant or deny), timestamp |
| Configuration state | AI-BASE.1 |
Configuration hash at time of deployment and any subsequent changes detected |
| Supply chain manifest | AI-SUPPLY.1 |
Component hashes: model weights, framework version, dependency manifest, container digest |
| Security events | AI-SEC.1 |
Guardrail failures, anomalous patterns, boundary violations, execution errors |
| Action chains | AI-CHAIN.1 |
Full lifecycle chains with shared cycle IDs linking related actions in sequence |
Each anchor in the package is SHA-256 fingerprinted and independently verifiable at sovereign.tenova.io/verify. The fingerprint formula is publicly documented and cross-language verified, so any party can confirm that an anchor has not been altered since it was minted.
The package can be shared with IR teams, legal counsel, regulators, and insurance carriers. Critically, the evidence exists outside the compromised system. It cannot be tampered with by the attacker, because the attacker would need to compromise the SWT3 ledger independently from the application under attack. The two systems are not co-located by design.
Forensic reconstruction is the reactive use case for SWT3 witnessing. The preventive use cases are equally important: detecting configuration drift, identifying unusual tool usage patterns, and surfacing boundary violations before they become incidents.
AI-BASE.1 anchors capture configuration state at attestation time. Any unauthorized change is visible by comparing consecutive anchors. The hash changes when the configuration changes. Set up alerts for configuration drift by comparing the most recent AI-BASE.1 anchor hash against the approved baseline hash. A mismatch requires immediate investigation.
AI-TOOL.1 anchors capture normal tool usage patterns over time. A sudden increase in tool calls, calls to tools not seen in baseline periods, or unusual argument patterns indicate potential compromise. The anchor stream provides a behavioral baseline that can be compared against current patterns without requiring the agent's own application logs.
AI-AUTO.2 anchors record boundary violations in real time. An agent exceeding its defined boundaries is immediately visible in the witness stream. This allows security teams to investigate a potential compromise before it progresses to credential harvesting or lateral movement. The violation anchor exists as evidence regardless of whether the agent's application logs were preserved.
| Framework | Relevant Requirements | SWT3 Evidence |
|---|---|---|
| NIST 800-53 | SI-7 (software integrity), IR-4 (incident handling), SA-12 (supply chain), AU-6 (audit review) | AI-SUPPLY.1, AI-CHAIN.1, AI-SEC.1, AI-INF.1 |
| EU AI Act | Art. 9 (risk management), Art. 14 (human oversight), Art. 15 (accuracy and robustness), Art. 72 (post-market monitoring) | AI-AUTO.2, AI-GRD.1, AI-BASE.1, AI-INF.1 |
| CMMC | SI.L2-3.14.1 (flaw remediation), AU.L2-3.3.1 (audit), SC.L2-3.13.11 (CUI encryption) | AI-SUPPLY.1, AI-CHAIN.1, AI-ACC.1 |
| EO 14028 (Cyber) | Software supply chain security, SBOM requirements | AI-SUPPLY.1, AI-BASE.1 |
If your team cannot answer these questions within 10 minutes, your AI governance has gaps. Run this exercise before an incident, not after. The goal is to identify which questions you cannot answer quickly, then use that list to prioritize witnessing implementation.
| # | Question | SWT3 Answer Source |
|---|---|---|
| 1 | Which AI agents in your environment have tool access? What tools can they call? | AI-BASE.1 configuration anchors, AI-TOOL.1 baseline call history |
| 2 | Can you produce the complete action history for any agent over the last 24 hours? | AI-CHAIN.1 lifecycle chains, AI-INF.1 inference stream |
| 3 | If an agent accessed credentials, can you identify which credentials and when? | AI-ACC.1 access decision anchors with resource and timestamp |
| 4 | What is the SHA-256 hash of the model weights currently running in production? | AI-SUPPLY.1 component manifest, AI-MDL.1 weight attestation |
| 5 | Can you prove that guardrails were active during every inference in the incident window? | AI-GRD.1 guardrail decision anchors, AI-SEC.1 security event stream |
| 6 | How long would it take to produce an evidence package for your legal team? | With SWT3: minutes. Evidence export is a single API call per agent and time window. |
| 7 | Is your AI audit trail independent of the systems under investigation? | SWT3 anchors are stored in a ledger that is not co-located with the agent infrastructure. |
SWT3 provides cryptographic answers to every question in this exercise. The evidence exists before the incident occurs, not after. Organizations that run this exercise and find gaps have a clear implementation roadmap: each unanswered question maps directly to a witnessing procedure that can be added to the agent's integration.
| Examiner Question | SWT3 Evidence | Procedure |
|---|---|---|
| Show me your AI component bill of materials | Supply chain manifest with cryptographic hashes for every component | AI-SUPPLY.1 |
| How do you detect model compromise between deployments? | Weight hash in AI-MDL.1 anchor compared against baseline; drift alert on mismatch | AI-MDL.1, AI-DRIFT.1 |
| Show me every tool call this agent made last Tuesday | AI-TOOL.1 anchor stream filtered by agent_id and date range, tool name and arguments hash per call | AI-TOOL.1 |
| Did the agent access any resources outside its defined scope? | AI-ACC.1 access decisions compared against permitted scope definition in AI-BASE.1 | AI-ACC.1, AI-BASE.1 |
| Were guardrails active during the incident window? | AI-GRD.1 guardrail anchors confirm active status; AI-SEC.1 shows any guardrail bypass events | AI-GRD.1, AI-SEC.1 |
| Reconstruct the full attack sequence from initial access to impact | AI-CHAIN.1 lifecycle chain: query any anchor in the sequence, resolve full chain by cycle ID | AI-CHAIN.1 |
| Prove the agent operated within its defined autonomy boundaries | AI-AUTO.2 anchors with boundary status for every inference; boundary violations are flagged at the time they occur | AI-AUTO.2 |
| Has the agent configuration changed since approval? | Compare current AI-BASE.1 anchor hash against approved baseline hash; any delta is visible with timestamp | AI-BASE.1 |