Independent cryptographic accountability for AI-powered security operations. Prove what your detection AI decided, when it decided, and whether guardrails were active.
Who this is for: SOC managers, security architects, compliance officers, and CISO teams operating AI-powered threat detection and response platforms. Assumes familiarity with SIEM/SOAR workflows and a need to produce independent evidence that security AI is operating within policy.
The accountability blind spot: AI-powered SOC tools -- CrowdStrike Charlotte AI, Palo Alto Cortex XSIAM, Microsoft Security Copilot, Cisco XDR -- make autonomous detection and response decisions in real time. These tools log internally, but their logs are self-attested. They produce no independent proof of what the AI decided, when, or why. When regulators or auditors ask for evidence that your security AI operated within policy during an incident, vendor-generated logs alone are insufficient. Independent witnessing closes this gap.
AI-driven security tools make real-time decisions with operational and legal consequences. They block traffic, quarantine endpoints, escalate alerts, suppress false positives, and trigger automated response playbooks. Each of these is a consequential automated decision.
The accountability gap is straightforward: no independent evidence chain proves the AI was operating within policy at the time of each decision.
Internal vendor logs are necessary for operations, but they are self-attested. The platform that made the decision is also the platform that records the decision. This creates a structural conflict when evidence must withstand regulatory or legal scrutiny.
Regulators and auditors increasingly require independent verification of automated decision-making systems. This applies to security AI just as it applies to any other consequential AI system:
The gap is not that security AI tools lack logging. They log extensively. The gap is that those logs cannot be independently verified by a third party without trusting the vendor's own attestation.
SWT3 does not perform threat detection. It witnesses the detection decisions made by your AI-powered security tools and produces independent cryptographic evidence of each decision.
| Security Event | Procedure | What Gets Witnessed |
|---|---|---|
| Adversarial detection events | AI-SEC.1 |
Detection classifier output, threat hash, action taken (block, allow, quarantine) |
| Input analysis (payload inspection) | AI-GRD.1 |
Inspection parameters, rule state, input classification result |
| Response actions | AI-GRD.2 |
Response classification, escalation path, automated vs. manual disposition |
| Behavioral anomalies | AI-VIO.1 |
Baseline deviation magnitude, severity classification, threshold at time of detection |
| Inference provenance | AI-INF.1 |
Model identifier, inference latency, token count, model version for each decision |
| Tool invocations (automated response) | AI-TOOL.1 |
Tool name, invocation parameters, outcome (success, failure, timeout) |
Each row in this table produces one or more SWT3 Witness Anchors -- tamper-evident records that an auditor can verify independently without access to the vendor platform.
SWT3 wraps the AI inference client used by the threat detection platform. Each detection decision produces a Witness Anchor. The anchor proves four things:
The witness layer sits between your application code and the AI inference endpoint. It does not modify the inference request or response. It observes and records.
Threat Feed / SIEM Alert
|
v
AI Detection Model (vendor-hosted or self-hosted)
|
v
SWT3 Witness Layer ----> Witness Anchor (SHA-256 fingerprint)
| |
v v
SOC Response Action Compliance Ledger / SIEM
The witness layer adds sub-millisecond overhead per inference. It operates as an observer, not a gatekeeper. Detection latency is not affected.
Threat detection environments handle sensitive data. SWT3 clearing levels control what evidence persists:
The clearing level is set per witness call. A single deployment can use different clearing levels for different threat categories.
Witness Anchors are compliance evidence, not operational telemetry. But they are most useful when they flow alongside operational data in your existing SIEM.
The SWT3 SDKs include an OpenTelemetry exporter that emits witness events as OTel spans. This integrates directly with any OTel-compatible backend:
For organizations that need compliance events delivered to GRC platforms or dedicated audit systems, the Axiom platform supports outbound HMAC-signed webhooks. Each verdict event -- PASS or FAIL -- is delivered with a cryptographic signature that the receiving system can verify.
Each Witness Anchor contains an epoch timestamp and a SHA-256 fingerprint. These can be correlated with SIEM events by timestamp or by including the anchor fingerprint in your detection pipeline's metadata fields. When an incident is investigated, the compliance evidence is already indexed alongside the operational evidence.
Witnesses the output of security classifiers that detect adversarial inputs, malicious payloads, or anomalous traffic patterns. The anchor records the classifier's verdict (threat/benign), the hash of the analyzed input, and the action taken.
Factors: Factor A = classifier model identifier and version. Factor B = SHA-256 hash of analyzed input. Factor C = action taken (block, allow, quarantine, escalate).
Request the full chain of AI-SEC.1 anchors for a specific incident timeframe. Verify that every detection decision during the incident has a corresponding anchor. Gaps indicate periods where the AI operated without independent witnessing.
Witnesses when an AI system detects behavioral anomalies that deviate from established baselines. In threat detection contexts, this covers unusual network patterns, anomalous user behavior scores, and deviation from expected traffic profiles.
Factors: Factor A = baseline identifier and version. Factor B = deviation magnitude and severity classification. Factor C = threshold value at time of detection.
Compare the baseline version referenced in Factor A against the organization's documented baseline update schedule. Stale baselines are a common finding -- the anchor provides the evidence to confirm or deny currency.
Witnesses automated response actions triggered by AI detection systems. When a security AI invokes a tool -- isolating an endpoint, blocking an IP, creating a ticket, or triggering a playbook -- the invocation parameters and outcome are recorded in a tamper-evident anchor.
Factors: Factor A = tool name and invocation parameters. Factor B = outcome (success, failure, timeout, partial). Factor C = authorization context (automated vs. human-approved).
Verify that Factor C distinguishes between fully automated tool invocations and those requiring human approval. This is a key control for demonstrating human-in-the-loop governance over automated response actions.
Witnesses the identity and performance characteristics of the AI model that produced each detection decision. This is the foundational procedure -- it proves which model was running, its version, and its operational parameters at the moment of each decision.
Factors: Factor A = model identifier, version, and provider. Factor B = inference latency and token count. Factor C = clearing level applied to this inference.
Cross-reference Factor A model versions against the organization's model change management records. Any model version appearing in AI-INF.1 anchors that is not in the change log indicates an uncontrolled deployment -- a significant finding.
The following example demonstrates wrapping a threat detection inference call with the SWT3 Python SDK. The witness layer records the detection decision without modifying the inference request or response.
from swt3_ai import witness
# Initialize the witness with your tenant credentials
w = witness(
tenant_id="YOUR_TENANT_ID",
api_key="axm_live_...",
clearing_level=1, # Standard -- inputs hashed, metadata preserved
agent_id="soc-threat-detector-v3"
)
# Wrap your AI client -- no changes to the inference call
client = w.wrap(your_ai_client)
# Detection inference (unchanged from your existing code)
result = client.chat.completions.create(
model="gpt-4o",
messages=[{
"role": "system",
"content": "Analyze this network payload for adversarial indicators."
}, {
"role": "user",
"content": payload_summary # Hashed at clearing level 1+
}]
)
# Witness the detection decision explicitly
anchor = w.witness(
procedure="AI-SEC.1",
factor_a="threat-classifier-v3.2.1",
factor_b=payload_hash,
factor_c="action:quarantine"
)
# anchor.fingerprint -- 12-char SHA-256 for verification
# anchor.swt3 -- full SWT3 Witness Anchor token
# Witness the automated response tool invocation
w.wrap_tool(
tool_name="endpoint_quarantine",
parameters={"host": target_host, "duration": "24h"},
outcome="success"
)
# Flush all anchors to the compliance ledger
w.flush()
The wrap() call intercepts inference requests and generates AI-INF.1 anchors automatically. The explicit witness() call adds the AI-SEC.1 detection evidence. The wrap_tool() call records the automated response action as AI-TOOL.1.
Three anchors are produced from this sequence: one proving which model ran (AI-INF.1), one proving the detection decision (AI-SEC.1), and one proving the response action (AI-TOOL.1). Each is independently verifiable.