Red-teaming
The retrofit kit is hypothetical for now: a small set of evidence-capture devices meant to let an ordinary AI cluster prove where it runs, who is using it, what model is loaded, and how much compute it burns, without exposing a model, a prompt, or a byte of user data. The red-team cluster is where we put that kit to the test.
Status: an early-stage hypothesis. We're working toward a reference architecture and red-teaming the candidate design with external partners. It is not yet proven against nation-state adversaries. This page will change as we learn and experiment more. We always welcome your input and feedback.
An architecture is only as good as the attacks it withstands. Ours is under fire in an 18-month validation program with a nation state actor: deployed on real GPU infrastructure and red-teamed independently by the actor's cybersecurity group, which delivers formal vulnerability and penetration-test reports. That is what a design would have to survive before we'd call it verified.
Builder
We design and deploy the verification architecture on real GPU infrastructure: the devices, the Assurance Node, the evidence pipeline.
Breaker
A nation state actor's cybersecurity group attacks it independently and reports what breaks, retaining full technical authority over its own methodology.
The rule
The people trying to break the architecture are never the people who built it. Without that separation, no government would trust verifiable compute.
Structured transparency
Threat model
In plain terms: this architecture is built to catch an operator or user who tries to break the rules quietly, hoping no one notices. Four continuously verified questions each close off one way of cheating.
Where are the chips located? If hardware is diverted, relocated, or hidden behind a proxy, the continuous location proof and the silicon’s physical fingerprint are designed to betray the move.
Who is using the model? Every interaction carries a verified identity and agent mandate; prompt attacks and out-of-scope agents are intended to be flagged in the traffic path.
What model is running? The running model is hash-bound to its evaluation at load time and spot-checked by recompute; a swapped or never-evaluated model should break the match.
How are the chips being used? Power draw, utilization counters, and traffic shape are cross-checked against the declared job; an undeclared training run is intended to show up in the meters.
Well-resourced state actors. None of these defenses has been battle-tested or red-teamed against a nation-state adversary. That hardening is what our red-team program with external partners is for. Until then, every design goal on this page remains an active area of research.
Open defectors. Someone who no longer cares about being caught cannot be stopped by receipts. Against open defection, verification’s job changes: it produces fast, unambiguous, attributable evidence that the rules were broken; the response belongs to governments and treaties, not to the hardware.
Anatomy of a verifiable datacenter
Three devices per server plus two independent appliances (the Assurance Node and a passive optical tap) are designed to turn a standard GPU cluster into a verifiable one. No single mechanism is trusted alone: TEEs, signed power telemetry, unpredictable recompute, and the optical tap corroborate one another, with tamper-responsive enclosures and cameras guarding the physical layer, and a provable memory wipe between jobs bounds what could have been hidden.
Assurance Node
The independent referee: evidence in, signed receipts out
GPU server tray · 1 of N
SmartNIC
gateway · traffic · job manifest
DC-SCM / BMC
power · inventory
CPU TEE : host attestation
8× GPU · TEE
🔒 CC▼ FRONT · COLD-AISLE INTAKE
A round-trip-time proof anchors each server to the Assurance Node, a landmark inside the same facility whose own position is independently attested. Added delay can only make a device look farther away, never closer, so the proof bounds the server to the facility itself. The GPU's TEE key binds that session to one specific chip, and the silicon's physical fingerprint (how it throttles under load) adds a continuously measured signal against key transplant, still a research primitive. A Data Sovereignty Auditor checks each workload against its declared jurisdiction, and the result is issued as a Sovereignty Certificate, a W3C Verifiable Credential the relying party verifies itself.
Captured by · Assurance Node + CPU TEE + GPU TEE
"where": {
"jurisdiction": "SE",
"proof": "rtt-an-landmark",
"witness": "an:sto-fac1",
"corroborators": ["sto1", "osl1", "cph1"],
"bound_m": 500,
"certificate": "vc:sovcert:7b9…",
"verified": true
}
Human identity-proofing and signed delegation chains establish who is acting, and each agent carries scoped credentials issued inside its TEE-backed harness. A formal policy language in the Assurance Node decides every interaction (permit or forbid, with annotations such as escalate or redact), and the AgentGateway enforces the verdict in the traffic path; the evaluation engine is formally verified upstream, our integration still in development. Identity comes in tiers, from self-asserted to hardware-bound, and escalations route to a human approver whose signed decision lands in the same receipt chain.
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 hashes the model at load time inside the GPU's trusted execution environment, and a formal policy cross-checks that hash against the lab-signed evaluation record, binding the running model to its evaluation without exposing the weights. The binding is spot-checked after deployment: every request commits an output digest, and an unpredictable sample is recomputed on reference hardware, a second root independent of the TEE. Bit-exact recompute is demonstrated under bounded assumptions and is being hardened for production.
Captured by · GPU TEE
"what": {
"model": "Llama-3.1-8B-Instruct",
"deploy_hash": "0x9f3c…a1",
"eval_hash": "0x9f3c…a1",
"match": true,
"safety_evals": {
"wmdp_acc": 0.31,
"harmbench_asr": 0.02,
"strongreject_score": 0.04,
"truthfulqa_acc": 0.71
},
"signed_by": "eval-lab (illustrative)"
}
Every job declares itself first in a signed Verifiable Job Manifest; measurement then checks the declaration. A DC-SCM / BMC module meters power at the shunt while the GPU TEE reports utilisation counters: two independent signals for the same work, cross-checked continuously, where disagreement flags an anomaly. Traffic shape helps distinguish training from inference, and a passive optical tap hashes every flow (headers only) into an append-only commitment, so the accounting rests on everything that crossed the wire, not only what was declared. Hardware never enrolled stays out of scope, a boundary the architecture states rather than hides. Every reading is hardware-rooted and every receipt chained, so a counter cannot be silently reset nor a window backdated without detection.
Captured by · SmartNIC + DC-SCM / BMC + GPU TEE
"how": {
"manifest": "vjm:sha256:9c41…",
"declared_class": "inference",
"measured_class": "inference",
"device_class": "NVIDIA HGX H100 · CC-mode",
"window": "2026-06-18T09:00Z / PT1H",
"shunt_power_kw": 10.4,
"utilization_pct": 93.4,
"flops_per_s": "1.5e16",
"energy_kwh": 10.4,
"shadow_hardware": "none-detected",
"attested": true
}
No party has to be trusted blindly
A sovereign datacenter, cloud, or AI company runs the GPUs and wants to prove compliance, without exposing proprietary models or user data. The verification software is open source and reproducibly built, so the operator can recompile it and byte-compare the running binary.
An independent body (Lucid) runs the Assurance Node. It trusts no one; every claim is checked against hardware roots the operator doesn't control. They also provide physical inspections: on-site audits confirming the hardware is where, and what, the cryptographic claims say it is.
A regulator, independent verification organization, treaty body, or enterprise customer, user or other stakeholder who needs verifiable proof of compliance without seeing raw data, only small signed receipts it verifies back to silicon.
Claims flow up, trust flows down to silicon, and each party can check the Verification Provider, not merely trust it.
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) under evaluation semantics formally verified upstream. The proof covers the evaluator, not the policies written in it.
Issues chained AI Passport receipts: retroactive forgery is detectable; only receipts leave the facility.
Emits a chained heartbeat: signed, sequentially numbered receipts every few seconds, so a gap in the evidence is itself evidence, cryptographically detectable.
Bounds staleness: receipts carry freshness windows and are checked against revocation state before a relying party acts, so a compromised key or device is cut off at the next check rather than trusted forever.
Spot-checks by recompute: an unpredictable sample of committed requests is re-run on reference hardware, and the output digests must match. The check is intended to stand even if a TEE falls.
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_m < 500, ) # 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 signed claims: facts, never verdicts. Write your own for any rule (residency, identity, evaluations, compute) in ordinary code; decisions belong to a separate formal policy language whose evaluation is verified, so a claim can be rich while the verdict stays provable. Auditors never run on the devices themselves: each device attests and emits signed evidence, and the node appraises it centrally, every Auditor in its own Confidential VM, its code hash bound into the receipt.
Tamper-evident by construction
Verification only means something if the evidence can't be quietly forged, and the way to forge it is physical: tap the memory bus, probe for side channels, interpose on a device to lift its keys. The design answers with tamper-responsive mesh that zeroizes on contact, continuous camera coverage of the racks, side-channel-hardened enclosures, and, for the moments physical security fails anyway, the independent recompute root, which trusts no TEE at all. These defenses are in active development and not yet proven against a nation-state attacker; that is what the red-team program is for.
Each verification device is designed to be wrapped in an active tamper-responsive mesh. Drilling, delayering, probing, or tapping the memory bus 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.
In the target design, cameras monitor the racks and the room continuously and the video feeds into the Assurance Node, bound into the same chained receipts, so the physical and cryptographic evidence corroborate each other. This binding is part of the enclosure program, not yet implemented.
NVIDIA, Secure AI with Blackwell and Hopper GPUs (whitepaper, 2025)
Niu et al., NVIDIA GPU Confidential Computing Demystified (2025) · arXiv:2507.02770
Zhang et al., SoK: Analysis of Accelerator TEE Designs (NDSS 2026)
Zhang et al., ccAI: Compatible and Confidential AI Computing (MICRO 2025)
Misono et al., Confidential VMs Explained: SEV-SNP vs. TDX (SIGMETRICS 2025)
Wang & Oswald, Confidential Computing on Heterogeneous CPU–GPU Systems: A Survey (ACM Computing Surveys 2026) · arXiv:2408.11601
Confidential Computing for Agentic AI (2026) · arXiv:2605.03213
Lu, Zhang et al., MOLE: Breaking GPU TEE with the GPU-Embedded MCU (CCS 2025); FAARM defense · arXiv:2510.22566
De Meulemeester et al., BadRAM (IEEE S&P 2025)
TEE.Fail and Battering RAM, DDR interposer attacks on attestation keys (2025)
Breaking Partial-TEE-Shielded LLM Inference with Precomputed Noise (2026) · arXiv:2602.11088
Energon: Unveiling Transformers from GPU Power and Thermal Side-Channels (2025) · arXiv:2508.01768
Baddour, Banerjee & Sanadhya, SideLink: NVLink Covert and Side Channels (J. Hardware & Systems Security 2026)
Wei et al., ShadowScope: Composable GPU Side-Channel Monitoring (2025) · arXiv:2509.00300
IETF, Remote ATtestation procedureS (RATS) Architecture · RFC 9334
DMTF, Security Protocol and Data Model (SPDM) 1.3
Open Compute Project, DC-SCM 2.2 Specification
CHIPS Alliance / OCP, Caliptra 2.x; lowRISC, OpenTitan
PCI-SIG, TDISP and CXL IDE trusted-I/O
W3C, Verifiable Credentials Data Model 2.0
SLSA; Sigstore / Rekor; Reproducible Builds
He, Defeating Nondeterminism in LLM Inference (Thinking Machines Lab, 2025)
Cankaya, Bit-Exact AI Inference Verification Without Performance Tradeoffs (2026) · arXiv:2606.00279
Karvonen et al., DiFR: Inference Verification Despite Nondeterminism (2025) · arXiv:2511.20621
Ong, Ferrante et al., TOPLOC: Locality-Sensitive Hashing for Trustless Verifiable Inference (2025) · arXiv:2501.16007
Rinberg et al., Verifying LLM Inference to Detect Model Weight Exfiltration (2025) · arXiv:2511.02620
TAO: Tolerance-Aware Optimistic Verification of Floating-Point Neural Networks (EuroSys 2026) · arXiv:2510.16028
Khattak & Mikaitis, Accurate Models of NVIDIA Tensor Cores (2025) · arXiv:2512.07004
Survey of Zero-Knowledge-Proof-Based Verifiable Machine Learning (2025) · arXiv:2502.18535
Sun et al., zkLLM (CCS 2024) · arXiv:2404.16109
Artemis: Commit-and-Prove SNARKs for zkML (2024) · arXiv:2409.12055
Jia et al., Proof-of-Learning: Definitions and Practice (IEEE S&P 2021) · arXiv:2103.05633
Peigné, Nguyen & Wang, Zero-Knowledge Verification of Frontier AI Training Is Possible (2026) · arXiv:2606.05433
Shavit, What Does It Take to Catch a Chinchilla? (2023) · arXiv:2303.11341
Cankaya, Catching Misreporting About ML Hardware Use (2025)
Cankaya et al., Fingerprinting All AI Cluster I/O Without Mutually Trusted Processors (2026) · arXiv:2606.10724
Timing and Memory Telemetry on GPUs for AI Governance (2026) · arXiv:2602.09369
Hausenloy & Li, Inspector Agents / the Verifier Challenge (2026)
IAPS, Location Verification for AI Chips (2024–25)
Petrie, Aarne, Ammann & Dalrymple, FlexHEG: Flexible Hardware-Enabled Guarantees (ARIA 2025) · arXiv:2506.03409
Aarne, Fist & Withers, Secure, Governable Chips (CNAS 2024)
Baker, Kulp, Marks, Brundage & Heim, Six Layers of Verification (RAND 2025) · arXiv:2507.15916
Petrie, Near-Term Enforcement of AI Chip Export Controls via Firmware-Based Offline Licensing (2024) · arXiv:2404.18308
Al Ramiah et al., Toward a Global Regime for Compute Governance: Building the Pause Button (2025) · arXiv:2506.20530
Heim, Fist, Egan et al., Governing Through the Cloud (2024) · arXiv:2403.08501
Moon et al., Strategies and Detection Gaps in a Game-Theoretic Model of Compute Governance (RAND 2025)
Ammann & Dalrymple, Faster AI Diffusion Through Hardware-Based Verification (IFP 2025)
Sastry, Heim, Belfield et al., Computing Power and the Governance of AI (GovAI 2024)
Bengio et al., International AI Safety Report 2026
Council of Europe, Framework Convention on Artificial Intelligence (CETS No. 225)
Scholefield, Martin & Barten, Review and Recommendations for a Conditional AI Safety Treaty (2025) · arXiv:2503.18956
Hendrycks, Schmidt & Wang, Superintelligence Strategy (2025) · arXiv:2503.05628
Reuel et al., Open Problems in Technical AI Governance (TMLR 2025) · arXiv:2407.14981
Barnett, Scher & Abecassis, Technical Requirements for Halting Dangerous AI Activities (2025) · arXiv:2507.09801
Scher, Abecassis et al., An International Agreement to Prevent the Premature Creation of Artificial Superintelligence (2025) · arXiv:2511.10783
Seth & Sankarapu, Behavioural Assurance Cannot Verify the Safety Claims Governance Demands (2026) · arXiv:2605.15164
Schnabl, Hugenroth, Marino & Beresford, Attestable Audits (2025) · arXiv:2506.23706
Becker et al., Stealthy Dopant-Level Hardware Trojans (CHES 2013)
Ilhan, Withers, Gietz & Harack, Verifiable Semiconductor Manufacturing (Oxford Martin AIGI 2026)
Tamper-Evident Covers from Flexible PCB (TCHES 2024)
Thummala et al., Out-of-Band Power Side-Channel Screening for Supply-Chain Integrity (2026) · arXiv:2601.01054
Tahghigh & Salmani, Reference-Free EM Detection of Always-On Hardware Trojans (2026) · arXiv:2603.16058
Fisk et al., Eliminating Steganography in Internet Traffic with Active Wardens (2003)
Xing, Kang & Chen, NetWarden (USENIX Security 2020)
Zhang et al., in-switch encrypted-traffic anomaly detection (SIGCOMM 2025)
Amodo Design, Network Tapping for AI Verification: A Technical Assessment (2026)
Proof of Secure Erasure (2024) · arXiv:2401.06626
Deochake, Heartbeat-Bound Hierarchical Credentials (2026) · arXiv:2605.20704
League of Entropy, drand; IETF, VRFs · RFC 9381; Google, Roughtime; Trillian / Certificate Transparency
Li et al., The WMDP Benchmark (2024) · arXiv:2403.03218
Mazeika et al., HarmBench (2024) · arXiv:2402.04249
Souly et al., StrongREJECT (2024) · arXiv:2402.10260
Lin, Hilton & Evans, TruthfulQA (ACL 2022) · arXiv:2109.07958
Compiled from the public literature, April–June 2026. Inclusion reflects our reading; it does not imply endorsement by the authors cited.
Get in touch
Tell us about your cluster and the claims you need to prove. We'll explore how the emerging reference architecture could map to your facility.
See the four standards →