How SWT3 Detects Poisoned Dependencies

Supply Chain Integrity for AI Systems

The Problem

In April 2026, a supply chain attack poisoned the LiteLLM open-source library — a proxy layer used by thousands of companies to route AI inference across providers. For approximately 40 minutes, a compromised dependency intercepted API keys, training methodologies, and raw inference data before the malicious code was identified and reverted.

The damage was not the vulnerability itself. It was the forensic gap afterward. Companies could not prove which API calls were intercepted, which data was exfiltrated, or whether their models were still running the approved code. Traditional vulnerability scanners found the poisoned library after the fact. None could prove what happened during the window.

The Core Failure: Administrative Trust

Every company that used LiteLLM trusted that the library hadn't been poisoned. That trust was mathematical — there was no cryptographic proof of what the library was actually doing at runtime. When trust is administrative, a 40-minute window is enough to exfiltrate four terabytes.

The Forensic Gap

After a supply chain attack, the organization needs to answer three questions:

What data left the wire? — Traditional logging can't prove this if the attacker also controls the logging layer.
Which models were affected? — Without per-inference witnessing, there's no way to isolate the blast radius.
Is the current state clean? — Without a declared SBOM compared against reality, you're trusting the same supply chain that was just compromised.

The SWT3 Solution

SWT3 (Sovereign Witness Traceability) is an open protocol that creates a cryptographic fingerprint for every AI inference at the point of execution. The fingerprint captures what ran, what it produced, and whether the safety guardrails were active — without retaining the raw data.

The Principle: The proof survives the data. The data doesn't outlive its purpose.

At Clearing Level 1+, SWT3 hashes the prompt and response, records the model ID and guardrail state, then purges the raw content. Even if the entire infrastructure is compromised, there is nothing to steal — because the data was never retained.

The Witness Pipeline

DeclareUpload CycloneDX AI-SBOM

→

WitnessSWT3 anchors every inference

→

CompareSBOM vs. live reality

→

DetectConflicts trigger FAIL anchors

SBOM + Witness: Theory vs. Reality

The AI-SBOM (CycloneDX 1.6) declares what should be running: which models, which versions, which guardrails. The SWT3 witness records what is actually running. Comparing the two catches supply chain integrity breaches automatically:

Detection	What It Means	Example
Undeclared Model	A model is running in production that wasn't in the SBOM	Shadow model deployed without governance approval
Missing Model	A model declared in the SBOM has no witness anchors	Model was replaced or removed without updating SBOM
Version Drift	The model version in production doesn't match the SBOM	Unauthorized fine-tuning or weight swap (the LiteLLM attack vector)
Guardrail Drift	The active guardrails don't match what was declared	Safety filter disabled or replaced by compromised dependency
Provider Mismatch	Inference is routing through a different provider than declared	Man-in-the-middle proxy redirecting API calls

The Clearing Advantage

Traditional compliance tools retain the evidence to prove compliance. This creates a honeypot — the evidence itself becomes the target. The LiteLLM attack succeeded because four terabytes of training telemetry existed in a vendor's database.

SWT3's Clearing Engine inverts this model:

Level	What Reaches the Wire	What an Attacker Gets
Level 0 (Analytics)	Full text	Everything (internal use only)
Level 1 (Standard)	Hashes + model ID + factors	Hashes — useless without the source data
Level 2 (Sensitive)	Hashes + model ID only	Model name and cryptographic fragments
Level 3 (Classified)	Factors only, model ID hashed	Nothing identifiable

At Level 1 and above, the proof survives but the data doesn't. You can verify every inference was witnessed, every guardrail was active, and every model matched the SBOM — without retaining a single prompt or response.

Regulatory Alignment

Requirement	Framework	How SWT3 Satisfies It
Automatic logging of AI system use	EU AI Act Art. 12	SWT3 anchors provide tamper-evident logs of every inference
Software supply chain integrity	EO 14028	AI-SBOM + witness comparison proves runtime matches declared state
Continuous monitoring	NIST 800-53 CA-7	SBOM comparison runs on every ingest, drift triggers FAIL anchors
Model risk management	SR 11-7	Version drift detection catches unauthorized model changes

Get Started

Three lines of code. Zero data retained.

# Python
pip install swt3-ai

# TypeScript
npm install @tenova/swt3-ai

AI Witness Quickstart Guide →
Auto-Generate Your AI-SBOM →
Integrity Debt Score Specification →