Self-Hosted AI Witnessing: Air-Gap and On-Premise Quick Start

0. Prerequisites

Install the SDK (Connected Machine)

If you have internet access on a build machine or staging server, install directly:

# Python
pip install swt3-ai

# TypeScript / Node.js
npm install @tenova/swt3-ai

# Rust
cargo add swt3-ai

# C# / .NET
dotnet add package swt3-ai

Install the SDK (Air-Gapped Machine)

On a connected machine, download the package for offline transfer:

# Python: download wheel + dependencies to a directory
pip download swt3-ai -d ./swt3-offline/

# Transfer the directory via approved media, then install
pip install --no-index --find-links ./swt3-offline/ swt3-ai

# TypeScript: pack the tarball on a connected machine
npm pack @tenova/swt3-ai

# Transfer the .tgz, then install from the local file
npm install ./tenova-swt3-ai-0.6.2.tgz

The SDK has zero native dependencies. It is pure Python / pure TypeScript. No compilation, no system libraries, no post-install scripts. The wheel or tarball is self-contained.

CLI Tools

The swt3 command-line tool is included with both SDKs. After installing the Python package, swt3 is available on your PATH. After installing the TypeScript package, use npx swt3. Both provide identical commands: verify, status, reconstruct, and gate.

1. Why Self-Host

Several categories of regulatory and operational requirements make self-hosted witnessing the only viable deployment pattern:

• Data localization mandates: China PIPL requires personal data processing within mainland China. EU GDPR Articles 44-49 restrict cross-border transfers. India DPDP Act mandates local processing for certain categories. These regulations prohibit sending inference telemetry to external endpoints.
• Export control regimes: ITAR and EAR restrict data about defense articles and dual-use technologies. CMMC Level 2+ requires CUI to remain within authorized boundaries. AI inference metadata from defense workloads may itself be controlled.
• Classified computing: SCIF operations, intelligence workloads, and air-gapped laboratories have zero-egress policies by design. No exceptions for compliance telemetry.
• Enterprise security posture: Zero-trust perimeters, segmented networks, and data-loss-prevention controls may block outbound API calls from inference pipelines.

The SWT3 protocol adapts to your security posture. You do not need to adapt your security posture for the protocol.

2. Deployment Patterns Overview

All three patterns produce identical witness anchors. The anchors are cryptographically interchangeable regardless of deployment pattern. An anchor minted in a SCIF verifies the same way as an anchor minted in a cloud environment.

3. Local Ledger Mode (Zero Egress)

Local Ledger mode writes every anchor to the local filesystem instead of transmitting to a remote endpoint. When factor_handoff is set to "file", the SDK writes anchor data to disk first, then attempts the network flush as a secondary step. In a disconnected environment the flush fails silently and the local files are your authoritative record.

Python

from swt3_ai import Witness
from openai import OpenAI

witness = Witness(
    endpoint="https://localhost",   # placeholder; flush will fail silently
    api_key="axm_local_placeholder",
    tenant_id="DISCONNECTED_ENCLAVE",
    clearing_level=3,               # classified: factors only
    factor_handoff="file",          # write to local filesystem
    factor_handoff_path="/secure/swt3-anchors/",
)

client = witness.wrap(OpenAI(base_url="http://gpu-node.local:8000/v1"))

# Use the client exactly as before. Every inference is witnessed locally.
result = client.chat.completions.create(
    model="llama-3.1-70b",
    messages=[{"role": "user", "content": "Analyze the threat indicators."}]
)

TypeScript

import { Witness } from "@tenova/swt3-ai";
import OpenAI from "openai";

const witness = new Witness({
  endpoint: "https://localhost",
  apiKey: "axm_local_placeholder",
  tenantId: "DISCONNECTED_ENCLAVE",
  clearingLevel: 3,
  factorHandoff: "file",
  factorHandoffPath: "/secure/swt3-anchors/",
});

const client = witness.wrap(
  new OpenAI({ baseURL: "http://gpu-node.local:8000/v1" })
) as OpenAI;

What Happens

The SDK creates the factor_handoff_path directory if it does not exist (with 0700 permissions). Each inference produces a JSON file named by its fingerprint:

