Mechanisms
A mechanism is a general technique for verifying a claim about AI hardware or software. Mechanisms are grouped by category and sorted by readiness. The Verifies column lists the claims each is aimed at, then, in grey italics, those it supports. Implementations realise one or more mechanisms.
On-chip & hardware-enabled (4)
Mechanisms built into accelerators or their firmware: trusted execution, attestation, hardware-enabled governance, on-chip telemetry and limits.
| Name | Readiness | Verifies | Threat model |
|---|---|---|---|
| TEE remote attestation for AI workloads Trusted execution environments (TEEs) in CPUs and GPUs sign reports of loaded software, so a remote party can check which code ran an AI workload. | R3In production | Semi-trusted prover | |
| On-chip telemetry from timing, memory and performance counters Uses timing, memory-residency and performance-counter signals measured on AI accelerators as evidence about which workloads they are running. | R2Demonstrated | Semi-trusted prover | |
| Hardware performance throttling and licensing On-chip mechanisms that cut an AI accelerator's performance when a license expires or a trusted trigger fires, bounding what the hardware can do. | R1Proposed | Adversarial prover | |
| Hardware-enabled guarantees (flexHEG) and guarantee processors Proposed chip add-ons, a guarantee processor inside a tamper-protected enclosure, that would check and enforce agreed rules on how AI accelerators are used. | R1Proposed | Adversarial prover |
Off-chip devices & sensors (3)
Retrofittable devices outside the accelerator: network taps and certifiers, power and analog sensors, tamper-evident enclosures.
| Name | Readiness | Verifies | Threat model |
|---|---|---|---|
| Tamper evidence for verifier devices Enclosures, seals and sensors that make physical interference with verification hardware either visible or self-defeating. | R2Demonstrated | Adversarial prover | |
| Network taps and certifiers Devices on a cluster's network links that copy and hash all traffic, so a verifier can later check sampled records against declared work. | R1Proposed | Adversarial prover | |
| Side-channel suppression for isolated facilities Shielding, filtering, jamming and inspecting an AI facility to limit hidden physical communication around monitored network links. | R1Proposed | Adversarial prover |
Cryptographic & computational (10)
Protocols that check computation itself: recomputation, zero-knowledge proofs, proofs of learning, proofs of work, challenge-response.
| Name | Readiness | Verifies | Threat model |
|---|---|---|---|
| Deterministic and bit-exact inference Making model inference reproducible bit for bit, so that a verifier's re-run must match the provider's output exactly rather than approximately. | R3In production | Adversarial prover | |
| Model identity attestation Establishes that responses come from a specific, committed set of model weights, using enclave measurements or recomputation of sampled outputs. | R3In production | Semi-trusted prover | |
| Sampled inference recomputation A verifier re-runs a random sample of an AI provider's logged queries on a trusted copy of the declared model and checks the outputs match. | R3In production | Adversarial prover | |
| Confidential multi-party verification Lets mutually distrusting parties run an agreed check over private models or records inside attested enclaves or zero-knowledge proofs, revealing only the result. | R2Demonstrated | Semi-trusted prover | |
| Safeguard attestation Hardware-signed evidence that an AI service ran its declared safeguards, such as a guardrail classifier or monitor, when producing a given response. | R2Demonstrated | Semi-trusted prover | |
| Timed challenge-response and memory-occupation challenges A verifier sends unpredictable questions that a device can answer in time only if it holds specified data, or dedicates specified resources, locally. | R2Demonstrated | Adversarial prover | |
| Training-transcript verification (proof-of-learning) A trainer logs checkpoints, data order and settings, so a verifier can re-run sampled training segments and check that the claimed training happened. | R2Demonstrated | Adversarial prover | |
| Zero-knowledge proofs of inference A prover produces a cryptographic proof that an output came from running a committed model on a given input, without revealing the weights. | R2Demonstrated | Adversarial prover | |
| Zero-knowledge proofs of training constraints Cryptographic proofs that a training run followed a committed dataset, procedure and rules, checkable without revealing the model or the data. | R2Demonstrated | Adversarial prover | |
| Proofs of useful work for capacity accounting Cryptographic evidence that a given amount of matrix-multiplication work was completed, proposed as one input to accounting for spare capacity on declared hardware. | R1Proposed | Adversarial prover |
Isolation & system architectures (4)
Ways of arranging or constraining a facility so that other checks become possible: bandwidth limits, compartmentalization, memory wiping, secure facilities, whole verification stacks.
| Name | Readiness | Verifies | Threat model |
|---|---|---|---|
| Bandwidth limits and compartmentalization Capping or removing network links between groups of accelerators, so that serving within each group still works but large training across groups becomes far slower. | R2Demonstrated | Adversarial prover | |
| Bounding unexplained information in outputs Limits the hidden information a facility's outputs can carry by measuring how much of those outputs the declared computation fails to predict. | R2Demonstrated | Adversarial prover | |
| Memory wiping and proofs of secure erasure Overwriting a device's memory in a way a verifier can check, so that data from earlier, undeclared work cannot persist in memory the wipe reaches. | R1Proposed | Adversarial prover | |
| Whole-workload recomputation (reproducible packets) Organizing all AI workloads in a facility into discrete, reproducible units, so that a verifier can recompute a random sample and check each one. | R1Proposed | Adversarial prover |
Compute accounting & provenance (2)
Establishing what compute exists, where it is and what it can do: chip registries, manufacturing records, location verification, capacity bounds.
| Name | Readiness | Verifies | Threat model |
|---|---|---|---|
| Chip location verification Timing a chip's signed replies to trusted servers at known places, so that the speed of light bounds how far away the chip can be. | R1Proposed | Adversarial prover | |
| Chip registries and manufacturing records Recording each AI chip's identity and owner from the fab onwards, and cryptographically fixing manufacturing records, so that chips can be accounted for later. | R1Proposed | Semi-trusted prover |
Remote & side-channel sensing (2)
Inferring activity from outside or from physical signals: detecting data centres, classifying workloads from power or other emissions.
| Name | Readiness | Verifies | Threat model |
|---|---|---|---|
| Workload classification from telemetry and side channels Telling whether chips are training, serving or doing non-AI work from GPU counters or power draw, signals that do not read weights or data. | R2Demonstrated | Adversarial prover | |
| Remote detection of data centres Remote detection locates large data centres and estimates their power capacity without site access, using satellite imagery, heat signatures and public records such as permits. | R1Proposed | Adversarial prover |