The reference architecture
A small set of evidence-capture devices retrofits an ordinary AI cluster into one that can prove what it's doing — where it runs, who's using it, what model is loaded, and how much compute it burns — without ever exposing a model, a prompt, or a byte of user data.
Status — a plain-language explainerThere's no such thing as perfect security. This is a reference architecture and a work in progress; it has not been tested for adversarial robustness, and is not yet proven secure against nation-state adversaries. This page is a non-technical explainer that goes hand in hand with our research paper — read the paper on arXiv ↗. Have feedback on the paper or our approach? We'd genuinely welcome it — fill out the form below ↓.
Structured transparency
Anatomy of a verifiable datacenter
Three devices per server plus one independent appliance turn a standard GPU cluster into a verifiable one. Every device is built to Open Compute Project specifications, so the architecture can retrofit any modern datacenter. Pick a question to see which devices answer it. This is a work in progress and an active area of research — not yet proven against nation-state adversaries.
Assurance Node
Independent Verification Provider · formal policy language · out of data path
GPU server tray · 1 of N
SmartNIC
gateway · traffic
DC-SCM / BMC
power · inventory
CPU TEE — host attestation
8× GPU · TEE
🔒 CC▼ FRONT · COLD-AISLE INTAKE
A round-trip-time location proof, measured against several independent witness nodes, fixes each server's physical position to within tens of kilometres — a bound derived from the speed of light that no VPN, relay, or proxy can fake. A Data Sovereignty Auditor checks every workload against its declared jurisdiction, and the Assurance Node issues the result as a Sovereignty Certificate — a W3C Verifiable Credential the relying party verifies itself, cross-walked to controls like GDPR Art. 44–49 and the EU AI Act.
Captured by · Assurance Node + CPU TEE + GPU TEE
"where": {
"jurisdiction": "SE",
"proof": "rtt-multiwitness",
"witnesses": ["sto1", "osl1", "cph1"],
"bound_km": 48,
"certificate": "vc:sovcert:7b9…",
"frameworks": ["GDPR Art.44-49", "EU-AI-Act"],
"verified": true
}
Human identity-proofing and signed agent-delegation chains establish the principal — and with Verifiable Agent Pods, each agent carries its own scoped credentials. The SmartNIC scores traffic for content governance while a formal policy language in the Assurance Node — one that enables mathematical proof of correctness — evaluates every interaction permit / forbid, annotating deny, warn, escalate, redact, shadow, or log.
Captured by · SmartNIC + CPU TEE
"who": {
"principal": "did:web:gov.se",
"agent": "vap:analyst-07",
"delegation": "verified",
"policy": {
"action": "invoke",
"injection_risk": 0.04,
"toxic_content": 0.11,
"pii_count": 0,
"decision": "permit"
}
}
Each serving Confidential VM (Intel TDX or AMD SEV-SNP) hashes the model at load time inside the GPU's trusted execution environment. A formal policy verifies the lab-signed (model hash, evaluation result) attestation and cross-checks it against the deploy-time hash — binding the running model to its evaluation without ever exposing the weights. Evaluation runs standard, widely-used safety benchmarks.
Captured by · GPU TEE
"what": {
"model": "Llama-3.1-8B-Instruct",
"deploy_hash": "0x9f3c…a1",
"eval_hash": "0x9f3c…a1",
"match": true,
"safety_evals": {
"WMDP": "pass",
"HarmBench": 0.98,
"StrongREJECT": 0.96,
"TruthfulQA": 0.71
},
"signed_by": "AISI"
}
A DC-SCM / BMC module meters power at the shunt while the GPU TEE reports utilisation counters; together they reconstruct FLOP/s across the cluster, sample it continuously, and enforce the scheduler against shadow hardware the operator never declared. Every reading is hardware-rooted and tamper-evident, and the receipts are chained — so a counter cannot be silently reset nor a window backdated without detection.
Captured by · DC-SCM / BMC + GPU TEE
"how": {
"device_class": "NVIDIA H200 · CC-mode",
"window": "2026-06-18T09:00Z / PT1H",
"shunt_power_kw": 41.8,
"utilization_pct": 93.4,
"flops_per_s": "6.1e18",
"energy_kwh": 4120,
"shadow_hardware": "none-detected",
"attested": true
}
No one has to trust anyone
A sovereign datacenter, cloud, or AI company runs the GPUs and wants to prove compliance — without exposing proprietary models or user data.
An independent body (Lucid) runs the Assurance Node. It trusts no one — every claim is checked against hardware roots the operator doesn't control.
A regulator, AI Safety Institute, treaty body, or enterprise customer needs proof — but never sees raw data, only small signed receipts it verifies back to silicon.
At the centre
A tamper-resistant appliance, operated by the verification provider and kept out of the user-traffic data path. It aggregates the hardware-signed claims and turns them into one receipt anyone can check.
Collects signed claims (RFC 9334 Evidence) from software ClaimsAuditors, each in its own Confidential VM.
Evaluates a formal policy language per interaction — permit or forbid, with decision annotations — enabling mathematical proof of correctness.
Issues chained AI Passport receipts — retroactive forgery is detectable; only receipts leave the facility.
At the treaty-grade tier, the relying party can request a fresh SPDM attestation directly from hardware to spot-check.
Programmable · the node runs Claims Auditors you write
from lucid import ClaimsAuditor, policy @ClaimsAuditor("data-residency") def residency(workload): loc = workload.location_proof() return claim( jurisdiction = loc.country, verified = loc.bound_km < 50, ) # formal policy — mathematically provable policy.forbid(action="key.release") .when("residency.jurisdiction != 'SE'")
Each Auditor is a small, scoped program that inspects one aspect of a workload and emits a single signed claim. Write your own for any rule — residency, identity, evaluations, compute — in a formal policy language whose decisions can be proved correct. The node runs each one inside its own Confidential VM and binds the result into the receipt.
Tamper-evident by construction
Verification only means something if the evidence itself can't be quietly forged. The hardware is being designed to make physical interference expensive, visible, and self-defeating. These defenses are in active development and have not yet been proven against a determined nation-state attacker — which is exactly what our red-teaming program is for.
Each verification device is wrapped in an active tamper-proof mesh. Drilling, delayering, or probing for a side channel breaks the mesh and zeroizes the device's keys — so the attempt destroys the very secret it was trying to reach.
Power, timing, and electromagnetic side channels are designed against rather than assumed away. The mesh and shielding are meant to keep secrets inside the cryptographic boundary, not just behind a login.
Cameras monitor the racks and the room continuously, and the video feeds directly into the Assurance Node — bound into the same chained receipts, so the physical and cryptographic evidence corroborate each other.
Safety without surveillance
We want a world where AI is verifiably safe without violating people's rights and freedoms. Verification has to deliver safety and avoid government overreach — or it isn't worth building. That constraint is designed into the architecture, not bolted on after.
Evidence capture is separated from evaluation. A facility emits a small signed receipt — never model weights, training data, prompts, or user content. The boundary is cryptographic, not a promise.
The relying party gets a verifiable answer to one agreed question — not a window into the datacenter. There is no live feed, no raw logs, no standing access to inspect what people are doing.
Policies are pre-agreed and cryptographically bound. A verifier — even a government — can check only what was agreed, and nothing more. The mechanism makes scope-creep visible and refusable by construction.
Structured transparency decides who can know what, when they can know it, and what they can do with it — so trust never costs a freedom.
Get in touch
Tell us about your cluster and the claims you need to prove — we'll map the reference architecture to your facility.
See the four standards →