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. Architecture candidates are developed on the experimentation cluster, then brought here to be attacked. 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 adversary acquires AI chips,
uses them to train a model,
deploys its dangerous capabilities,
and uses it to do harm.
Threat: compute is diverted — smuggled past export controls or operated outside its licensed jurisdiction.
Verification: where is the compute, and whose is it? Hardware-rooted location and identity proofs back export-control and data-residency claims; relocation, resale, or fronting through a proxy is designed to surface as evidence.
Threat: controlled compute powers an undeclared training run — past reporting thresholds, or outside a compute agreement.
Verification: how is the compute being used? Power, utilization, and traffic signatures separate training from inference and reconcile consumed compute against the declared workload, supporting threshold-based reporting.
Threat: a model reaches deployment without the capability evaluations or authorizations its jurisdiction or agreement requires.
Verification: what model is serving? The deployed model is cryptographically bound to its evaluation record, so deployment can be gated on passed evaluations — and swapped or unevaluated weights rejected.
Threat: a deployed model is misused to cause harm — by its operator or its users.
Verification: who is acting, and under what mandate? Verified identities, scoped agent mandates, and in-path monitoring flag prohibited use — jailbreaks, distillation, dangerous requests — and yield attributable evidence for enforcement.
Wants proof · trusts no one
A regulator, treaty body, counterparty, or customer who needs to know the four questions above — where, how, what, who — hold for this datacenter. It never sees models, prompts, or user data: only small signed receipts it can verify using the hardware itself.
Builder · installs verification
An independent body installs the retrofit kit and the Assurance Node, turns hardware evidence into signed receipts, and backs the record with on-site physical inspections. Its software is open source, so anyone can confirm the software actually running is exactly the published code.
Breaker · red-teams verification
Played by a government research institute’s red teams: they run the GPUs, covertly attempt every attack in section 01 — diverting compute, undeclared training, swapped models, hidden users — and attack the monitoring devices themselves.
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. Each workload is checked against the jurisdiction it declares, and the result is issued as a signed certificate — a W3C Verifiable Credential — that the relying party can check for 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
}
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 signed 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.
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'")
What gets checked is not fixed by us. The relying party and the operator agree on the claims that matter — residency, identity, evaluations, compute — and the node runs exactly that agreement. As the agreement evolves, the auditors and policies are re-programmed, and every change is hash-bound into the receipts.
Claims are facts, never verdicts. Each Auditor is a small, scoped program that inspects one aspect of a workload and emits signed claims.
Your rules, in ordinary code. Write an Auditor for any rule; decisions belong to a separate formal policy language whose evaluation is verified, so a claim can be rich while the verdict stays provable.
Run centrally, under attestation. Auditors never run on the devices themselves: each device emits signed evidence and the node appraises it, every Auditor in its own Confidential VM, its code hash bound into the receipt.
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.
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.
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 involved
We're red-teaming the retrofit kit with external partners — and looking for more breakers, operators with clusters to prove, and relying parties who need the proof. Tell us where you'd fit.
See the four standards →Tell us where you'd fit — breaker, operator, or relying party.
Email info@lucidcomputing.ai