Mechanisms
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 specific systems that realise them are listed under Implementations.
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 |
|---|---|---|---|
| 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 | This compute runs inference, not training; Declared hardware is idle or shut down | Semi-trusted prover |
| 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. | R2Demonstrated | The declared model is the one being served | 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 | A training run stayed within declared limits | 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 | This compute runs inference, not training | Adversarial prover |
| Side-channel suppression for isolated facilities Shielding, filtering, jamming and inspecting an AI facility so that no hidden physical channel can bypass the checks placed on its official links. | R1Proposed | Communication between compute groups is bounded | 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 |
|---|---|---|---|
| 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 | The declared model is the one being served | Semi-trusted prover |
| 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. | R2Demonstrated | The declared model is the one being served | 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. | R2Demonstrated | The declared model is the one being served | Semi-trusted prover |
| Proof-of-learning and training-transcript verification 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 | A training run stayed within declared limits | Adversarial 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 | Declared safeguards were applied during inference | 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. | R2Demonstrated | The declared model is the one being served | 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 | The declared model is the one being served | 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 | A training run stayed within declared limits | Adversarial prover |
| Proofs of useful work and resource exhaustion Cryptographic evidence that hardware performed a given amount of agreed computation, proposed as a way to show no spare capacity remained for other work. | R1Proposed | There is no undeclared relevant compute | Adversarial 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. | R1Proposed | Declared hardware is idle or shut down | 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 |
|---|---|---|---|
| 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 | Model weights or data have not left the facility | Adversarial prover |
| Bandwidth limits and compartmentalization Capping or removing the network links between groups of accelerators, so that serving models still works but large training runs become impractically slow. | R1Proposed | Communication between compute groups is bounded | Adversarial prover |
| Memory wiping and proofs of secure erasure Overwriting all of a device's memory in a way a verifier can check, so that nothing from earlier, undeclared work survives the wipe. | R1Proposed | Adversarial prover | |
| Reproducible computation 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 | This compute runs inference, not training | 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 | Chips are where they are declared to be | 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 | Compute stock is at most a declared amount | 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 | This compute runs inference, not training | 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 | There is no undeclared relevant compute | Adversarial prover |