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.

NameReadinessVerifiesThreat 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 productionSemi-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.
R2DemonstratedSemi-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.
R1ProposedAdversarial 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.
R1ProposedAdversarial prover

Off-chip devices & sensors (3)

Retrofittable devices outside the accelerator: network taps and certifiers, power and analog sensors, tamper-evident enclosures.

NameReadinessVerifiesThreat model
Tamper evidence for verifier devices
Enclosures, seals and sensors that make physical interference with verification hardware either visible or self-defeating.
R2DemonstratedAdversarial 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.
R1ProposedAdversarial prover
Side-channel suppression for isolated facilities
Shielding, filtering, jamming and inspecting an AI facility to limit hidden physical communication around monitored network links.
R1ProposedAdversarial prover

Cryptographic & computational (10)

Protocols that check computation itself: recomputation, zero-knowledge proofs, proofs of learning, proofs of work, challenge-response.

NameReadinessVerifiesThreat 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 productionAdversarial 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 productionSemi-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 productionAdversarial 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.
R2DemonstratedSemi-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.
R2DemonstratedSemi-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.
R2DemonstratedAdversarial 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.
R2DemonstratedAdversarial 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.
R2DemonstratedAdversarial 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.
R2DemonstratedAdversarial 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.
R1ProposedAdversarial 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.

NameReadinessVerifiesThreat 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.
R2DemonstratedAdversarial 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.
R2DemonstratedAdversarial 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.
R1ProposedAdversarial 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.
R1ProposedAdversarial 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.

NameReadinessVerifiesThreat 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.
R1ProposedAdversarial 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.
R1ProposedSemi-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.

NameReadinessVerifiesThreat 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.
R2DemonstratedAdversarial 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.
R1ProposedAdversarial prover

Search

Full search page