Mechanisms · category

On-chip & hardware-enabled

Mechanisms built into accelerators or their firmware: trusted execution, attestation, hardware-enabled governance, on-chip telemetry and limits.

Name	Type	Readiness	Verifies	Threat model
Attestable Audits A research prototype that runs AI safety benchmarks inside a trusted execution environment and publishes attestations binding the model, the audit and the results. Provider-reported	Implementation	R2Demonstrated	The declared model is the one being served	Semi-trusted 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.	Mechanism	R2Demonstrated	The declared model is the one being served	Semi-trusted prover
Model identity attestation Establishes that responses come from a specific, committed set of model weights, using enclave measurements or recomputation of sampled outputs. ⚠ Open critical flaw Provider-reported	Mechanism	R2Demonstrated	The declared model is the one being served	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. ⚠ Open critical flaw	Mechanism	R2Demonstrated	This compute runs inference, not training; Declared hardware is idle or shut down	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. Provider-reported	Mechanism	R2Demonstrated	Declared safeguards were applied during inference	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. ⚠ Open critical flaw Provider-reported	Mechanism	R2Demonstrated	The declared model is the one being served	Semi-trusted prover
Tinfoil model identity (Modelwrap) Tinfoil's method for proving which model weights its enclave-hosted inference service runs, by binding a dm-verity hash of the weights into remote attestation. ⚠ Open critical flaw Provider-reported	Implementation	R2Demonstrated	The declared model is the one being served	Semi-trusted prover
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.	Mechanism	R2Demonstrated	This compute runs inference, not training	Adversarial prover
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.	Mechanism	R1Proposed	Chips are where they are declared to be	Adversarial 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.	Mechanism	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.	Mechanism	R1Proposed	A training run stayed within declared limits	Adversarial prover
Lucid sovereignty (location) certificates A draft specification, hosted by Lucid Computing, for short-lived certificates that bound where a workload runs by timing signed exchanges with fixed anchors. Provider-reported	Implementation	R1Proposed	Chips are where they are declared to be	Semi-trusted prover

Includes records that list this as a secondary category.