When you own the model, you own the evidence burden. Cryptographic governance for self-hosted AI.
Who this is for: AI engineers, CISOs, and security teams deploying self-hosted models (vLLM, Ollama, TGI, llama.cpp). Organizations evaluating sovereign AI for data sovereignty, regulatory compliance, or competitive advantage.
The shift to sovereign AI is accelerating. Organizations moving models in-house gain control over data, latency, and cost. They also inherit the full governance burden that API providers previously absorbed. Every self-hosted inference without a governance record is an evidence gap that grows with each request.
Organizations across every sector are moving AI inference in-house. The drivers are well understood:
These are real advantages. The governance gap is the price of sovereignty.
API providers (OpenAI, Anthropic, Google) handle logging, monitoring, and compliance evidence as part of their service. They operate the inference endpoint. They can attest to how their model was used because they control the runtime. When you self-host, that entire evidence chain disappears. SWT3 replaces it. It provides independent, cryptographic evidence that governance controls were active during every inference, minted outside your serving infrastructure as a third-party attestation record.
| Capability | Cloud API (OpenAI, etc.) | Sovereign (vLLM, Ollama, etc.) | With SWT3 |
|---|---|---|---|
| Inference logging | Provider handles | You build it | Automatic Witness Anchors |
| Audit trail | Provider's format | None by default | Immutable ledger with SHA-256 fingerprints |
| Guardrail evidence | Provider attestation | You implement, no proof | AI-GRD.1 anchors per inference |
| Model version tracking | Provider manages | Manual / ad hoc | AI-MDL.1 cryptographic hash records |
| Regulatory evidence | Provider compliance docs | Your responsibility entirely | Framework-mapped anchors (36 frameworks) |
| Incident forensics | Request provider logs | Hope you logged enough | Lifecycle chains with 2-minute evidence export |
| Third-party verification | Provider reputation | Self-attestation | Independent verification at sovereign.tenova.io/verify |
The following controls address the most critical governance gaps in sovereign AI deployments. Each maps to one or more SWT3 procedures and produces independently verifiable Witness Anchors.
Sovereign context: No API provider is recording your inferences. Your serving framework processes requests and returns responses. Without independent witnessing, there is no verifiable record that any inference occurred, let alone what model, what input, or what output.
SWT3 witnesses: Every inference produces a Witness Anchor recording the model identifier, SHA-256 hashes of input and output, execution latency, and serving endpoint. The anchor exists outside your serving infrastructure as a third-party attestation record.
AI-INF.1 anchors prove that a specific model processed a specific input at a specific time. Prompt and response hashes allow correlation with application logs without exposing actual content. Verify any anchor at sovereign.tenova.io/verify.
Sovereign context: When you self-host, guardrail implementation is entirely your responsibility. Llama Guard, custom filters, content classifiers: whatever you choose, you must prove it was active during every inference. Not just that you deployed guardrails, but that they were active for each request.
SWT3 witnesses: The anchor records guardrail status (active/inactive) and pass/fail for each inference. This creates a continuous record of safety control status, independent of the guardrail implementation.
AI-GRD.1 evidence shows guardrailsActive and guardrailPassed for every witnessed inference. A gap in guardrail coverage is immediately visible in the ledger.
Sovereign context: Self-hosted models increasingly use tools: function calling, MCP servers, database queries, API calls. Each tool invocation is an action taken by the AI system outside its language generation boundary. Without witnessing, there is no record of what tools were called, what arguments were passed, or what results were returned.
SWT3 witnesses: wrap_tool() records every tool invocation with the tool name, arguments hash, result hash, and execution time. This creates an auditable chain of every action the model took beyond text generation.
AI-TOOL.1 anchors show the complete tool call graph for any inference. Critical for agent-based systems where the model takes autonomous actions. Export the lifecycle chain for a full sequence view.
Sovereign context: Self-hosted deployments must implement their own access controls. Who can prompt the model? What data can it access? What actions can it take? Without witnessing, there is no evidence that access policies were enforced at inference time.
SWT3 witnesses: wrap_access() records the authorization context for each inference: who requested it, what permissions were checked, and whether access was granted or denied.
AI-ACC.1 anchors prove that access control was enforced at inference time, not just configured at deployment time. Each anchor shows the authorization decision for that specific request.
Sovereign context: Self-hosted models have configuration: temperature, top-p, system prompts, context window settings, quantization parameters. These settings affect model behavior. Without witnessing, there is no evidence of what configuration was active when the model produced a given output.
SWT3 witnesses: AI-BASE.1 records the model configuration at attestation time. Changes to configuration produce new anchors, creating a timeline of configuration drift that can be compared against approved baselines.
AI-BASE.1 anchors prove the model's operational parameters at any point in time. Compare against approved baselines to detect unauthorized configuration changes between audit cycles.
Sovereign context: Self-hosted models have a supply chain: model weights (downloaded from distribution platforms or vendor portals), serving frameworks (vLLM, Ollama), dependencies (CUDA, PyTorch), container images. Every component in this stack is a potential integrity risk. Recent incidents involving model distribution platforms have demonstrated that supply chains for AI components carry real integrity risk, not theoretical risk.
SWT3 witnesses: AI-SUPPLY.1 records the provenance of model components: weights hash, framework version, dependency manifest hash. This creates a software bill of materials for the AI system that can be verified at any point in time.
AI-SUPPLY.1 anchors prove the origin and integrity of every component in the AI stack. Compare weights hashes against published checksums from the source. Track framework versions across deployments to detect unauthorized changes.
Sovereign context: Self-hosted models can be given more autonomy than API-hosted models because there are no provider-imposed guardrails limiting what actions the model can take. This freedom requires proportionally stronger oversight evidence.
SWT3 witnesses: AI-AUTO.2 records the autonomy boundaries for each inference: what actions are permitted, what requires human approval, and whether the model operated within its defined boundaries. This creates evidence of human oversight for autonomous AI systems.
AI-AUTO.2 anchors prove that human oversight policies were active during autonomous operations. Required by EU AI Act Art. 14 for high-risk AI systems. The anchor records whether the action fell within pre-approved autonomy bounds.
Full SDK documentation: sovereign.tenova.io/docs. Install: pip install swt3-ai or npm install @tenova/swt3-ai.
The difference between a 2-minute evidence export and a 6-week forensic investigation is whether the governance records existed before the incident.
Traditional incident response for AI systems requires manual log collection, vendor data requests, timeline reconstruction from scattered sources, and often a determination that the relevant logs were never captured in the first place. Self-hosted deployments are especially vulnerable: there is no provider to call, no pre-existing audit trail, and no external record of what happened.
SWT3 lifecycle chains are multi-anchor sequences linked by shared cycle IDs. When an incident occurs, the entire governance history is already recorded: every inference, every tool call, every access decision, every configuration change. The forensic timeline is not reconstructed after the fact. It was built continuously as the system operated.
The contrast with traditional forensics is structural. With lifecycle chains, an assessor can export the complete evidence record for any model, any time window, any procedure type in seconds. Without them, the same exercise requires weeks of log correlation, assuming the logs exist at all.
| Framework | Relevant Articles / Controls | SWT3 Procedures |
|---|---|---|
| EU AI Act | Art. 9 (risk management), Art. 14 (human oversight), Art. 50 (transparency), Art. 72 (post-market monitoring) | AI-INF.1, AI-GRD.1, AI-AUTO.2, AI-SUPPLY.1 |
| NIST 800-53 | SI-7 (software integrity), AU-2 (audit events), SA-12 (supply chain), CM-6 (configuration) | AI-BASE.1, AI-INF.1, AI-SUPPLY.1, AI-ACC.1 |
| NIST AI RMF | MAP 1.5 (risk identification), MEASURE 2.6 (bias), GOVERN 1.1 (accountability) | AI-GRD.1, AI-INF.1, AI-AUTO.2 |
| CMMC | SC.L2-3.13.11 (CUI protection), AU.L2-3.3.1 (system audit), SI.L2-3.14.1 (flaw remediation) | AI-INF.1, AI-ACC.1, AI-SUPPLY.1 |
For the full bidirectional crosswalk across 36 frameworks, see the Framework Crosswalk Explorer.
If your organization is preparing for an AI governance assessment, the Assessor Hot Sheet is a one-page printable leave-behind that covers key evidence locations, procedure IDs, and verification steps. Designed for assessment meetings where you need to show, not tell.
The table below maps common examiner questions to the specific evidence location in the SWT3 ledger.
| Examiner Question | Where to Find Evidence |
|---|---|
| Can you prove every inference was governed? | AI-INF.1 anchors in the SWT3 ledger. One anchor per inference, continuous, not sampled. Export via /api/v1/ai-witness/export. |
| Were guardrails active during each request? | AI-GRD.1 fields: guardrailsActive and guardrailPassed on every inference anchor. Any gap is visible as a missing or inactive record. |
| What model version is running? | AI-BASE.1 configuration anchor for operational parameters. AI-MDL.1 weights hash for cryptographic model identity. Compare hash against source checksum. |
| Who accessed the model? | AI-ACC.1 authorization records. Each anchor captures the requestor identity and access decision at inference time. |
| What tools did the model use? | AI-TOOL.1 tool call graph. Each tool invocation produces a separate anchor linked to the parent inference by the lifecycle chain cycle ID. |
| How do you handle model updates? | AI-ASSESS.1 lifecycle chains. Each model upgrade is recorded as a champion-challenger assessment with the evaluation dataset and promotion decision. |
| Is the evidence independently verifiable? | Every anchor is verifiable at sovereign.tenova.io/verify. SHA-256 fingerprints exist outside your infrastructure. No self-attestation. |