/secure/swt3-anchors/
  c059eb5938c0.json
  0d446d2f9c39.json
  9b2923db0f62.json

Each file contains the complete factor data needed for independent verification:

{
  "anchor": "SWT3-E-LOCAL-INF-AIINF1-PASS-1774800000-c059eb5938c0",
  "fingerprint": "c059eb5938c0",
  "tenant_id": "DISCONNECTED_ENCLAVE",
  "procedure_id": "AI-INF.1",
  "factor_a": "llama-3.1-70b",
  "factor_b": "a3f8...",
  "factor_c": 0,
  "timestamp_ms": 1774800000000,
  "clearing_level": 3,
  "verdict": "PASS"
}

Files are written with 0600 permissions (owner read/write only). Anyone with this file and a SHA-256 implementation can independently recompute the fingerprint and verify the anchor.

Network flush behavior: After writing the local file, the SDK attempts to flush to the endpoint. In a disconnected environment this fails silently and the payload moves to an internal dead-letter queue. No retries, no error logs, no backoff overhead. The local file is your authoritative record. If you later connect the machine or transfer the files, you can batch upload them (see Section 5).

4. Private Endpoint (On-Prem Ledger)

For enterprise environments with internal network connectivity but no internet access. The SDK points to your own witness receiver instead of the public endpoint.

from swt3_ai import Witness
from openai import OpenAI

witness = Witness(
    endpoint="https://witness.internal.acme.com",  # your private endpoint
    api_key="axm_live_your_key_here",
    tenant_id="ACME_ONPREM",
    clearing_level=1,
)

client = witness.wrap(OpenAI(base_url="http://gpu-cluster.internal:8000/v1"))

The endpoint receives the same POST /api/v1/witness and POST /api/v1/witness/batch payloads as the public API. To deploy a private receiver:

• Option A: Axiom platform (self-hosted). Deploy the Axiom dashboard container on your internal infrastructure. This gives you the full ledger, audit portal, forensic reconstruction, and anchor verification on your network. Contact support@tenovaai.com for Sovereign tier self-hosted deployment.
• Option B: Custom receiver. Implement a minimal HTTP endpoint that accepts the witness payload JSON and writes it to your database of choice. The payload schema is documented in the SDK documentation. Verification is performed client-side using the fingerprint formula.

Both options can be combined with factor_handoff="file" for defense-in-depth: anchors are written locally AND flushed to the private endpoint.

5. Delayed Sync (Sneakernet)

For environments where anchors must eventually reach an audit system but cannot do so in real time.

Export

# On the disconnected machine
tar czf swt3-anchors-$(date +%Y%m%d).tar.gz /secure/swt3-anchors/

# Transfer via approved media (USB, optical disc, cross-domain solution)

Verify on the Audit Terminal

# Extract
tar xzf swt3-anchors-20260727.tar.gz

# Verify each anchor independently (no network required)
swt3 verify --dir /secure/swt3-anchors/

Optional: Batch Upload

If the audit terminal has network access to a witness ledger:

import json, os
from pathlib import Path
from urllib.request import Request, urlopen

# Collect all anchor files
anchor_dir = Path("/secure/swt3-anchors/")
payloads = [json.loads(f.read_text()) for f in anchor_dir.glob("*.json")]

# Submit to the witness batch endpoint
req = Request(
    "https://sovereign.tenova.io/api/v1/witness/batch",
    data=json.dumps({"payloads": payloads}).encode(),
    headers={
        "Authorization": "Bearer axm_live_...",
        "Content-Type": "application/json",
    },
    method="POST",
)
resp = urlopen(req)
print(f"Uploaded {len(payloads)} anchors: {resp.status}")

Replace the endpoint with your private endpoint URL if using an on-prem ledger (see Section 4).

6. Offline Verification

All verification is pure SHA-256 math. No network required. No vendor dependency. Any machine with a hash implementation can verify an anchor.

From a Handoff File

The simplest path: point swt3 verify at a handoff JSON file. The CLI extracts the factors automatically.

# Verify a single anchor file (factors extracted from the JSON)
swt3 verify --file /secure/swt3-anchors/c059eb5938c0.json

# Verify all anchor files in a directory
swt3 verify --dir /secure/swt3-anchors/

