Red-teaming

Vision: a retrofit kit to make any datacenter verifiable.

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.

Proof of Principle Stage 2 of 4
Theory Proof of Principle Demonstration Red-teamed

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.

Explore the research ↓ Four questions
The red-team cluster

Tested the only way that counts: by the people trying to break it.

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

Lucid builds it.

We design and deploy the verification architecture on real GPU infrastructure: the devices, the Assurance Node, the evidence pipeline.

Breaker

A nation state actor breaks it.

A nation state actor's cybersecurity group attacks it independently and reports what breaks, retaining full technical authority over its own methodology.

The rule

Never the same team.

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

Claims flow up. Trust flows down to silicon. Only signed receipts ever leave the facility, never weights, prompts, or user data.

Threat model

What we aim to defend against, and what we don’t.

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

Compute smuggled to a non-trusted party

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

Misuse or jailbreak of a licensed model

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

Inference on an unlicensed model

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

Covert training of an unlicensed model

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.

What we don’t defend against

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

The retrofit, device by device.

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

▲ claims trust ▼
FABRIC passive optical tap · data fiber
headers hashed at line rate · commitments ▲ AN
TRAY I/O

GPU server tray · 1 of N

IN ↑ INPUT / OUTPUT ↓ OUT

SmartNIC

gateway · traffic · job manifest

DC-SCM / BMC

power · inventory

CPU TEE : host attestation

8× GPU · TEE

🔒 CC

▼ FRONT · COLD-AISLE INTAKE

WHERE Draft standard · v0.2

Where are the chips located?

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
}
WHO In development

Who is using the model?

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"
  }
}
WHAT In development

What model is running?

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)"
}
HOW In development

How are the chips being used?

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

Three roles, mutually verifiable.

Runs the cluster

The Operator

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.

signed claims
Operates the Assurance Node

The Verification Provider

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.

AI Passport
Consumes receipts

The Relying Party

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.

LUCID
230V
Assurance Node · secure rack

At the centre

The Assurance Node.

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'")

Define a claim. The node runs it under attestation.

Claims Auditor · SDK Confidential VM Assurance Node

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

Sealed, watched, and self-reporting.

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.

Tamper-responsive mesh

An attack destroys what it reads

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.

Side-channel hardened

No leaks through the side door

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.

Watched, and bound to the record

Cameras feed the Assurance Node

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.

References: the public literature this work builds on ▾

Confidential computing & GPU TEEs

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

Attacks on trusted execution: why one root is never enough

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

Roots of trust & attestation standards

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

Verifiable inference: determinism & recompute

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

Cryptographic proof approaches

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

Telemetry & workload verification

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)

Location verification & hardware-enabled governance

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)

International verification & policy

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

Supply chain & tamper evidence

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

Network observation, completeness & liveness

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

Safety evaluation benchmarks (shown in the WHAT example)

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.

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 →