From Raw Values

If you have the anchor token and factors separately (e.g., from a log or a colleague), supply them directly. The factor values must match what was recorded at inference time.

# Verify with explicit factors
swt3 verify "SWT3-E-LOCAL-INF-AIINF1-PASS-1774800000-c059eb5938c0" \
  --tenant DISCONNECTED_ENCLAVE \
  --procedure AI-INF.1 \
  --factors 1,1,0 \
  --timestamp 1774800000000

Programmatic Verification

from swt3_ai import verify_fingerprint

result = verify_fingerprint(
    anchor="SWT3-E-LOCAL-INF-AIINF1-PASS-1774800000-c059eb5938c0",
    tenant_id="DISCONNECTED_ENCLAVE",
    procedure_id="AI-INF.1",
    factor_a=1,
    factor_b=1,
    factor_c=0,
    timestamp_ms=1774800000000,
)

print(result)  # "CERTIFIED TRUTH" or "TAMPERED"

The verification formula is public and identical across all 8 SDK languages: SHA256("WITNESS:{tenant}:{procedure}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12]

7. Pulse Bundles (STIG and KEV Updates)

Disconnected environments still need updated STIG benchmarks and CISA KEV feeds. Pulse bundles are signed, portable update packages designed for sneakernet transfer.

# On a connected machine: generate a signed pulse bundle
axiom pulse --generate --output /media/usb/axiom-pulse-$(date +%Y%m%d).pulse

# On the disconnected machine: verify integrity before loading
axiom pulse --verify /media/usb/axiom-pulse-20260727.pulse

# Load the verified bundle
axiom pulse --load /media/usb/axiom-pulse-20260727.pulse

Pulse bundles contain SHA-256 manifests for integrity verification. The --verify step checks all file hashes before loading. If any file has been modified in transit, the bundle is rejected.

8. Clearing Levels for Classified Environments

Clearing levels control what evidence persists in each anchor. Higher levels reduce data exposure while preserving cryptographic provability.

Level 3 is recommended for air-gapped deployments. At Level 3, no metadata, provider names, or guardrail names are present in the anchor. Only numeric factors and a hashed model identifier.

USB transfer safety: Anchor files at Level 3 contain only hashes and numeric factors. No prompt content, no response content, no model names appear in any file. Transfer via approved removable media is acceptable because the files contain no classifiable content.

Factor handoff files contain the full uncleared data. These files must be protected with filesystem permissions and encryption at rest appropriate to your classification level.

9. Forensic Reconstruction (Offline)

The swt3 reconstruct command rebuilds chronological timelines from local WAL files with no network access required.

# Reconstruct from local WAL (no API call)
swt3 reconstruct --last 24h

# Reconstruct a specific cycle
swt3 reconstruct --cycle CYCLE_ABC123

# Reconstruct and export as self-contained HTML
swt3 reconstruct --last 7d --html > timeline-report.html

The HTML export is a self-contained file with the TeNova dark theme, KPI summary, delegation trees, drift and override markers, clearing level badges, and verification links. It includes an attestation banner noting that the export was generated from local data.

For environments with API access, the same command queries the remote ledger instead:

# Reconstruct from remote API
swt3 reconstruct --agent soc-detector-v3 --last 48h

10. SDK Support Matrix

All 8 SDK languages support local-mode operation. The witness protocol is identical across languages, and anchors are cross-language compatible.

Cross-language parity: 54 test vectors ensure identical fingerprint computation across all SDK languages. An anchor minted in Rust verifies in Python. An anchor minted in Swift verifies in C#. The protocol is language-agnostic by design.

11. Troubleshooting

12. References

• Edge and Embedded Attestation - Witnessing on resource-constrained devices
• Signing and Security Guide - HMAC-SHA256 payload signing reference
• Cross-Silicon Kubernetes Attestation - Hardware-aware witnessing in K8s clusters
• Clearing and Data Sovereignty Addendum - Legal terms and shared responsibility
• SDK Documentation - Python, TypeScript, and all SDK reference
• UCT Registry - Complete procedure catalog (108 procedures, 56 namespaces)
• Anchor Verifier - Verify any SWT3 Witness Anchor fingerprint