# AI Verification Landscape — full text


## Compute stock is at most a declared amount (C-0001, claim)
A party holds no more AI-relevant compute, counted in chips or equivalent capacity, than the total it has declared.
Many proposed AI agreements start from an inventory: each party declares how many AI chips it holds, and others check that the real total is no larger. A bounded stock caps how much training or inference a party could run in secret, and anchors other checks, such as monitoring how chips are used. The claim is negative, which makes it hard to verify. Millions of AI-relevant chips already exist without central tracking, and a party could acquire or build chips outside any registry. Proposals combine monitoring of the chip supply chain from fabrication onward, registries of chips and their owners, inspections, and intelligence methods such as customs and financial data. Supply-chain tracking can reach newly produced chips; the existing stock is the main gap.
## Why it matters
An accurate chip count underpins other checks on compute. Proposals rely on it in several ways:

- **Shavit's monitoring framework** has three stages: on-chip logging, proofs about training runs, and monitoring of the chip supply chain [S-0029]. The third stage exists so that no actor can avoid discovery by amassing a large quantity of untracked chips [S-0029]. Without it, a prover could covertly acquire chips and train on them without ever notifying the verifier, bypassing checks on the chips it did declare [S-0029].
- **Sastry and colleagues** describe AI-relevant compute as detectable, excludable and quantifiable, and produced through an extremely concentrated supply chain [S-0053]. They list an international AI chip registry among possible mechanisms for regulatory visibility [S-0053].
- **A draft international agreement** would prohibit concentrations of more than 16 H100-equivalents outside monitored facilities [S-0063]. It would consolidate existing chips into those facilities and track new production [S-0063]. Chips would be located through supply-chain tracking, mandatory reporting, intelligence gathering, open-source intelligence, power monitoring, challenge inspections and whistleblowers [S-0063].
- **Scher and Thiergart** argue for locating AI chips at an initial point in time and then keeping them monitored, rather than relying on detecting secret data centres later [S-0005].

## Why it is hard
The claim is negative: it asserts that no chips exist beyond the declared total.

- **The existing stock.** Shavit noted in 2023 that hundreds of thousands of ML chips had already been sold, many lacking the security features his framework needs and possibly not locatable by governments [S-0029]. Scher and Thiergart write that millions of AI-relevant chips already exist with no central tracking, which could make an initial inventory difficult [S-0005].
- **Tracking must start at the fab.** Shavit's design monitors the small number of fabrication facilities that make leading-edge chips [S-0029]. It records each chip's burned-in serial number in a directory of chip owners, kept up to date when chips are resold or damaged [S-0029]. Responsibility for any missing chip precursors lies with the most recent holder [S-0029].
- **Supporting methods have gaps.** Wasil and colleagues note that customs data is less useful against countries that can manufacture components domestically, and that financial intelligence is limited because many hardware purchases have legitimate uses [S-0062]. Inspections of chip fabrication plants are resource-intensive and put intellectual property at risk [S-0062]. The same authors list local chip manufacture and the use of older chips as evasion routes, and note that chip location tracking would apply only to new chips [S-0062].
- **Chips are not a fixed unit of capacity.** RAND's framework counts a cluster as large-scale if it has the computing power of thousands of high-end AI chips controlled by a single entity [S-0002]. Sastry and colleagues caution that algorithmic progress can reduce the compute needed for a given capability, and that decentralised training could undermine the detectability of compute [S-0053].

The claim is closely tied to There is no undeclared relevant compute, which asks whether any compute lies outside the declared stock, and to Chips are where they are declared to be, which asks whether declared chips are where they are said to be.
Sources: [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-0063] An International Agreement to Prevent the Premature Creation of Artificial Superintelligence (2025) https://arxiv.org/abs/2511.10783; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0062] Verification methods for international AI agreements (2024) https://arxiv.org/abs/2408.16074; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-1411] Introducing the Frontier Data Centers Hub (2025) https://epoch.ai/latest/introducing-the-frontier-data-centers-hub; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html

## Chips are where they are declared to be (C-0002, claim)
Specific AI chips are physically located at the sites a party has declared, throughout the declared period.
Location claims underpin export controls and chip-tracking proposals. If each chip's location can be checked, a registry of declared sites becomes enforceable and diversion of chips to undeclared facilities becomes detectable. The claim concerns specific devices and can be tested positively, which makes it more tractable than proving that no chips exist elsewhere. The main technical approach has a chip answer timed challenges from trusted servers, so that the delay bounds its distance from them. A rudimentary prototype on NVIDIA H100 chips has been reported with one published result and no systematic measurements. NVIDIA is reported to be developing a similar scheme that uses its own servers. Physical inspection and supply-chain records complement the approach. Known weaknesses are extraction of the chip's private key, which would let another device answer on its behalf, modification of the chip hardware, and limited reach into chips already in circulation.
## Why it matters
Proposals use chip location in three ways.

- **Export controls.** High-end data-centre AI chips are subject to US export controls, but the Open Problems survey describes them as at present straightforward to smuggle [S-0001]. It names as a key technical problem that a chip's location or owner cannot currently be known after export [S-0001]. Verified location could also help cloud users check that their data is processed in line with local data-processing laws [S-0001].
- **International agreements.** Wasil and colleagues list chip location tracking, using unique identifiers and tracking mechanisms built into chips, among the hardware-dependent methods for verifying agreements [S-0062]. A draft international agreement requires parties to declare chip locations and to keep large concentrations of chips in monitored facilities where inspectors have ongoing physical access [S-0063].
- **A base for broader claims.** Scher and Thiergart treat locating AI compute as one of their main verification goals [S-0005]. They favour tracking chips over trying to detect secret data centres, and propose locating chips at an initial point in time and then keeping them monitored [S-0005]. The Open Problems survey also calls for methods to verify that a large number of chips are co-located in a single data centre [S-0001].

## Why it is hard
The main technical proposal is delay-based. A chip exchanges timed messages with a network of trusted servers, and the measured latencies constrain where it can be [S-0001]. Scher and Thiergart describe AI chips using time-based pings to servers around the world to locate themselves [S-0005]. An IAPS issue brief from May 2025, which summarises a 2024 report by Brass and Aarne, states that a rudimentary version has been prototyped on NVIDIA H100 chips [S-1401]. It shows one result: a landmark in Singapore verifying that a chip in Singapore is within 300 miles of Singapore [S-1401].

Avellar and Grunewald report, citing Reuters reporting from December 2025, that NVIDIA has confirmed it is developing location verification that estimates a chip's location from communication delays with NVIDIA-run servers [S-1402]. NVIDIA's own announcement from that month describes an opt-in fleet-management service that customers install and that reports read-only telemetry [S-1413]. The announcement states that NVIDIA GPUs do not have hardware tracking technology, kill switches or backdoors [S-1413].

- **Binding to the physical chip.** Scher and Thiergart identify the main security issue as ensuring that a chip's private key cannot be extracted [S-0005]. Extraction would let other chips pretend to be the chip in question, so its location could be spoofed [S-0005]. Wasil and colleagues list modifying AI chip hardware and spoofing location as evasion techniques, and note that sophisticated actors may try to disable tracking [S-0062].
- **Coverage.** Wasil and colleagues note that chip location tracking is limited to newly produced chips and requires agreements on manufacturing standards [S-0062]. Brass and Aarne, by contrast, expect that the H100's trusted execution environment could be used to implement location attestation [S-1400]. For chips without such features, location must be established by other means, such as physical inspection against a directory of chip serial numbers and owners [S-0029].
- **Scope.** A verified location says where a chip is, not what it is computing or who controls it. Proposals therefore pair location with verification of chip use [S-0063], which on this site falls under Declared hardware is idle or shut down and This compute runs inference, not training.
Sources: [S-0001] Open Problems in Technical AI Governance (2025) https://openreview.net/forum?id=1nO4qFMiS0; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0062] Verification methods for international AI agreements (2024) https://arxiv.org/abs/2408.16074; [S-0063] An International Agreement to Prevent the Premature Creation of Artificial Superintelligence (2025) https://arxiv.org/abs/2511.10783; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-1400] Location Verification for AI Chips (2024) https://www.iaps.ai/research/location-verification-for-ai-chips; [S-1401] Location Verification for AI Chips (issue brief) (2025) https://static1.squarespace.com/static/64edf8e7f2b10d716b5ba0e1/t/6827b67275666f3757f134ea/1747433075281/Location+Verification+two-pager.pdf; [S-1402] Near-Term Verification Methods for AI Chip Exports (2026) https://arxiv.org/abs/2609.07637; [S-1413] Opt-In NVIDIA Software Enables Data Center Fleet Management (2025) https://blogs.nvidia.com/blog/optional-data-center-fleet-management-software/; [S-1404] Sovereignty Certificates: draft specification, version 0.1.0 (2025) https://github.com/Lucid-Computing/sovereignty-certificate-specification; [S-0035] Flexible Hardware-Enabled Guarantees for AI Compute (2025) https://arxiv.org/abs/2506.15093

## Declared hardware is idle or shut down (C-0003, claim)
Specified AI chips or facilities are not performing computation, or are powered off, throughout a declared period.
Some agreement designs would pause certain activities by keeping declared chips switched off or idle, or hold a reserve of compute that is verified not to be in use. Verifying idleness would let a party show it is not using hardware it still owns. It is a negative claim, but a comparatively simple one: chips need power to compute, so a facility's power draw, knowledge of on-site generation and possibly thermal imaging could show whether hardware is running. One analysis expects this to be verifiable with less invasive methods than those needed to check what running chips compute. The difficulties are binding and coverage: showing that the monitored facility holds the declared chips, and obtaining reliable power data that cannot be masked. On-chip telemetry and hardware licensing could add chip-level evidence or enforcement.
## Why it matters
Idleness lets a party show that hardware it still owns is not in use. Proposals use it in three ways:

- **Pausing large training runs.** Scher and Thiergart observe that a data-centre operator can claim its chips are not being used in a large training run if the chips are not receiving the power they need to operate [S-0005]. They add that this can likely be verified with less invasive methods, such as the data centre's power draw, knowledge of on-site backup power generation, or possibly thermal imaging [S-0005].
- **Holding compute in reserve.** The AI 2040 verification plan suggests a small compute bank, verified not to be in use during an agreement, as a way to reduce the incentive to withdraw from it [S-0067].
- **Monitoring energy use.** Energy monitoring is one of the national technical means Wasil and colleagues consider for detecting unauthorised facilities, by analysing power consumption and converting energy estimates into an approximate count of operations [S-0062].

## Why it is hard
The claim is negative: it asserts that no computation takes place.

- **Power data describes a facility, not a chip.** A verifier must know about every power source, including on-site generation [S-0005]. Wasil and colleagues note that energy monitoring is unproven in practice, that energy use may be disguised as other high-energy activity, and that detailed consumption data is hard to obtain [S-0062]. They list masking a data centre's energy use and siting a data centre at a power plant as evasion techniques [S-0062].
- **Binding.** A dark building shows that the chips inside it are idle, but not that the declared chips are the ones inside. The claim therefore depends on verifying chip location and custody, covered under Chips are where they are declared to be.
- **Chip-level evidence is immature.** RAND's framework includes off-chip analog sensors, and lists estimating a workload's utilisation and associated physical signature, such as power, as a research problem [S-0002]. Monfared and colleagues report timing and memory measurements on GPUs that correlate with compute activity even when host and device are untrusted [S-0033]. One telemetry classifier detects training with 98.2% accuracy across its own corpus, falling to 43–87% on the most challenging disguised workloads held out from its training [S-0037].
- **Hardware enforcement.** RAND's offline-licensing design grants a chip a compute budget through a renewable licence; once the budget is spent, the chip would refuse the relevant operations or perform them at a much lower rate [S-0057].

Where chips must stay powered for permitted tasks, the claim becomes a bound on use rather than idleness, and the questions of This compute runs inference, not training and A training run stayed within declared limits apply.
Sources: [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0062] Verification methods for international AI agreements (2024) https://arxiv.org/abs/2408.16074; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-0037] Detecting Hidden ML Training With Zero-Overhead Telemetry (2026) https://arxiv.org/abs/2606.19262; [S-0033] Timing and Memory Telemetry on GPUs for AI Governance (2026) https://arxiv.org/abs/2602.09369; [S-1102] Pacing AI Requires Proof (2026) https://attestable.com/blog/pacing-ai-requires-proof

## This compute runs inference, not training (C-0004, claim)
A declared cluster is used only to run existing models to produce outputs, and not to train new or more capable models.
Several agreement proposals would let existing AI models keep serving users while restricting further training. That requires verifying that a data centre runs inference only. The claim combines a positive part (the declared inference is happening) with a negative part (nothing else, especially training, is). It matters because it could let most AI compute stay in productive use under a training restriction. It is hard because the same chips can do both, workloads can be disguised, and the negative part requires accounting for all of a facility's activity. Proposed approaches include capturing and recomputing the traffic that enters and leaves a facility, limiting bandwidth between groups of chips so that large training cannot be coordinated, and classifying workloads from telemetry. Each rests on open assumptions about numerical nondeterminism, hidden capacity and side channels.
## Why it matters
Several proposals to restrict frontier AI development target training while preserving the use of existing models [S-0063] [S-0067]. Sastry and colleagues note that most AI compute is now used for inference [S-0053].

- **A draft international agreement** restricts the scale of AI training. Its chip-use verification is meant to distinguish inference on existing systems from the training of new models [S-0063].
- **The AI 2040 verification plan** would convert data centres to inference-only operation, preventing training runs while models continue to serve users [S-0067].
- **RAND's framework** treats accurate declaration of AI inference as its own verification subgoal, separate from declared training [S-0002]. It lists deterministic replication of neural-network inference as a research problem [S-0002].
- **A low-trust system overview** names distinguishing inference from training, and deploying only approved models, among its core objectives [S-0018].

## Why it is hard
- **The same hardware can do both.** Scher and Thiergart expect that some current inference-specialised chips could be repurposed for training without significant effort [S-0005]. Shavit notes that there is no straightforward way to determine whether an ML chip is running a training job or an unrelated one [S-0029].
- **Classifiers invite evasion.** The Open Problems survey notes that adversarial customers may obfuscate their activities, for example by adding noise to how they use computational resources [S-0001]. One adversarial study of GPU-telemetry classifiers reports 98.2% accuracy at identifying training across its corpus, but 43–87% on the most challenging disguised workloads held out from its training [S-0037].
- **Training traffic is harder to observe.** Inference produces token-level input and output data on the front-end links between a data centre and its users [S-0018]. Training traffic runs over back-end fabric that has much higher bandwidth, is latency-sensitive, and is harder to tap [S-0018]. Cankaya describes front-end tapping as the most viable option, and notes that back-end tapping may require sampling rather than full capture [S-0031]. The system overview leaves open how far a facility can be required to make all egress traffic explainable by its ingress [S-0018].
- **Recomputation must cope with numerical noise.** Checks on sampled outputs handle it either statistically [S-0016] or by exact reproduction [S-0020].
- **Bandwidth limits may erode.** Limits between pods of chips could prevent the gradient exchange that distributed training needs [S-0005]. Sastry and colleagues note that more viable decentralised training could undermine the detectability of training [S-0053].
- **Hidden capacity and channels.** The negative part of the claim requires that no capacity or channel is hidden. The system overview addresses this with memory wiping and side-channel suppression, and lists open problems for both [S-0018].
Sources: [S-0063] An International Agreement to Prevent the Premature Creation of Artificial Superintelligence (2025) https://arxiv.org/abs/2511.10783; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0037] Detecting Hidden ML Training With Zero-Overhead Telemetry (2026) https://arxiv.org/abs/2606.19262; [S-0001] Open Problems in Technical AI Governance (2025) https://openreview.net/forum?id=1nO4qFMiS0; [S-0031] The Fundamentals and Feasibility of Secure Network Taps for Verifying AI Datacenter Use (2026) https://nacicankaya.substack.com/p/research-note-the-fundamentals-and; [S-0016] DiFR: Inference Verification Despite Nondeterminism (2025) https://arxiv.org/abs/2511.20621; [S-0020] Bit-Exact AI Inference Verification Without Performance Tradeoffs (2026) https://arxiv.org/abs/2606.00279; [S-1512] Verifying international AI deals: Plan A, the state-of-play, and what you can do to help (2026) https://amodo.substack.com/p/verifying-international-ai-deals; [S-0033] Timing and Memory Telemetry on GPUs for AI Governance (2026) https://arxiv.org/abs/2602.09369

## The declared model is the one being served (C-0005, claim)
Outputs delivered to users or auditors come from the specific model, weights and configuration the provider declared, not from a substitute.
Evaluations, audits and agreements often apply to one specific model. If a provider could evaluate one model and serve another, such as a cheaper, quantized or modified version, those checks would say little about what users receive. It is a positive claim that can be tested directly, but three problems make it hard. Numerical nondeterminism means honest recomputation does not match exactly. The verifier usually cannot see the weights, which are commercially or strategically sensitive. And the evidence must come from the actual serving system rather than a separate test instance. Approaches include statistical or exact recomputation of sampled outputs, hardware attestation of the loaded weights, and zero-knowledge proofs. They trade off cost, trust in hardware vendors and confidentiality.
## Why it matters
Checks on a model's capabilities or safety apply to the model that was checked. Several parties depend on that link:

- **Agreement verifiers.** RAND's framework asks verifiers to confirm that declared inference is declared accurately, so that the prover actually did the claimed deployment [S-0002]. It then asks them to confirm that deployed models have the required properties, for example through evaluations at regular intervals [S-0002]. Both steps assume the evaluated model is the served model. A low-trust system overview identifies running approved models for prohibited uses as the most difficult violation to defend against, and aims to deploy only approved models [S-0018]. The Oxford Martin report includes appendices on model fingerprint attestation and on "device-model mating" with an encrypted model [S-0004].
- **Customers.** The DiFR authors note that providers and their customers increasingly need to verify that inference is performed correctly, without errors or tampering [S-0016]. Their Token-DiFR method detected 4-bit quantization of a model with AUC above 0.999 within 300 output tokens [S-0016].

## Why it is hard
- **Noise.** Re-running the same inference often gives slightly different results because of benign numerical variation, which makes it hard to tell legitimate variation from substitution [S-0016]. In LLM serving a major cause is that kernels are not invariant to batch size, which varies with server load [S-1009]. Statistical tests tolerate this noise [S-0016]. Alternatively, Cankaya reports that inference can be reproduced bit-exactly across several NVIDIA GPU variants in software, given enough recorded information about the original run [S-0020].
- **Confidentiality.** Recomputation requires the weights, which a provider or state may not reveal [S-0018]. One system design keeps weights cryptographically committed and uses them only inside air-gapped auditing environments [S-0018]. Zero-knowledge proofs avoid revealing weights at all. zkLLM reports proving a full inference of a 13-billion-parameter model in under 15 minutes, with proofs under 200 kB [S-0023], but the low-trust overview describes zero-knowledge proof computation as still expensive [S-0018]. Trusted execution environments can attest which software and data were loaded [S-0014]. PAL\*M reports property attestation on confidential computing hardware (Intel TDX with NVIDIA H100) at under 11% overhead for common operations [S-0012].
- **Binding.** Evidence about a test instance says nothing about production unless it is tied to the serving hardware and time. The low-trust design aims to identify each forward pass uniquely and attribute it to the hardware and time it was processed [S-0018]. TEE-based binding relies on the vendor's keys: whoever holds the hardware's attestation key can produce valid reports, and every component that influences inference must be covered by launch measurement [S-0014]. A published memory-bus interposition attack, which needs physical access, extracted a per-CPU Intel attestation key and forged Intel TDX attestations [S-1202]. Other attacks forged AMD SEV-SNP attestations, one through a DDR4 interposer and one from software alone before AMD's fix [S-1210] [S-1212].
Sources: [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0016] DiFR: Inference Verification Despite Nondeterminism (2025) https://arxiv.org/abs/2511.20621; [S-1009] Defeating Nondeterminism in LLM Inference (2025) https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/; [S-0020] Bit-Exact AI Inference Verification Without Performance Tradeoffs (2026) https://arxiv.org/abs/2606.00279; [S-0004] Verification for International AI Governance (2025) https://www.oxfordmartin.ox.ac.uk/publications/verification-for-international-ai-governance; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0023] zkLLM: Zero Knowledge Proofs for Large Language Models (2024) https://doi.org/10.1145/3658644.3670334; [S-0012] PAL*M: Property Attestation for Large Generative Models (2026) https://arxiv.org/abs/2601.16199; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance; [S-0009] Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments (2025) https://arxiv.org/abs/2506.23706; [S-1202] TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (2026) https://tee.fail/; [S-1210] Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing (2026) https://batteringram.eu/; [S-1212] RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP (2025) https://rmpocalypse.github.io/

## Declared safeguards were applied during inference (C-0006, claim)
Specified safety measures, such as input filters, output checks or monitoring, actually ran on the requests a deployed model served.
Rules for deploying AI systems often require safeguards: filters on inputs, checks on outputs, or monitoring for misuse. A developer's statement that safeguards exist does not show that they ran on every request, or that the version checked is the one in production. Verifying application matters to regulators and to agreements that allow deployment on condition of mitigations. It is a positive claim, but it inherits the difficulties of verifying the served model and adds more. Safeguards are often separate software components whose configuration can change, and the verifier usually cannot see users' prompts or the provider's systems. Proposals use trusted execution environments to attest the serving stack, audits run inside such environments, and inspections. Whether a safeguard is effective is a separate question from whether it was applied.
## Why it matters
Rules on deployment often take the form of required mitigations.

- **Regulators and auditors.** RAND gives the example of deployment mitigations specified in terms of input and output data, such as filtering out some kinds of inputs or running oversight checks on outputs [S-0002]. Proposals for frontier AI auditing call for rigorous third-party verification of developers' safety and security claims, grounded in deep, secure access to non-public information [S-0003].
- **International agreements.** Wasil and colleagues include inspections of AI developers to check that they run authorised code and properly implement model evaluations and safeguards [S-0062].
- **Users' privacy.** A 2026 analysis argues that trusted execution environments could let an auditor check that deployed software follows an agreed policy, with access control enforced so that neither the service provider nor the auditor needs to pair users' identities with their data [S-0014].

## Why it is hard
- **Knowing what software is serving.** With TEEs, hardware attestation can show that specified software is running unaltered, but only for what the launch measurement covers [S-0014]. The same analysis notes that every component influencing inference behaviour must be covered, and that incomplete specifications could let an adversary undermine deployment integrity [S-0014]. It also notes that whoever holds the hardware's attestation key can produce valid reports, and that side-channel and physical attacks remain concerns [S-0014].
- **Confidentiality.** Attestable Audits runs benchmarks inside TEEs so that results are verifiable while model weights and test data stay confidential, with a prototype tested on Llama-3.1 [S-0009]. PAL\*M defines properties across training and inference and attests them using confidential virtual machines with GPU support [S-0012]. Its authors model the protocol formally with the Tamarin prover [S-0012].
- **Software changes quickly.** Wasil and colleagues note that code can be rapidly modified or hidden, which limits what periodic inspections of developers can show [S-0062]. Automated inspection has its own weaknesses: a low-trust system overview notes that inspector agents may be vulnerable to prompt injection and that their classification precision is uncertain [S-0018].
- **Application is not effectiveness.** Proof-of-guardrail's authors note that an attested guardrail can still err or be jailbroken [S-1500]. RAND notes that deciding which technical rules actually achieve policy objectives remains difficult [S-0002]. Personnel-based layers such as whistleblower programmes and interviews are proposed for cases where technical evidence is unavailable [S-0002].
Sources: [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0062] Verification methods for international AI agreements (2024) https://arxiv.org/abs/2408.16074; [S-0003] Frontier AI Auditing: Toward Rigorous Third-Party Assessment of Safety and Security Practices at Leading AI Companies (2026) https://arxiv.org/abs/2601.11699; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance; [S-0009] Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments (2025) https://arxiv.org/abs/2506.23706; [S-0012] PAL*M: Property Attestation for Large Generative Models (2026) https://arxiv.org/abs/2601.16199; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-1500] Proof-of-Guardrail in AI Agents and What (Not) to Trust from It (2026) https://arxiv.org/abs/2603.05786; [S-1503] Enabling Verifiably-Scoped Monitoring through Large Language Models and Trusted Compute (2026) https://icml.cc/virtual/2026/78630; [S-1504] Auditor-in-a-Box: Tools for Third-Party Auditing (2026) https://www.lesswrong.com/posts/uWYk7MM9hAf9GEbGe/auditor-in-a-box-tools-for-third-party-auditing

## A training run stayed within declared limits (C-0007, claim)
A declared training run used no more compute than permitted and had its declared properties, such as data, hyperparameters and resulting weights.
Many proposed rules on frontier AI limit training, often through a threshold on total training compute measured in floating-point operations, sometimes combined with limits on data or methods. Verifying that a run stayed within them would let a regulator or treaty partner rely on something other than self-reporting. The claim is mixed: the declared run happened as described, and it did not exceed its limits. It is hard because training is long, distributed and expensive to repeat. Exact replay is complicated by numerical noise, the data and weights are sensitive, and work could be split across declared and undeclared hardware. Proposals include on-chip logging of weight snapshots with sampled recomputation of training segments, proof-of-learning protocols, zero-knowledge proofs and telemetry-based accounting. Published attacks show that the original proof-of-learning protocol can be spoofed.
## Why it matters
Limits on training are a common rule in compute-governance proposals [S-0062].

- **Shavit's framework** aims to give governments high confidence that no actor uses large quantities of specialised ML chips for a training run that violates agreed rules [S-0029]. Its example rules include total training compute, properties of the training data, hyperparameters such as the share of reinforcement-learning steps, and combinations of these with benchmark performance [S-0029].
- **US Executive Order 14110** required reporting for models trained with more than 10^26 operations [S-0053]. It was revoked in January 2025 [S-0069].
- **A draft international agreement** prohibits training runs above 10^24 FLOP, and requires runs above 10^22 FLOP to be approved and monitored [S-0063].
- **Wasil and colleagues** treat training above an agreed FLOP threshold as one of two main violation types to be detected [S-0062]. RAND lists verifying declared training as its own subgoal [S-0002].

Without technical verification, such limits rest on self-reporting, a gap the authors of a 2026 zero-knowledge proposal identify in current frontier AI governance frameworks [S-0025].

## Why it is hard
- **Training cannot simply be re-run.** Shavit gives three reasons: hardware noise makes training irreproducible, the compute cost is very large, and the training data may be confidential [S-0029]. His framework instead has chips save weight snapshots at random times, and the verifier re-runs short segments between reported checkpoints, accepting results within a tolerance [S-0029].
- **Transcripts can be spoofed.** Shavit notes that proving a transcript is the original one is harder than proof-of-learning, because the adversary knows the true transcript and has more compute time to construct a spoof [S-0029]. Fang and colleagues introduced spoofing strategies against proof-of-learning that reproduce across verification configurations at a fraction of the cost of earlier attacks [S-0027]. They conclude that a provably robust proof-of-learning mechanism cannot be built without further understanding of optimisation in deep learning [S-0027].
- **Coverage.** A limit on one run means little if other hardware contributes undeclared work, so Shavit pairs run verification with supply-chain monitoring [S-0029]. Training traffic runs over high-bandwidth back-end fabric that is harder to capture than inference traffic [S-0018].
- **Open design problems.** Shavit lists extending pre-commitment to online reinforcement learning, where training data cannot be known in advance, and choosing principled thresholds when scaling laws do not reliably predict downstream capabilities [S-0029].
- **Cryptographic cost.** A 2026 proposal notes that governance analyses judge zero-knowledge proofs currently impractical at frontier scale, and argues that this is a limit of current approaches rather than a fundamental one [S-0025]. It sets out an architecture combining a pre-committed training specification, network observations and Merkle commitments, and estimates a proof of concept within about 36 months [S-0025].
- **Compute is a proxy.** Training compute is only a high-level proxy for capability, and thresholds may need to change as algorithms improve [S-0053].
Sources: [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-0069] Executive Order 14148: Initial Rescissions of Harmful Executive Orders and Actions (2025) https://www.federalregister.gov/documents/2025/01/28/2025-01901/initial-rescissions-of-harmful-executive-orders-and-actions; [S-0063] An International Agreement to Prevent the Premature Creation of Artificial Superintelligence (2025) https://arxiv.org/abs/2511.10783; [S-0062] Verification methods for international AI agreements (2024) https://arxiv.org/abs/2408.16074; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0025] Zero knowledge verification for frontier AI training is possible (2026) https://arxiv.org/abs/2606.05433; [S-0027] Proof-of-Learning is Currently More Broken Than You Think (2023) https://arxiv.org/abs/2208.03567; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0035] Flexible Hardware-Enabled Guarantees for AI Compute (2025) https://arxiv.org/abs/2506.15093; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-0030] Tools for Verifying Neural Models' Training Data (2023) https://proceedings.neurips.cc/paper_files/paper/2023/hash/03e33e1f62e3302b47fe1d38a235921e-Abstract-Conference.html; [S-1110] Zero-Knowledge Proofs of Training for Deep Neural Networks (2024) https://eprint.iacr.org/2024/162

## Communication between compute groups is bounded (C-0008, claim)
Data flowing between specified groups of chips, or out of a facility, stays below a declared rate, so the groups cannot jointly run large workloads.
Large-scale training requires chips to exchange large volumes of data, while serving an existing model needs much less between groups of chips. A verified bound on communication between compute groups could therefore restrict training while allowing inference. A bound on a facility's external links also limits how much weights or data could leave it. The claim is negative: no channel exceeds the bound, including channels outside the monitored network. Proposed designs cap the external bandwidth of small pods of chips or restrict chip networking in hardware, and use network taps to observe the links. The hard parts are finding every path, including physical side channels; choosing bounds that stay meaningful as distributed training methods improve; and monitoring high-speed accelerator fabrics that are difficult to tap.
## Why it matters
Distributed training depends on fast communication between chips, so limiting communication limits training [S-0005].

- **Pods with narrow external links.** Scher and Thiergart describe pods of chips with high-bandwidth interconnect inside each pod but very low external bandwidth: enough for inference tokens, not for training gradients [S-0005]. They suggest this could be implemented with modest changes to existing technology, physical access and monitoring, without access to code [S-0005].
- **Hardware limits on networking.** Compute-governance analyses list physical limits on chip-to-chip networking as a way to enforce compute caps [S-0053]. RAND's "fixed set" design restricts networking so that small, fixed sets of GPUs cannot be aggregated into large clusters [S-0057].
- **Limits on what leaves a facility.** A low-trust system overview assumes that the information bandwidth of inference is not more than two orders of magnitude above expected API traffic at full utilisation [S-0018]. It asks how far a facility can be required to make all egress traffic explainable by its ingress [S-0018]. Rinberg and colleagues note that egress limits cap theft directly: if only 10 GB leaves a data centre, an adversary cannot steal more than 10 GB [S-1508]. This links the claim to Model weights or data have not left the facility.

## Why it is hard
The claim requires knowing every path.

- **Taps see only the links they are on.** RAND's network-tap layer observes data exchanged between chips [S-0002]. The cost and feasibility of tapping differ by link: Cankaya describes front-end links to the outside world as the most viable to monitor, while the back-end compute fabric has far higher bandwidth, is latency-critical, and may require sampling rather than full capture [S-0031].
- **Some links are hard to observe at all.** As scale-up domains grow, more traffic runs over copper links that passive optical taps cannot see, and encrypted interconnects complicate inspection [S-0031]. Shavit notes that methods for verifiers to confirm, after the fact, the topology in which chips were configured in a data centre were beyond the scope of his work [S-0029].
- **Physical side channels.** Data could bypass network monitoring altogether. A MIRI Technical Governance Team post surveys electromagnetic, acoustic, conducted and fibre-optic channels, and proposes shielding, active jamming with sensing, inspection and filtering [S-0038]. The system overview's target is to suppress covert side-channel bandwidth to kilobits per second, not to zero [S-0018].
- **Choosing the bound.** A threshold that separates inference from training today may not do so later. On the widely used C4 dataset, DiLoCo on 8 workers matched fully synchronous training while communicating 500 times less [S-1314]. Sastry and colleagues note that decentralised training across many data centres, or with lower-quality compute, could undermine compute detectability if it becomes more viable [S-0053].
Sources: [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-1314] DiLoCo: Distributed Low-Communication Training of Language Models (2024) https://arxiv.org/abs/2311.08105; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0031] The Fundamentals and Feasibility of Secure Network Taps for Verifying AI Datacenter Use (2026) https://nacicankaya.substack.com/p/research-note-the-fundamentals-and; [S-0038] Suppressing Side Channels in an Untrusted Data Center via Retrofitted Defenses (2026) https://techgov.intelligence.org/blog/suppressing-side-channels-in-an-untrusted-data-center-via-retrofitted-defenses; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-1301] Traffic Shaping for Workload Classification (2026) https://lucidcomputing.substack.com/p/traffic-shaping-for-workload-classification; [S-1313] The Tray as a Bandwidth Boundary (2026) https://amododesign.com/notes/2026-03-16-dpu-bandwidth-limiter/; [S-1508] Haiku to Opus in Just 10 bits: LLMs Unlock Large Compression Gains (2026) https://arxiv.org/abs/2604.02343

## Model weights or data have not left the facility (C-0009, claim)
No copy of specified model weights or sensitive data has left a designated facility through networks, physical media or other channels.
Agreements and security commitments may require that certain model weights stay inside a secured facility, for example to protect them against theft by well-resourced attackers. Verification itself creates a related concern, since monitoring equipment could leak the prover's secrets. Verifying that weights have not left is a negative claim over every possible channel: network links, physical media, people and physical side channels. Approaches include checking that outgoing traffic is explained by legitimate computation so that hidden data stands out, capping the bandwidth of external links, suppressing side channels, and physical security with inspection. Checking inference outputs against a reference cut the information an attacker could hide in responses to under 0.5% in one test; in an independent study, an attacker who controlled the prompts roughly doubled the leak. Physical and insider channels remain harder to bound.
## Why it matters
Model weights are a primary target for theft [S-1610].

- **Security of frontier models.** RAND researchers write that protecting frontier models from theft and misuse will become more important as they grow more capable [S-1610]. They identify 38 distinct attack vectors, and define five security levels for defending against actors ranging from opportunistic criminals to well-resourced nation-states [S-1610].
- **Agreements.** Scher and Thiergart describe one approach as using strong security to prevent model weights from leaving a data centre, and then monitoring that data centre closely [S-0005].
- **Verification itself.** RAND's framework treats confidentiality, meaning protection of models, data and code from unauthorised access and especially theft, as a requirement on verification [S-0002]. A low-trust system overview assumes the verifier may try to exfiltrate the prover's secrets [S-0018]. It therefore sends only cryptographic commitments out of the facility, and checks challenged data only in an auditing environment inside the prover's facility [S-0018].

## Why it is hard
The claim must hold for every channel. The RAND weight-security study's 38 attack vectors span far more than network transfer [S-1610].

- **Hidden data in ordinary outputs.** An attacker who controls an inference server could hide weights inside ordinary model responses using steganography [S-0015]. Rinberg and colleagues formalise this as a security game and verify outputs against a reference [S-0015]. On a 30-billion-parameter mixture-of-experts model, their detector reduced exfiltratable information to under 0.5% at a false-positive rate below 0.01%, which they equate to a slowdown of more than 200 times for an adversary [S-0015]. An independent study found that an attacker who chooses the prompts roughly doubles the bits leaked per token, cutting the slowdown to 60–118 times [S-1507].
- **Capping egress.** Rinberg and colleagues note that egress limits cap theft directly: if only 10 GB leaves a data centre, an adversary cannot steal more than 10 GB [S-1508]. Bounding a facility's links in this way is the subject of Communication between compute groups is bounded.
- **Explaining all egress.** Making all egress traffic explainable by its ingress is an open design question, including which engineering compromises it would require [S-0018]. Active network taps on front-end links could scrub headers to reduce covert channels [S-0031].
- **Physical side channels.** These offer routes around network monitoring altogether. Proposed defences include shielding, jamming, inspection and filtering [S-0038], with a design target of kilobits per second rather than zero [S-0018]. Residual copies in memory are addressed by memory wiping [S-0018].
- **Insiders and physical media.** These are outside the reach of network-level mechanisms. RAND's verification framework includes whistleblower programmes and personnel interviews among its layers [S-0002], and the weight-security study treats defence as requiring comprehensive measures rather than isolated ones [S-1610].
Sources: [S-1610] Securing AI Model Weights: Preventing Theft and Misuse of Frontier Models (2024) https://www.rand.org/pubs/research_reports/RRA2849-1.html; [S-0015] Verifying LLM Inference to Detect Model Weight Exfiltration (2025) https://arxiv.org/abs/2511.02620; [S-1507] Adversarial Entropy Inflation Against Gumbel-Based Inference Verification (2026) https://arxiv.org/abs/2608.23375; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0038] Suppressing Side Channels in an Untrusted Data Center via Retrofitted Defenses (2026) https://techgov.intelligence.org/blog/suppressing-side-channels-in-an-untrusted-data-center-via-retrofitted-defenses; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0031] The Fundamentals and Feasibility of Secure Network Taps for Verifying AI Datacenter Use (2026) https://nacicankaya.substack.com/p/research-note-the-fundamentals-and; [S-1508] Haiku to Opus in Just 10 bits: LLMs Unlock Large Compression Gains (2026) https://arxiv.org/abs/2604.02343; [S-0020] Bit-Exact AI Inference Verification Without Performance Tradeoffs (2026) https://arxiv.org/abs/2606.00279; [S-1510] Highly Secure Inference Data Centers: A Vertically Integrated Strategy for Security Engineering (2026) https://www.rand.org/pubs/research_reports/RRA4827-1.html

## There is no undeclared relevant compute (C-0010, claim)
A party controls no AI-relevant computing hardware or facilities, above an agreed threshold, beyond those it has declared.
Every other check on declared hardware can be sidestepped if a party runs prohibited work on hardware it never declared. Verifying that no such compute exists is therefore central to many proposed AI agreements. It is also among the hardest claims to establish, because it asserts an absence across a whole country or organisation, and demonstrating non-existence is generally harder than demonstrating existence. No single technique establishes it. Proposals combine tracking chips from manufacture, so that the declared stock is complete; searching for undeclared facilities with satellite imagery, energy data, customs and financial intelligence; and human sources such as whistleblowers and inspections. Each has documented evasions, and the achievable assurance depends on how much compute a meaningful violation would require.
## Why it matters
Checks on declared hardware say nothing about hardware that was never declared.

- **RAND's framework** gives this its own goal: verifying that there are no undeclared uses of large-scale AI compute [S-0002]. It splits the goal into no undeclared use of declared clusters, and no undeclared clusters, whether inside known data centres or standalone [S-0002].
- **Shavit's framework** depends on the same property. Without chip-ownership verification, a prover might covertly acquire a large quantity of chips and train on them without ever notifying the verifier [S-0029].
- **Wasil and colleagues** list unauthorised data centres as one of two main violation types [S-0062].
- **A draft international agreement** relies on a combination of supply-chain tracking, mandatory reporting, state intelligence, open-source intelligence, power monitoring, challenge inspections and whistleblowers to locate chips [S-0063].

## Why it is hard
The claim asserts absence. The Oxford Martin report observes that demonstrating the existence of an object or process is often straightforward compared with demonstrating its non-existence [S-0004].

- **Hidden facilities.** Scher and Thiergart judge that detecting covert data centres may be difficult, because AI compute may be hidden among other compute or in secret facilities [S-0005]. They see whistleblowers and intelligence as possible means of detection [S-0005]. Sastry and colleagues note that large training facilities are visible because of their size and power demands, and that hiding them underground would likely increase cost significantly [S-0053].
- **Limits of each detection method.** Wasil and colleagues note that data centres could be concealed underground or camouflaged from satellite imagery, and that energy use can be disguised as other high-energy activity [S-0062]. Customs data is less useful against domestic chip production, and financial intelligence must separate illicit purchases from many legitimate ones [S-0062]. Whistleblowers may be deterred by fear of retaliation [S-0062].
- **The existing stock.** Shavit notes that many chips already sold lack the security features his framework needs and may not be locatable by governments [S-0029]. A 2026 analysis of TEE-based monitoring notes the difficulty of verifying that workload declarations are complete and of forming tight bounds on unknown compute [S-0014].
- **The threshold.** RAND's framework focuses on clusters with the computing power of thousands of high-end chips, while noting it is not clear that frontier AI deployment must happen at scale to be dangerous [S-0002]. Sastry and colleagues caution that low-compute narrow models can have dangerous capabilities, and that more viable decentralised training could undermine the detectability of compute [S-0053].
Sources: [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0004] Verification for International AI Governance (2025) https://www.oxfordmartin.ox.ac.uk/publications/verification-for-international-ai-governance; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0062] Verification methods for international AI agreements (2024) https://arxiv.org/abs/2408.16074; [S-0063] An International Agreement to Prevent the Premature Creation of Artificial Superintelligence (2025) https://arxiv.org/abs/2511.10783; [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance; [S-1409] Tracking Hyperscale AI Data Center Growth with Satellite Imagery (2026) https://fas.org/publication/tracking-hyperscale/; [S-1102] Pacing AI Requires Proof (2026) https://attestable.com/blog/pacing-ai-requires-proof

## Bandwidth limits and compartmentalization (M-0014, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1: detailed designs are public, but no cap that a verifier can check has been built. - R1 met: the AI 2040 plan proposes isolated inference units created by removing back-end networking, on the grounds that high-bandwidth links are mostly needed only for training [S-0067]. Lucid Computing gives a detailed design with a cap, a pod definition, adversary strategies, favourable assumptions and residual risks [S-1301]. The MIRI overview describes perimeters of monitored links sized to pods for inference [S-0018]. - R2 not met: Lucid states that the design is "still at the design stage and not yet implemented or red-teamed" [S-1301]. Amodo has demonstrated DPU-enforced rate limiting on 400G links on real hardware [S-1313]. That work targets weight security under a cooperating operator, not a cap that a verifier checks against the operator, and Amodo has not yet fully analysed resilience to a compromised DPU [S-1313]. The mechanism's implementations, RAND secure inference data center (SIDC) design and AI 2040 inference-only verification stack, are proposed architectures at R1. Confidence is medium: the design evidence is clear, but it is uncertain whether node-level rate-limiting demonstrations should count toward this use.
Capping or removing the network links between groups of accelerators, so that serving models still works but large training runs become impractically slow.
Training frontier models needs very fast links between many accelerators; serving a trained model needs far less. This mechanism caps or removes the links between groups of accelerators ("pods"), so that inference keeps working but large training runs become slow and costly. The AI 2040 plan would remove much back-end networking to create isolated inference units. Lucid Computing's design caps each 72-GPU pod at 1 Gbps in each direction. Lucid estimates that covert frontier training would then be at least about 350 times less efficient, provided an auditor randomizes how pods connect to routers; with operator-chosen routing, it can fall to about 25 times. As of September 2026 no cap that a verifier can check has been built or red-teamed. The main obstacles are showing that all traffic crosses the capped links and that the enforcing devices can be trusted. The largest known weakness is progress in low-communication training.
## How it works

Training and serving use the network differently [S-0067] [S-1301]. The AI 2040 plan notes that AI servers "have a lot of high bandwidth communication between them, but this is (mostly) only necessary for training" [S-0067]. Lucid Computing gives the same rationale: inference sends little external traffic, while training moves gradients, model state and activations among many machines [S-1301].

Two families of design use this asymmetry [S-0067] [S-1301]:

- **Removing links.** The AI 2040 plan would "convert datacenters into groups of isolated inference-units" by removing a significant amount of back-end networking [S-0067]. Its illustration retrofits 40% of US compute into inference units of four server racks [S-0067].
- **Capping links.** Lucid's Traffic Shaping design installs a network shaper at the north-south uplink of each pod, modelled as one GB200 NVL72 rack [S-1301]. It recommends a cap of 1 Gbps per direction per pod, averaged over 60 seconds [S-1301]. The parties would configure and agree on the shaping devices, built on commodity hardware or open standards through a mediated co-design process [S-1301].

The MIRI system overview frames the same boundary as a perimeter: untrusted devices are grouped so that only monitored links communicate in and out [S-0018]. For inference, that perimeter can be as small as pods of a few hundred accelerators [S-0018]. Monitored links are covered in Network taps and certifiers.

Amodo has built a related enforcement point for weight security [S-1313]. It replaced a node's NICs with NVIDIA BlueField-3 DPUs, reasoning that "all the traffic in and out of a node goes through a NIC", which creates "a clean bandwidth boundary" [S-1313].

For proofs of compartmentalization, a related approach to constraining training, see Zero-knowledge proofs of training constraints.

## What it establishes
Lucid aims to let a third party verify that frontier training either is not happening in a declared facility or would cost so much more that training a model ten times the current frontier becomes economically infeasible [S-1301]. It estimates a lower bound of about 350x on the inefficiency of covert frontier training, with central estimates of 1,000x to 10,000x, if the auditor controls pod routing and per-pod storage is capped [S-1301]. This addresses Communication between compute groups is bounded, and indirectly This compute runs inference, not training and A training run stayed within declared limits.

It does not establish:

- **What the pods compute.** A cap alone does not show this, so the AI 2040 plan pairs inference units with taps and recomputation (Sampled inference recomputation, Reproducible computation packets) [S-0067].
- **Absence of training inside one pod.** Lucid places training that fits within one pod, fine-tuning and reinforcement-learning post-training within one pod outside its modelled threat [S-1301].
- **Anything outside declared facilities.** Rahman judges it "infeasible to prevent evaders from getting fast internet connections" [S-0060].

## Threat model
- **Favourable adversary.** Lucid's analysis grants the adversary perfect overlap of communication and computation, zero pipeline bubbles and "the best published communication-reduction techniques", among other advantages [S-1301].
- **Auditor-controlled routing.** The bound holds only if the auditor randomizes the assignment of pods to routers and periodically re-randomizes it [S-1301].
- **Declared storage.** Per-pod storage must be declared, capped and inspected [S-1301].
- **Complete perimeter.** The shaper sits at each pod's uplink [S-1301]. The verifier must also know that no other path leaves the pod, which the MIRI overview handles with a perimeter where only monitored links communicate in and out [S-0018]; see Network taps and certifiers and Tamper evidence for verifier devices.

## Evidence
- **Designs.** The AI 2040 plan, Lucid's design brief and the MIRI overview are designs and analysis [S-0067] [S-1301] [S-0018]. Lucid describes its design as "still at the design stage and not yet implemented or red-teamed" [S-1301]. It reports that its engineers are building a proof of concept for red-teaming at a partner cluster [S-1301].
- **Node-level limiter.** Amodo reports 390 Gbps unencrypted and 193 Gbps encrypted throughput between two DPUs on a 400G link [S-1313]. That demonstration targets weight security with a cooperating operator, and Amodo has "not yet fully analysed resilience to a single compromised DPU" [S-1313].

## Limitations
- **Low-communication training.** DiLoCo matched fully synchronous training on 8 workers while communicating 500 times less [S-1314]. Rahman writes that this family theoretically allows large-scale training at under 100 Mbps [S-0060]. Lucid's bounds include DiLoCo- and SWARM-family methods, but it notes that extreme activation compression or modular paradigms could erode the margin [S-1301].
- **Routing control.** If the operator can group pods freely behind routers, the bound falls to about 90–220x uncompressed and as low as about 25x with compression [S-1301].
- **Hidden storage.** Undeclared per-pod storage weakens the bound [S-1301].
- **Scale-up bypass.** In GB200 topologies, GPUs reach other nodes through NVSwitches without a NIC on the path, and compromising one or two parallel switches would bypass a limit [S-1313].
- **Durability.** Lucid positions the design as "a short-to-medium-term deterrent and Phase-1 milestone" [S-1301].
Technical detail: - Pod and cap. Lucid Computing's Traffic Shaping design models a pod as one NVIDIA GB200 NVL72 rack (72 GPUs). A shaper at each pod's north-south uplink enforces a recommended cap of β = 1 Gbps (125 MB/s) per direction per pod, averaged over 60 seconds, about 14 Mbps per GPU [S-1301]. - Adversary. The reference served model is a "Fable-sized model (estimated 6T parameter MoE)"; the adversary's target is about 10x larger (60T parameters). Strategies analysed: centralized training adapted to the cap, DiLoCo-family low-communication data parallelism (including streaming and quantized variants), and SWARM-family decentralized pipeline parallelism. The analysis grants the adversary perfect overlap of communication and computation, zero pipeline bubbles, zero straggler and fault overhead, free coordination compute outside the pods, aggressive low-precision recipes and the best published communication-reduction techniques [S-1301]. - Results. The headline is a lower bound on the inefficiency multiplier of about 350x, with central estimates of 1,000x–10,000x depending on training architecture. For SWARM-style pipelines the floor falls to about 140x only if two further unproven techniques both succeed (8x lossless activation compression at frontier scale and an unusually narrow 60T-parameter architecture). The appendix summary claims at least 100x, with roughly 1.4–3.5x of margin, after stacking every charitable and speculative assumption [S-1301]. - Conditions. The auditor randomizes the assignment of pods to routers and re-randomizes it periodically, and per-pod local storage is declared, capped and inspected. If the operator could instead assign whole cells of 100 or more pods to one pipeline stage, the bound would collapse to about 90–220x uncompressed and as low as about 25x with compression [S-1301]. - Amodo's node-level limiter. NVIDIA BlueField-3 DPUs replace the NICs on a 400G Ethernet link, reaching 390 Gbps unencrypted and 193 Gbps encrypted between two DPUs [S-1313].
Sources: [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-1301] Traffic Shaping for Workload Classification (2026) https://lucidcomputing.substack.com/p/traffic-shaping-for-workload-classification; [S-1508] Haiku to Opus in Just 10 bits: LLMs Unlock Large Compression Gains (2026) https://arxiv.org/abs/2604.02343; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-1313] The Tray as a Bandwidth Boundary (2026) https://amododesign.com/notes/2026-03-16-dpu-bandwidth-limiter/; [S-1314] DiLoCo: Distributed Low-Communication Training of Language Models (2024) https://arxiv.org/abs/2311.08105; [S-0060] Does Distributed Training Undermine Compute Governance? (2026) https://arxiv.org/abs/2605.29359

## Bounding unexplained information in outputs (M-0024, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, low confidence. R2 through the inference-output instance, which has public code and an independent attack study; the facility-level architecture is still a proposal. - R1 met: Petrie and Mühlhäuser publish an architecture, the claim it verifies and its setting, in which neither party trusts the other's hardware [S-0019]. - R2 met through the instance for inference outputs. Rinberg et al. bound the covert information in LLM responses beyond what honest sampling from the declared model explains. They publish code and report results on a 30-billion-parameter mixture-of-experts model against a stated adversary who controls the inference server [S-0015]. The facility-level architecture remains at R1: its paper outlines protocol details, attacks and prototyping plans, not results [S-0019]. - R3 not met. Criterion (b) is met for the inference instance only: an independent researcher attacked it in practice, and the flaw shown widens the bound rather than defeating it, so the evaluation left no critical flaw open [S-1507]. The facility-level design has not been independently evaluated. Criterion (a) fails: no party other than the developers relies on the bound for a verification decision, and no production-grade system is available. Confidence is low. The R2 evidence covers token outputs of a single inference service, not the general bound over all facility outputs [S-0019], and the demonstrated bound degrades when the attacker controls prompts [S-1507].
Limits the hidden information a facility's outputs can carry by measuring how much of those outputs the declared computation fails to predict.
This mechanism measures how much of the information leaving a facility the declared work cannot explain. If a verifier can predict outputs from the declared model and recorded inputs, little room remains to smuggle out model weights or the results of hidden work. One proposed architecture routes all traffic through a verifier-controlled interlock and challenges the operator to show that random outputs follow from compliant computation; as of September 2026 no prototype results have been published. An instance for language-model inference, with public code, cut the information an attacker could hide to under 0.5% on a 30-billion-parameter model, under benign prompts and at a false-positive rate below 0.01%. An independent study showed that an attacker who chooses the prompts roughly doubles the leakage per token. The main obstacles are closing every other channel, including side channels, and tolerating numerical noise without leaving room for a covert channel.
## How it works

The idea is to measure the information that leaves a facility against what its declared work would produce [S-0019]. Petrie and Mühlhäuser propose verifying AI compute agreements by bounding the amount of unexplained information in network outputs, without either party trusting the other's hardware [S-0019].

- **Isolation and commitment.** The prover's compute nodes are isolated, and all traffic passes through a verifier interlock that records cryptographic commitments of the encrypted traffic [S-0019].
- **Prediction challenges.** From time to time the verifier challenges the prover to show that randomly selected outputs can be predicted by a policy-compliant computation on the measured inputs [S-0019].
- **Principle.** The better compliant computation predicts the outputs, the less bandwidth is left for exporting the results of undeclared workloads [S-0019].
- **Confidentiality.** The prover can recompute inside a verifier-controlled enclosure, the verifier can recompute inside a prover-controlled enclosure, or zero-knowledge proofs can be used [S-0019].

For language-model inference, Rinberg et al. make this concrete. Honest inference follows a well-defined generative process, so hiding data in responses must make them deviate from expected model behaviour [S-0015]. A verification server re-runs sampled requests with the trusted model and the shared random seed, scores how plausible each emitted token is, and bounds the rate at which hidden bits can pass unnoticed [S-0015]. See Sampled inference recomputation.

A related line of work uses compression [S-1509] [S-1508]. One proposal compresses each response with a weaker reference model, using arithmetic coding, so that only bits the reference model did not predict count against an upload limit [S-1509]. Rinberg and co-authors note that limiting egress rests on a simple fact: if only 10 GB leaves a data centre, no attacker can steal more than 10 GB [S-1508]. Language-model text compresses far better than model weights, so a facility can apply stricter egress limits [S-1508].

## What it establishes
It can put an upper bound on the covert information in checked outputs, which slows exfiltration rather than stopping it [S-0015]. Under benign prompt traffic, Rinberg et al. report that the exfiltratable fraction fell to under 0.5%, not zero [S-0015].

It does not establish:

- **That explained outputs are harmless.** It does not limit information that the declared computation itself explains [S-1508]. Compression research notes that someone with inference access can extract more proprietary information per bit than naive transmission allows [S-1508].
- **That no smaller model is being prepared.** One upload-limit proposal lists running a hidden distillation job inside the data centre, to produce a smaller model that is easier to move, as a residual route [S-1509].
- **Anything about other channels.** The inference scheme treats side channels as out of scope [S-0015].

## Threat model
- **Facility-level design.** Neither party trusts the other's hardware, and the prover's compute can be isolated behind the interlock [S-0019].
- **Inference scheme.** The adversary controls the server's outputs [S-0015]. The scheme also assumes trusted verification code, secure logging, private sampling that the adversary cannot manipulate, and randomness that is trusted and non-malleable [S-0015]. An independent study notes that the published bound assumes a passive attacker sending benign prompts [S-1507].
- **Upload limits.** The proposal assumes strong physical security [S-1509]. It also assumes that a lab's most powerful model will not generate more than one or two orders of magnitude more tokens than it saw in training [S-1509].

## Evidence
- **Inference outputs.** Rinberg et al. tested models from 3 to 30 billion parameters, including two mixture-of-experts models, and published code [S-0015]. On the 30-billion-parameter mixture-of-experts model, under benign prompt traffic, they report under 0.5% exfiltratable information at a false-positive rate below 0.01%, a slowdown of more than 200 times [S-0015].
- **Independent attack.** Kezins tested six instruction-tuned models of 1 to 32 billion parameters over three seeds [S-1507]. Engineered prompts roughly doubled leakage per token and reduced the slowdown to 60–118 times [S-1507].
- **Compressibility.** A question-asking protocol compressed responses to ratios of 0.0006 to 0.004 while recovering part of the gap between a small and a large model [S-1508].
- **Facility-level architecture.** Published as protocol details, attack vectors and prototyping plans [S-0019].

## Limitations
- **Entropy inflation.** An attacker who controls prompts widens the set of tokens the verifier tolerates [S-1507]. Kezins argues that designs built on the same unexplained-information bound inherit this weakness, and recommends calibrating tolerances against local token entropy [S-1507].
- **Noise tolerance.** The covert channel lives in the tolerance allowed for GPU nondeterminism [S-1507]. Bit-exact replay needs the hardware model, weights, parallelism layout, software versions and batch size [S-0018]; see Deterministic and bit-exact inference.
- **Residual physical bandwidth.** One design argues that suppressing covert physical bandwidth below kilobits per second is much more achievable than aiming for zero [S-0018]. See Side-channel suppression for isolated facilities and Bandwidth limits and compartmentalization.
- **Uncertain volumes.** The upload-limit author is uncertain about the ratio of generated tokens to model parameters [S-1509]. He estimates about a 25% chance that the approach can cheaply ensure that weights cannot be taken without bypassing physical security [S-1509].
Technical detail: - Fixed-seed sampling likelihood. The verifier knows the seed and recomputes the next-token distribution for each logged position, then scores whether each emitted token is plausible under honest sampling. Gumbel-Max and inverse-probability-transform estimators are given, and three theorems bound the rate at which an adversary can embed information while passing the check [S-0015]. - Reported result. On MoE-Qwen-30B under benign prompt traffic, exfiltratable information fell to under 0.5% at a false-positive rate below 0.01%, a slowdown of more than 200 times [S-0015]. - Attack result. Across six instruction-tuned models of 1 to 32 billion parameters and three seeds, adversarially chosen prompts raised leakage from 0.067–0.119 to 0.145–0.286 bits per token and cut the slowdown to 60–118 times, because the verifier's admissible-token set grows with the model's output entropy [S-1507]. - Compression bounds. LLM-based arithmetic coding with domain-adapted LoRA adapters is 2 times better than the base model; succinct rewrites reach compression ratios of about 0.03; and a question-asking protocol reaches 0.0006–0.004 [S-1508]. An earlier proposal reports compression below 1 bit per token by arithmetic coding against a weaker reference model [S-1509].
Sources: [S-0019] Verifying AI Compute by Bounding Unexplained Information Exfiltration (2026) https://openreview.net/forum?id=qtgG5HZSsk; [S-0015] Verifying LLM Inference to Detect Model Weight Exfiltration (2025) https://arxiv.org/abs/2511.02620; [S-1507] Adversarial Entropy Inflation Against Gumbel-Based Inference Verification (2026) https://arxiv.org/abs/2608.23375; [S-1508] Haiku to Opus in Just 10 bits: LLMs Unlock Large Compression Gains (2026) https://arxiv.org/abs/2604.02343; [S-1509] Preventing model exfiltration with upload limits (2024) https://www.alignmentforum.org/posts/rf66R4YsrCHgWx9RG/preventing-model-exfiltration-with-upload-limits; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Chip location verification (M-0018, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1: the design is public and detailed, but the one reported prototype has a single published result, which cannot be checked. - R1 met: Brass and Aarne give a full design with adversary classes, attacks and cost estimates [S-1400]. Aarne, Fist and Withers describe landmark-based verification [S-0056], and Avellar and Grunewald set out how a regulator could run it [S-1402]. - R2 not met: the IAPS brief reports a rudimentary H100 prototype and points to a video demonstration [S-1401]. It shows a single result, a Singapore landmark bounding a chip in Singapore to within 300 miles, but gives no systematic measurements, error rates or code [S-1401]. Claimed results that cannot be checked do not count. NVIDIA's delay-based scheme, reported by Avellar and Grunewald [S-1402], has no published design or results. Tee and Happel publish reproducible results for GPU fingerprinting, which is a component, not end-to-end location verification [S-1403]. The most mature implementation for this use, the draft Sovereignty Certificates specification (Lucid sovereignty (location) certificates), is itself R1 [S-1404]. Confidence is medium: if the prototype's demonstration website [S-1401] carries reproducible H100 measurements, R2 would be met.
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.
Location verification aims to show that an AI chip is where its owner says, or at least not in a restricted region. Trusted "landmark" servers at known places exchange cryptographic challenges with the chip, which signs its replies with a key unique to it. Signals cannot travel faster than light, so a fast reply caps the chip's distance from each landmark. A slow reply does not show that a chip is far away, because internet routes add delay. The designers estimate under $1 million for firmware and software, plus $2.5–12.5 million a year for 100–500 landmarks. A rudimentary H100 prototype is known only from a two-page brief and a demonstration website. NVIDIA is reportedly developing a version that uses its own servers. The main weaknesses are extraction of a chip's key, manipulated network delay and compromised landmarks. The check says nothing about chips in transit or how they are used.
## How it works

Chip location verification tries to establish where an AI chip physically is [S-1400]. Brass and Aarne judge delay-based methods, also called ping-based or latency-based verification, the most promising approach [S-1400]. A trusted "landmark" server at a known location sends the chip a cryptographic challenge, and the chip replies using a secret key unique to it [S-1400]. Signals cannot travel faster than light, so the reply time gives an upper bound on the chip's distance from the landmark [S-1400] [S-0056]. Measurements from several landmarks narrow the region where the chip can be [S-1404].

Brass and Aarne separate a general problem, locating a chip anywhere, from a narrower anti-smuggling problem: checking only that a chip is not in a restricted location [S-1400]. They recommend solving the narrower problem first [S-1400]. Aarne, Fist and Withers illustrate it with a trusted server in Paris [S-0056]. A reply in under 9 ms would show that a chip lies inside a circle that excludes countries to which exports are restricted [S-0056].

Estimates of the landmark network differ:

- Brass and Aarne's 2024 report suggests several dozen landmarks at most [S-1400].
- An IAPS issue brief from 2025, summarising that report, assumes 100 to 500, depending on which countries are included [S-1401].
- Aarne, Fist and Withers expect hundreds worldwide [S-0056].

For export control, Avellar and Grunewald place landmark servers in or near major data-centre hubs [S-1402]. The regulator would periodically ask exporters or end users to have chips ping the nearest landmark [S-1402].

The chip's key must stay secret [S-1400]. Brass and Aarne write that per-chip keys would need secure storage, such as a TPM, and that the trusted execution environment on NVIDIA H100 GPUs "could likely be used to implement location attestation" [S-1400]. A draft industry specification, Lucid sovereignty (location) certificates, packages the approach as a remote-attestation protocol that issues short-lived location certificates [S-1404]. In it, an attester inside a trusted execution environment probes anchor servers and the verifier computes the feasible region [S-1404]. Related timing-based checks appear in Timed challenge-response and memory-occupation challenges.

## What it establishes
What a timed reply can show:

- **An upper bound on distance.** A reply with one-way delay T ms shows that a device holding the chip's key was at most T × 200 km from the landmark at that moment, if signals travel no faster than light in fibre [S-1400].
- **Absence from a region.** For the anti-smuggling problem, a fast enough reply to a landmark outside restricted regions shows that the chip is not in those regions [S-0056] [S-1400].
- **Resistance to added delay.** Detours and tunnels add latency, so they generally cannot make a device appear closer to a landmark than it is [S-1404]. A path faster than the signal speed the verifier assumes can [S-1400].

What it cannot show:

- **Distance from a slow reply.** Internet traffic does not travel in straight lines, so an honest chip near a landmark may reply too slowly to be cleared [S-1400]. Under a hard time limit, a slow reply only means the chip cannot be ruled out of a restricted location [S-1400].
- **A precise position.** Delay-based methods give positions to within about 10 km to 1,000 km, depending on the algorithm [S-1400].
- **The chip itself.** The check binds the reply to whatever holds the key; an extracted key lets another device answer [S-1403].
- **Location between checks.** It shows nothing about where chips were between checks, and gives little visibility during shipping and warehousing [S-1402].
- **Who uses the chips, or for what.** Avellar and Grunewald treat end-location, end-user and end-use verification as separate problems [S-1402].

Brass and Aarne suggest combining location checks with a centralized chip registry (Chip registries and manufacturing records) [S-1400].

## Threat model
Brass and Aarne define three adversary classes [S-1400]:

- **Minimally adversarial** actors spend little and are very averse to discovery.
- **Covertly adversarial** actors spend substantial resources but still want to avoid being caught.
- **Openly adversarial** actors spend heavily and do not mind being discovered.

They argue that even an imperfect scheme has value, because it can occasionally catch cheaters and deter minimally adversarial actors [S-1400].

The scheme assumes the following:

- **Chip keys stay secret.** Each chip's key is provisioned and stored so that the owner cannot extract it [S-1400]. Tee and Happel question this against adversaries with physical access [S-1403].
- **Signals are no faster than assumed.** The bound holds only if no path beats the signal speed the verifier uses: the speed of light in fibre, or in a vacuum for a limit that cannot be beaten [S-1400].
- **Landmarks are trustworthy.** Landmarks are honest and correctly located [S-1400]. The draft specification requires a signed directory of anchors and keys protected in hardware security modules [S-1404].
- **The chip hardware is trusted.** The draft specification lets the attacker control the network and the host's root account, but trusts the hardware root of trust and TEE, and leaves sophisticated physical attacks as a residual risk [S-1404].

## Evidence
- **Prototype.** An IAPS issue brief from May 2025, which summarises Brass and Aarne's 2024 report, states that a rudimentary version has been prototyped on NVIDIA H100 chips [S-1401]. It does not say who built the prototype. It shows one result, a landmark in Singapore verifying that a chip in Singapore is within 300 miles of Singapore, and points to a video demonstration on a website [S-1401].
- **NVIDIA.** Avellar and Grunewald report, citing Reuters reporting from December 2025, that NVIDIA has confirmed it is developing location verification that estimates a chip's location from communication delays with NVIDIA-run servers [S-1402]. NVIDIA's own announcement from that month describes an opt-in fleet-management service that customers install and that reports read-only telemetry, with a client agent slated to be open-sourced [S-1413]. The announcement states that NVIDIA GPUs do not have hardware tracking technology, kill switches or backdoors [S-1413].
- **Costs.** The 2024 report estimates that a solution would cost less than $1 million to set up and maintain for several years [S-1400]. The 2025 brief puts the chip firmware and software update at under $1 million, and 100 to 500 landmarks at $25,000 each a year, or $2.5 million to $12.5 million a year [S-1401]. Avellar and Grunewald repeat the brief's figures [S-1402].
- **Ratings.** Ansari rates software-based delay methods as near-term and hardware-integrated, tamper-resistant versions as needing R&D [S-0007]. Avellar and Grunewald rate delay-based location verification as novel in maturity, high in effectiveness and not invasive [S-1402].
- **Component result.** Tee and Happel's GPU fingerprinting re-identified 24 rented H200 GPUs with 98.8% accuracy from a single run [S-1403]. It tests chip identification, not location [S-1403].
- **Specification.** The Sovereignty Certificates specification (Lucid sovereignty (location) certificates) is a draft, version 0.1.0, dated 2025-10-21 [S-1404]. As of September 2026 its repository holds no reference implementation [S-1404].

## Limitations
- **Delay inflation.** Added delay moved estimated positions by up to 1,000 km in research Brass and Aarne cite; they propose a hard time limit as the counter [S-1400].
- **Faster paths.** Dark fibre and other private high-speed links can lower measured delays artificially [S-1400] [S-1402].
- **False negatives.** A limit set at the vacuum speed of light cannot be beaten, but honest chips may often fail it [S-1400].
- **Landmark compromise.** Manipulating a third of the landmarks shifted estimates by about 700 km in cited research [S-1400], and compromised landmarks can spoof measurements directly [S-1402].
- **Key extraction.** An extracted key breaks the link between reply and chip [S-1403]. Ansari lists glitching and focused-ion-beam editing among physical attacks on embedded mechanisms [S-0007].
- **Tunnelling.** The draft specification argues that tunnels add latency and produce inconsistent geometry, and requires rejecting such results [S-1404].
- **Coverage gaps.** Chips in transit or storage cannot be checked [S-1402].
Technical detail: Brass and Aarne give the distance bound as D = T × 200, where D is the maximum distance in km and T the one-way delay in ms, taking about 200,000 km/s as the speed of light in optical fibre [S-1400]. In their case study, a 4.665 ms one-way delay bounds the chip to within 933 km of the landmark [S-1400]. They note that a limit based on the vacuum speed of light, about 300,000 km/s, covers worst cases such as out-of-band radio or satellite links and cannot be beaten physically [S-1400]. The cost is more false negatives: honest chips near a landmark may not reply fast enough, which the authors' moderate experimentation suggested could happen "perhaps even in more than 50% of cases" [S-1400]. Calibrating landmark delay factors might reduce this rate but needs further work [S-1400]. Recent geolocation algorithms reach a median error under 10 km given excellent landmark distribution and coverage; delay-based methods in general give about 10 km to 1,000 km, depending on the algorithm [S-1400]. The Sovereignty Certificates draft (Lucid sovereignty (location) certificates) casts the protocol as a RATS (RFC 9334) attestation flow with Entity Attestation Token (RFC 9711) claims [S-1404]. The verifier issues a nonce and a signed directory of anchors. The attester probes anchors from inside a TEE, and each anchor returns a signed receipt with a high-precision timestamp and a nonce. The verifier then runs a deterministic multilateration to compute a feasible region [S-1404]. Per-cycle ephemeral keys are bound into the hardware root of trust's attestation quote to prevent replay [S-1404]. Tee and Happel propose identifying a GPU by a hardware fingerprint instead of an extractable on-chip key. Their proof of concept races atomic operations across streaming multiprocessors [S-1403]. Over 480 runs on 24 NVIDIA H200 GPUs rented from a cloud provider, re-identification accuracy was 98.8% from a single run and 100% from paired runs, with each run taking about 2.9 s [S-1403]. The authors state that the fingerprint still has to be validated on more GPUs, shown to be stable over time and conditions, and shown to resist an adversary who runs the function faster or simulates the GPU [S-1403].
Sources: [S-1400] Location Verification for AI Chips (2024) https://www.iaps.ai/research/location-verification-for-ai-chips; [S-1401] Location Verification for AI Chips (issue brief) (2025) https://static1.squarespace.com/static/64edf8e7f2b10d716b5ba0e1/t/6827b67275666f3757f134ea/1747433075281/Location+Verification+two-pager.pdf; [S-1402] Near-Term Verification Methods for AI Chip Exports (2026) https://arxiv.org/abs/2609.07637; [S-1413] Opt-In NVIDIA Software Enables Data Center Fleet Management (2025) https://blogs.nvidia.com/blog/optional-data-center-fleet-management-software/; [S-0056] Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing (2024) https://www.cnas.org/publications/reports/secure-governable-chips; [S-0007] Hardware-Level Governance of AI Compute: A Feasibility Taxonomy for Regulatory Compliance and Treaty Verification (2026) https://arxiv.org/abs/2604.04712; [S-1403] GPU Fingerprinting for Location Verification (2026) https://arxiv.org/abs/2605.01930; [S-1404] Sovereignty Certificates: draft specification, version 0.1.0 (2025) https://github.com/Lucid-Computing/sovereignty-certificate-specification

## Chip registries and manufacturing records (M-0019, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1: registry and record-commitment designs are public, but none has been built or tested. - R1 met: Baker et al. describe an AI chip registry for ownership declarations, with sampled chain-of-custody checks from manufacture to destruction, and state the goal and assumptions [S-0002]. Avellar and Grunewald describe how a regulator could run a registry of chip ownership and use it for random return requests [S-1402]. Cankaya proposes cryptographic commitments to foundry chip-ID records [S-1408]. - R2 not met: as of September 2026 no AI chip registry or manufacturing-record commitment has a public implementation, and no end-to-end results have been published [S-0002] [S-1402] [S-1408]. Export documentation checks are established practice, but they are not a registry, and Avellar and Grunewald rate them low in effectiveness as a verification tool [S-1402]. Ansari rates registry systems as near-term, not deployable now [S-0007].
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.
A chip registry records unique identifiers for AI chips, with their owners and sometimes their locations, from manufacture to destruction. A verifier can then sample chips and check that declared chains of custody match what is physically there. A related proposal protects the foundry's own record of chip IDs by publishing a cryptographic fingerprint of it, so that later changes would show. As of September 2026 these are published designs, and no AI chip registry or record commitment is in operation. The main obstacle is institutional: someone must run the registry, and covering re-exports needs cooperation from re-exporters and foreign governments. The main weaknesses are that records cover only chips that were recorded, that documents and serial numbers can be forged, and that a commitment cannot show the records were accurate when made. A commitment shows what was made, not where it went.
## How it works

A chip registry records unique identifiers for AI chips, together with their owners and, in some designs, their locations [S-0002]. The aim is to account for chips over their lifetime [S-0002] [S-0007]. Baker et al. describe an AI chip registry as one possible way to report who owns AI compute [S-0002]. They note that declaring individual chips is not strictly necessary but makes verification easier [S-0002]. A verifier could check the locations and owners of random samples of chips, from manufacture to destruction, using inspections, possibly video cameras, and hard-to-spoof unique IDs [S-0002].

Ansari describes lifecycle registries as a chain-of-custody layer similar to nuclear material accountancy [S-0007]. He cites proposals to identify chips with physical unclonable functions and to serialize them on a blockchain [S-0007]. Aarne, Fist and Withers write that on-chip governance mechanisms would need a way to track who owns data-centre AI chips, supported by supply-chain tracking and Know Your Customer policies [S-0056].

In an export-control setting, Avellar and Grunewald describe a centralized registry of chip ownership [S-1402]. The regulator could pick random chip IDs from it and ask the owners to return those chips at short notice [S-1402]. During on-site inspections, inspectors would check the serial numbers of a random sample of chips against asset inventories and the records reported to the regulator [S-1402].

**Manufacturing records.** Cankaya argues that the foundry already holds a "golden record" of the AI chips it has made [S-1408]. He writes that modern processors carry Electronic Chip IDs (ECIDs), burned into one-time-programmable fuses at wafer test, that encode the wafer lot, the wafer number and the die position [S-1408]. He proposes that the foundry build a Merkle tree over these IDs and publish only its root hash after each batch [S-1408]. Later tampering would then be detectable, while the IDs themselves stay private [S-1408]. An inspector could later read a chip's ECID through its test access port without opening the package [S-1408].

**Upstream audits.** Halstead and Larsen propose auditing the semiconductor supply chain upstream, across logic fabrication, memory and packaging suppliers [S-1410]. This would give a record of past production that is hard to under-report without creating inconsistencies [S-1410].

## What it establishes
What these tools can show:

- **Custody matches declarations.** A registry, with sampled inspections, tests whether declared chains of custody match what is physically present [S-0002] [S-1402].
- **No undeclared clusters of recorded chips.** It supports the wider goal of checking that large quantities of chips have not been assembled into undeclared clusters [S-0002].
- **Records were not changed later.** A published commitment makes later changes to foundry records detectable [S-1408].

What they cannot show:

- **Unrecorded chips.** Chips that were never recorded are not covered [S-1408].
- **Where chips went.** Cankaya notes that a commitment shows what was made, and that "the harder question is where it went" [S-1408].
- **Accuracy at the start.** A commitment cannot show that the records were correct when committed [S-1408].
- **Strong assurance from documents alone.** Avellar and Grunewald rate export documentation checks low in effectiveness and useful mainly against actors of low to moderate sophistication [S-1402].

Brass and Aarne suggest pairing a registry with location verification (Chip location verification) [S-1400].

## Threat model
These designs trust some parties:

- **Owners** declare truthfully, or are caught by sampled inspections [S-0002].
- **Foundries** keep accurate ID records; Cankaya's proposal assumes the foundry holds the ECID data [S-1408].
- **IDs** are hard to alter [S-0002]. Cankaya argues that a blown fuse cannot be restored, and that changing it would need focused-ion-beam work that leaves detectable traces [S-1408].

The main threats named in the sources are forged documents and serial numbers [S-1402], opaque corporate structures [S-1402] and insiders altering production records [S-1408]. Ansari argues that the concentration of advanced manufacturing, with fewer than two dozen facilities making sub-14 nm chips as of 2023, makes a registry easier to enforce than for a commodity with distributed production [S-0007].

## Evidence
- **Designs only.** Baker et al., Avellar and Grunewald, and Cankaya publish designs; none reports an implementation [S-0002] [S-1402] [S-1408].
- **Feasibility ratings.** Ansari rates registry systems as near-term [S-0007]. He rates trade-data analysis as deployable now, citing work that uses existing customs data to find circumvention patterns [S-0007].
- **Export-control ratings.** Avellar and Grunewald rate export documentation checks as relatively established but low in effectiveness, and random return requests from a registry as novel and high in effectiveness [S-1402].

## Limitations
- **Unrecorded chips.** Chips outside the record are not covered, and a fraudulent original record would mean unregistered chips were made in advance [S-1408]. Reconstructing earlier production depends on supplier records [S-1410].
- **Forgery.** Documents can be forged, and serial numbers on chips and racks may be forgeable [S-1402].
- **Insider tampering.** Records can be altered before they are committed [S-1408].
- **Limited reach.** Covering re-exports would need cooperation from re-exporters and foreign governments, which may not be feasible everywhere [S-1402].
- **Custody versus location.** A commitment fixes what was made, but tracking where chips are needs inspections or location checks [S-1408] [S-0002].
Sources: [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-1402] Near-Term Verification Methods for AI Chip Exports (2026) https://arxiv.org/abs/2609.07637; [S-1408] TSMC most definitely has a golden record of all AI chips it made (2025) https://nacicankaya.substack.com/p/tsmc-most-definitely-has-a-golden; [S-0056] Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing (2024) https://www.cnas.org/publications/reports/secure-governable-chips; [S-0007] Hardware-Level Governance of AI Compute: A Feasibility Taxonomy for Regulatory Compliance and Treaty Verification (2026) https://arxiv.org/abs/2604.04712; [S-1410] Covert AI Projects (2026) https://ai-2040.com/supplements/covert-ai-projects; [S-1400] Location Verification for AI Chips (2024) https://www.iaps.ai/research/location-verification-for-ai-chips

## Confidential multi-party verification (M-0025, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2: open-source and peer-reviewed prototypes work on production enclaves and small models, but none is relied on or independently evaluated. - R1 met: designs that state what is verified and what is trusted are published for TEE workflows [S-0011] [S-1505] and zero-knowledge audits [S-0022]. - R2 met. Cove has an open-source reference implementation on Intel TDX via Phala Cloud's dstack, and its authors report an end-to-end attested confidential benchmark workflow on that production enclave platform [S-0011] [S-1505]. ZkAudit reports peer-reviewed end-to-end audits of MobileNet image classifiers and a recommender model [S-0022]. Attestable Audits ran safety benchmarks on an 8-billion-parameter model in AWS Nitro Enclaves [S-0009]. - R3 not met. Criterion (a) fails: no party other than a developer is documented as relying on these systems for a verification decision, and they are research prototypes. Criterion (b) fails: no independent audit or red-team of Cove, Attestable Audits or ZkAudit has been published. An independent analysis of one monitoring tool's published evaluation found that its one-bit verdicts leak information [S-1506]. Confidence is medium: prototypes exist, but at small model scales or on CPU-only enclaves [S-0009] [S-0022].
Lets mutually distrusting parties run an agreed check over private models or records inside attested enclaves or zero-knowledge proofs, revealing only the result.
Many verification questions involve assets that their owners will not show anyone, such as a developer's model weights, an auditor's test data or users' logs. Confidential multi-party verification runs the agreed check where no participant can see the others' inputs, either inside hardware-isolated enclaves that sign what code ran or with zero-knowledge proofs. Only the result is released, with evidence of how it was produced. Research prototypes compose multi-step audit workflows on commercial enclaves, run safety benchmarks without revealing the model or test data, limit usage monitoring to a jointly signed plan, and prove audits of small models with zero-knowledge proofs. As of September 2026 none is documented as relied on for a verification decision, and none has been independently red-teamed. The main obstacles are the limited scale of enclaves and proof systems, and trust in hardware vendors. Even a one-bit verdict can leak information about the private inputs.
## How it works

Audits often need sensitive artifacts, such as model weights and evaluation data, held by parties who do not trust each other [S-0011]. Model providers have business reasons to keep models and data secret, while society needs algorithmic transparency [S-0022]. Confidential multi-party verification moves the agreed check to a place where no single party sees the others' inputs [S-0011] [S-0022].

- **Composable enclave workflows.** Cove uses trusted execution environments (TEEs) to compose reusable multi-stage audit workflows [S-0011]. In its developers' design, each data owner encrypts its artifact locally and approves only specific, hashed workflow steps [S-1505]. A key is released only to an enclave whose attestation matches an approved step [S-1505]. Each step emits a certificate that the hardware binds to its code and outputs, and a verifier checks the whole chain, starting from the final certificate [S-1505].
- **Enclave-run audits.** In Attestable Audits, the model provider and the auditor each encrypt their inputs to an enclave key [S-0009]. The enclave runs the benchmark and publishes to a transparency log an attestation that binds the model hash, the hash of the audit code and data, and the result [S-0009].
- **Plan-scoped monitoring.** A monitoring party and a monitored party co-sign a plan, which an open-source classifier runs inside an attested TEE; scope changes need fresh signatures from both parties [S-1503]. The plan fixes the inputs, the computation steps and the outputs to be released [S-1504].
- **Zero-knowledge audits.** In ZkAudit, a provider publishes cryptographic commitments to its dataset and weights, plus a zero-knowledge proof that the weights came from training on that data [S-0022]. It then answers audit requests by computing a function privately and releasing the output with a proof that the computation was correct [S-0022].
- **Designing what is disclosed.** Minimal Information Disclosure treats the content of the released evidence as a design choice, and aims to minimize what the evidence reveals beyond the authorized result [S-1506].

## What it establishes
It can establish:

- that an agreed computation ran on committed or attested inputs and produced the released result, without revealing the inputs [S-0022] [S-1505];
- in Attestable Audits, that the model answering a user is the one that was audited [S-0009].

It cannot establish:

- that nothing was left out of the workflow, since auditors also need assurance that all activity is accounted for [S-0014];
- that the released result reveals nothing else: in one analysis, a one-bit verdict let a predictor tell which of two groups a private request came from with 72.4% balanced accuracy, against 50% by chance [S-1506];
- in ZkAudit, secrecy of the model architecture, which the proofs reveal [S-0022].

## Threat model
- **Cove.** Its developers state that it trusts Intel TDX and its attestation roots, Docker's enforcement of the generated configuration, pinned first-party components, and public source code with human review [S-1505]. It does not trust its own storage server, network routing or orchestration [S-1505].
- **Attestable Audits.** All parties must trust the vendor of the confidential-computing technology, which was AWS in the prototype [S-0009].
- **ZkAudit.** It rests on cryptographic assumptions, including binding and hiding commitments [S-0022].
- **Treaty setting.** A governance analysis contrasts the confidential-computing adversary, a dishonest operator, with the adversary in a treaty setting: a state with physical access to data centres and leverage over hardware vendors [S-0014].

## Evidence
- **Cove.** Its authors show how its primitives express three applications: capability-attested inference, attested confidential benchmarks and bilateral capability verification [S-0011]. They report an open-source reference implementation on Intel TDX via Phala Cloud's dstack, demonstrated end to end on the benchmark workflow only [S-0011] [S-1505].
- **Attestable Audits.** The authors ran MMLU, XSum and ToxicChat on a 4-bit Llama-3.1-8B model in CPU-only AWS Nitro Enclaves [S-0009]. They report that CPU inference cost 21.7 times as much per token as GPU inference and ran about 100 times slower [S-0009].
- **ZkAudit.** Peer-reviewed at ICML 2024 [S-0022]. The authors audited MobileNet v2 image classifiers on three datasets, with accuracy 0.5–0.7 percentage points below full precision, and a small recommender whose error matched full precision [S-0022].
- **Auditor-in-a-Box.** A reference implementation runs in Tinfoil confidential virtual machines [S-1504]. Its authors state that user data and plan execution in the demo are not actually secure, and that it has not been stress-tested by a counterparty [S-1504].

## Limitations
- **Verdict leakage.** Abdelghafar and Kulp found that one-bit reports can reveal sensitive attributes [S-1506]. They propose designing the evidence itself to limit this [S-1506].
- **Physical attacks on TEEs.** Researchers interposing on the memory bus extracted a per-CPU Intel attestation key and forged TDX attestations [S-1202]. Other attacks forged AMD SEV-SNP attestations, one through a DDR4 interposer and one from software alone before AMD's fix [S-1210] [S-1212].
- **Stack trust.** Compromise of the Docker daemon, host kernel or TEE stack breaks Cove's guarantees [S-1505].
- **Scale.** Frontier model inference typically needs the resources of several GPUs [S-0014], and ZkAudit was shown on image classifiers and a recommender model, not frontier-scale language models [S-0022].
- **Process.** Plan negotiation, false positives and appeals remain open problems [S-1504].

For attesting that a declared safeguard ran on a single service, see Safeguard attestation.
Technical detail: - Cove object model. An artifact is a unit of private data with exactly one owner, encrypted locally before upload. A workflow is a directed acyclic graph with a canonical serialization, and its hash names the bundle. Compilation to per-node manifests is deterministic, and the manifest hash is the node's identity. Owners record allow rules that bind each artifact to approved manifest hashes [S-1505]. - Cove run and verification. At run time a node fetches and verifies upstream certificates, evaluates preconditions, obtains decryption keys only after attestation, runs the workload and emits a certificate whose TEE report data commits to the certificate-body hash. Report data is two SHA-256 hashes, of a fixed label and of a canonical payload. Verifiers start from a terminal certificate, the workflow bytes and the TEE vendor's roots, and check each certificate recursively [S-1505]. - ZkAudit. The provider publishes commitments to its dataset and weights, with a zero-knowledge proof that the committed weights result from training. It then answers each audit request by computing a function F privately and releasing F's output with a second proof [S-0022]. A copyright or demographic audit of a MobileNet v2 model on Flowers-102 cost $108 in total (about 10 cents per image), and a counterfactual audit of a recommender on MovieLens cost $8,456 [S-0022]. - Minimal Information Disclosure. It chooses the evidence mechanism to minimize the conditional mutual information between protected properties and the released evidence, subject to a floor on information about the authorized target. One variant proves a linear projection with a Groth16 zk-SNARK [S-1506].
Sources: [S-0011] Cove: Compositional Multi-Party Confidential Workflows for Verifiable AI Governance (2026) https://openreview.net/forum?id=t1dz06Vcee; [S-1505] Cove: Compositional Multi-Party Confidential Workflows for Verifiable AI Governance (reference implementation) (2026) https://github.com/covehub/cove; [S-0022] Trustless Audits without Revealing Data or Models (2024) https://proceedings.mlr.press/v235/waiwitlikhit24a.html; [S-0009] Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments (2025) https://arxiv.org/abs/2506.23706; [S-1503] Enabling Verifiably-Scoped Monitoring through Large Language Models and Trusted Compute (2026) https://icml.cc/virtual/2026/78630; [S-1504] Auditor-in-a-Box: Tools for Third-Party Auditing (2026) https://www.lesswrong.com/posts/uWYk7MM9hAf9GEbGe/auditor-in-a-box-tools-for-third-party-auditing; [S-1506] Privacy-Preserving AI Verification via Minimal Information Disclosure (2026) https://arxiv.org/abs/2608.02774; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance; [S-1202] TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (2026) https://tee.fail/; [S-1210] Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing (2026) https://batteringram.eu/; [S-1212] RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP (2025) https://rmpocalypse.github.io/; [S-1213] SEV-SNP RMP Initialization Vulnerability (AMD-SB-3020) (2025) https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3020.html

## Deterministic and bit-exact inference (M-0002, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2: public code reproduces dense LLM blocks bit for bit on realistic GPUs against a stated adversary, but no third party relies on exact replay and no independent evaluation exists. - R1 met: the verification claim, a covert-adversary threat model and the information a verifier needs are published [S-0020]. - R2 met: public code predicts dense LLM blocks bit for bit on A100, L40, L40S and H100 GPUs running unmodified vLLM and Hugging Face engines, against a stated adversary [S-0020]. Batch-invariant modes are public in vLLM (beta) and SGLang [S-1013] [S-1012], and batch invariance was shown on a 235-billion-parameter model [S-1009]. Exact CPU reproduction of GPU matrix multiplication is peer-reviewed [S-1010]. The only Implementation record for this mechanism, Low-trust AI compute verification system overview, is a proposed architecture assessed R1, so the level rests on these systems directly. - R3 not met: determinism modes are available in production engines, and one model developer reports using end-to-end deterministic kernels [S-1011], but no party other than a developer is documented relying on exact replay for a verification decision. As of September 2026 no independent audit, red-team or peer-reviewed security analysis of bit-exact verification has been published. Confidence is medium because the verification-specific evidence is one single-author preprint covering dense model blocks.
Making model inference reproducible bit for bit, so that a verifier's re-run must match the provider's output exactly rather than approximately.
Re-running the same AI model on the same input often gives slightly different numbers. Floating-point results depend on the order of operations, which shifts with batch size, hardware and software. This noise forces recomputation checks to accept approximate matches, which a cheating provider could exploit. Deterministic inference removes the noise in one of two ways: kernels whose results do not depend on batch size, or recording enough about the hardware and software for a verifier to reproduce every rounding error. vLLM and SGLang offer batch-invariant or deterministic modes, and a published software emulator predicts, bit for bit, the outputs of dense transformer blocks on four NVIDIA GPU models. The obstacles are the throughput cost of batch-invariant kernels, gaps in the emulator's coverage (mixture-of-experts models, one proprietary kernel family, non-NVIDIA GPUs), no independent security evaluation, and the provider's need to disclose its full configuration.
## How it works

Floating-point arithmetic is not associative, so the same sum computed in a different order can round differently [S-0017] [S-1009]. In LLM serving, the order changes with [S-0016]:

- batch size and kernel strategy, which depend on server load;
- GPU type, CUDA version and kernel implementations;
- in mixture-of-experts models, routing that depends on other tokens in the batch.

Thinking Machines Lab argues that the main reason inference endpoints are nondeterministic is that load, and so batch size, varies while kernels are not batch-invariant [S-1009]. The bit-exact work separates true nondeterminism, caused by atomic functions, from non-invariance: deterministic computation that follows different reduction trees [S-0020].

There are two routes to exact results:

- **Invariant kernels.** Kernels fix the reduction order for each output element whatever the batch size [S-1009]. vLLM offers a batch-invariant mode, currently in beta [S-1013], and SGLang offers a deterministic inference mode [S-1012]. DeepSeek reports end-to-end bitwise batch-invariant and deterministic kernels, built with the goal of bitwise alignment among its pre-training, post-training and inference pipelines [S-1011]. LLM-42 enforces determinism through scheduling, replaying candidate tokens under a fixed reduction schedule instead of rewriting kernels [S-1014].
- **Record and replay.** Stock engines already give deterministic outputs that a verifier can reproduce bit for bit, if the verifier knows the key factors and no atomic functions are called [S-0020]. The factors are the hardware model, exact weights, parallelism layout, software versions and the batch size of each forward pass [S-0018] [S-0020]. Software emulation removes the need for identical hardware [S-0020], and Hawkeye re-executes GPU matrix multiplications on a CPU without precision loss [S-1010].

For verification, exactness turns a recomputation check (Sampled inference recomputation) into a pass/fail test [S-0020]. Zero-knowledge proofs of inference need determinism as a precondition [S-0020], and packet-based schemes (Reproducible computation packets) need workloads to be reproducible [S-0067].

## What it establishes
Under exact replay, the accumulated rounding errors become an auditable signature of the software and hardware used [S-0020]. The bit-exact work names three attacks that exploit the tolerance of approximate checks: steganography, unreported changes to inference software, and covert computation in unreported batch elements [S-0020]. It argues that statistical schemes can bound the covert bandwidth these leave, but cannot close it [S-0020].

Determinism does not capture traffic or choose samples; those come from recording and sampling mechanisms such as Network taps and certifiers and Sampled inference recomputation [S-0015] [S-0067]. Batch-invariant kernels give identical results only while the model, inference implementation and device stay fixed [S-0016]. For varied inference stacks and mixed GPU types, DiFR's authors expect statistical verification to remain necessary [S-0016].

## Threat model
- **Adversary.** The bit-exact work targets covert adversaries, who comply with monitoring only when the chance of detection is high [S-0020].
- **Full disclosure.** Exact replay assumes the verifier learns every factor that affects the numerics [S-0020]. A reference architecture for low-trust verification lists the same replay metadata [S-0018]. Recording the batch size is described as negligible overhead for the prover [S-0020].
- **No atomic functions.** Backends must avoid atomic functions [S-0020].
- **Correct hardware model.** Cross-hardware emulation assumes the hardware's rounding, subnormal handling and accumulation order have been characterized correctly [S-1010] [S-0020].

## Evidence
- **Nondeterminism measured.** For 1,000 temperature-0 completions of one prompt on Qwen3-235B-A22B, Thinking Machines reports 80 unique outputs with default kernels [S-1009]. With batch-invariant kernels, all 1,000 were identical [S-1009].
- **Bit-exact emulation.** On Qwen3 4B blocks, the emulator reports zero BF16 differences for feed-forward blocks on A100, L40, L40S and H100 GPUs [S-0020]. It reports zero differences out of 71 million elements for FlashAttention-2 at 4,000 tokens [S-0020]. The paper received a best-paper award at the ICML 2026 TAIGR workshop, and its code is public [S-0020].
- **Matrix multiplication on CPU.** Hawkeye, peer-reviewed at MLSys 2026, reports 100% success replicating 4096 × 4096 matrix multiplications on Ampere, Hopper and Lovelace GPUs [S-1010].
- **Engines.** vLLM documents its batch-invariant mode [S-1013]. SGLang reports an average slowdown of 34.35% for its deterministic mode on FlashInfer and FlashAttention 3 backends [S-1012].
- **Without determinism.** In DiFR's tests with synchronized seeds, over 98% of tokens already match exactly between provider and verifier [S-0016].

## Limitations
- **Throughput.** In Thinking Machines' test on Qwen3-8B, vLLM's default took 26 s, the unoptimized deterministic build 55 s, and the build with an improved attention kernel 42 s [S-1009].
- **Coverage.** The emulator does not yet cover mixture-of-experts inference, non-NVIDIA GPUs, the proprietary nvjet kernel family on Hopper, or training [S-0020]. Hawkeye covers matrix multiplication only; attention and convolutions need further reverse engineering [S-1010]. As of its September 2025 post, SGLang supported deterministic inference only for dense models, and only with tensor parallelism across one or two GPUs [S-1012].
- **Residual nondeterminism.** Some integer de-quantization kernels use atomic additions and remain truly nondeterministic [S-0020].
- **Disclosure.** Replay requires exact weights and configuration details [S-0020].
- **Maturity.** Amodo rates a reproducible inference stack for verification as not started, and red-teaming of recomputation schemes as not started [S-1008].
Technical detail: Two routes lead to exact results. - Invariance. Kernels fix the reduction order for each output element regardless of batch size. Thinking Machines made RMSNorm, matrix multiplication and attention batch-invariant, the last with a fixed split size for the key-value dimension rather than a fixed number of splits [S-1009]. vLLM exposes this behind VLLMBATCHINVARIANT=1 on NVIDIA GPUs of compute capability 8.0 or higher, in beta [S-1013]. SGLang integrated batch-invariant attention for its FlashInfer, FlashAttention 3 and Triton backends [S-1012]. LLM-42 instead decodes on a non-deterministic fast path and replays candidate tokens under a fixed-shape reduction schedule, rolling back any that are inconsistent [S-1014]. - Record and replay. Stock engines are deterministic but not invariant. Outputs are bitwise reproducible if the verifier knows the hardware model, the exact deployed weights, the parallelism topology (separately for prefill and decode), software versions including custom kernels, and the batch size of each forward pass [S-0018] [S-0020]. Of these, only batch size changes during serving, and it costs one extra integer per forward pass to record [S-0020]. A software emulator reproduces the rounding of other GPU models by modelling tensor-core accumulation and kernel-specific reduction trees [S-0020]. Hawkeye reproduces tensor-core matrix multiplication exactly on a CPU for Ampere, Hopper and Ada Lovelace GPUs in FP16, BF16 and FP8 [S-1010]. With exact replay, verification is pass/fail, and the chance of catching at least one false output in k samples is 1 − (1 − p)^k for a false-output rate p [S-0020].
Sources: [S-0020] Bit-Exact AI Inference Verification Without Performance Tradeoffs (2026) https://arxiv.org/abs/2606.00279; [S-0015] Verifying LLM Inference to Detect Model Weight Exfiltration (2025) https://arxiv.org/abs/2511.02620; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0016] DiFR: Inference Verification Despite Nondeterminism (2025) https://arxiv.org/abs/2511.20621; [S-0017] Example Schemes for Verifying High-Stakes AI Agreements (2026) https://amododesign.com/notes/2026-06-23-verification-algorithms/; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-1008] AI 2040 Plan A — Verification SITREP (2026) https://amododesign.com/ai-verification/plan-a-sitrep/; [S-1009] Defeating Nondeterminism in LLM Inference (2025) https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/; [S-1010] Hawkeye: Reproducing GPU-Level Non-Determinism (2026) https://proceedings.mlsys.org/paper_files/paper/2026/hash/e217c271a57c365a246b0ad39e668ba8-Abstract-Conference.html; [S-1011] DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence (2026) https://arxiv.org/abs/2606.19348; [S-1012] Towards Deterministic Inference in SGLang and Reproducible RL Training (2025) https://www.lmsys.org/blog/2025-09-22-sglang-deterministic/; [S-1013] Batch Invariance (vLLM documentation) (2026) https://github.com/vllm-project/vllm/blob/main/docs/features/batch_invariance.md; [S-1014] LLM-42: Enabling Determinism in LLM Inference with Verified Speculation (2026) https://arxiv.org/abs/2601.17768

## Hardware performance throttling and licensing (M-0011, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1. The designs are published, but the only quantitative results are kernel-level simulations. Assessed for limits a verifier could rely on against an operator trying to bypass them. - R1 met: RAND and O'Gara et al. describe offline licensing, including its claims and threats [S-0057] [S-0006]. Ma et al. describe microarchitectural throttles with a stated adversary [S-0036]. The flexHEG reports describe license-gated operation [S-1204]. - R2 not met. The quantitative evidence is one cycle-accurate simulation of a modelled A100, at the level of kernels rather than end-to-end workloads [S-0036]. The paper announces no code or hardware release; code is not required, but the results are not end-to-end. The existing features that sources mention, thermal and power clock throttling and Intel On Demand feature licensing, were not built or evaluated for this use [S-0057] [S-0006]. No Implementation record realises this mechanism.
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.
Throttling mechanisms would let the hardware itself enforce limits on AI computation. One proposal is offline licensing: a chip runs at full speed only while it holds a valid license for a set amount of work. Another is a set of microarchitectural throttles that, when triggered, shrink L2 cache capacity, add cache latency, cap cache bandwidth or limit shared-memory access. A 2026 simulation of an NVIDIA A100 found that such throttles could cut the performance of large-language-model kernels by up to 80% at one-eighth of resource availability, at a cost of under about 10,000 flip-flops each. The results come from simulation, not real chips. For verification, throttling matters only if a verifier can confirm the limit is in place and cannot be bypassed. That depends on attestation, tamper resistance and a secure trigger or licensing path. RAND judges that anti-tamper protection would not be insurmountable for a determined, well-resourced adversary.
## How it works

Two families of throttling are proposed.

**Licensing.** Several designs gate performance on a license:

- **RAND's offline licensing.** A renewable license temporarily authorizes certain hardware features. Once the license is used up, the GPU refuses the relevant operations or runs them "at a much lower rate" [S-0057].
- **O'Gara et al.** They describe licenses as cryptographic keys that unlock "a specified amount of computational work". Throttling could limit one capability, such as memory transfers, or all of them, and meters would track the licensed quantities. They cite Intel On Demand, which unlocks chip features by license, as a commercial precedent [S-0006].
- **CNAS.** Its proposed security module would enforce up-to-date operating licenses, among other checks [S-0056].
- **flexHEG.** Devices would periodically need a license that sets a minimum firmware version [S-1204]. A guarantee processor could also block operations that would take a training run past a threshold [S-0035].

**Microarchitectural throttles.** Ma et al. add knobs that reduce L2 cache capacity, add L2 latency, cap L2 bandwidth or limit access to shared-memory ports. None of these knobs is visible to software [S-0036]. A trigger switches them on. It might come from an on-chip classifier or from an external trusted authority, provided the trigger path stays in the throttle's trust domain [S-0036].

Existing GPUs already throttle their clocks when power or thermal limits are exceeded, and users can set clock speeds through NVIDIA tools [S-0057].

## What it establishes
Throttling enforces a limit. It does not by itself produce evidence for a verifier. A verifier could rely on a cap only if the throttle state were attested (TEE remote attestation for AI workloads) and, for licenses denominated in work, securely metered (On-chip telemetry from timing, memory and performance counters) [S-0006]. With both in place, a cap could support claims about capacity (Compute stock is at most a declared amount) or about compute used in a license period (A training run stayed within declared limits).

Ma et al. find that memory-side knobs hit LLM kernels selectively, while disabling compute cores slows nearly every workload [S-0036]. The throttle does not detect intent. The authors call detection of misaligned behaviour "an active and orthogonal research problem" [S-0036].

## Threat model
The sources assume adversaries of different strength:

- **Ma et al.** The adversary may be an autonomous AI agent, a malicious human, or both. It may have broad operating-system access but cannot alter the on-chip hardware [S-0036].
- **RAND** considers actors up to states, with physical and non-physical attacks. It concludes that anti-tamper protection can raise costs and reveal tampering but is not insurmountable [S-0057].
- **CNAS** judges that existing on-chip features must be hardened before they can be relied on in adversarial settings [S-0056].

O'Gara et al. ask which quantities should be metered and how to do so securely [S-0006].

## Evidence
- **Ma et al.** They simulate an NVIDIA A100 in AccelSim on GEMM and attention kernels shaped like those of recent large models. Performance fell by up to 80% at one-eighth of resource availability, and settled 5–80K cycles after a throttle was applied. Each mechanism needs fewer than about 10K flip-flops. The paper announces no code or hardware release [S-0036].
- **Licensing designs.** RAND and O'Gara et al. present designs and open questions, not prototypes [S-0057] [S-0006].
- **Development effort.** CNAS estimates that adequate hardware security for on-chip mechanisms, particularly tamper evidence and tamper-proofing, could take as little as 18 months, and up to 4 years, of technical effort by leading firms [S-0056].

## Limitations
The weaknesses the sources recognize are:

- the security of the trigger or license path [S-0036] [S-0006];
- physical, firmware and supply-chain attacks on the enforcing hardware [S-0057];
- sensitivity that varies by architecture, including non-monotonic L2 behaviour [S-0036];
- workloads adapting to the throttle [S-0036].

Evaluation on newer architectures is left open [S-0036]. Secure boot and voltage-glitching risks for license-checking firmware are discussed under Hardware-enabled guarantees (flexHEG) and guarantee processors [S-1204].
Technical detail: - Knobs evaluated by Ma et al. L2 capacity through way masking, L2 latency through configurable request buffering, L2 bandwidth through credit-based rate limiting, and shared-memory port access through bank arbitration. None is exposed to a software-visible interface [S-0036]. - Setup. The simulator was AccelSim, configured as an NVIDIA A100, with utilization metrics validated on a real GPU with Nsight Compute. The workloads were CUTLASS StreamK GEMM kernels, for prefill (M=4096) and decode (M=128), and FlashAttention, with shapes from DeepSeek-V3, Llama-3-70B and Mixtral-8x7B, plus six non-LLM CUDA sample workloads [S-0036]. - Results. At one-eighth of resource availability, performance fell by up to 80% (L2 latency for decode; L2 associativity for prefill). After a throttle was applied, performance settled within about 5K cycles for shared-memory ports, 5–7K cycles for L2 response rate and about 80K cycles for L2 associativity. Each mechanism needs fewer than about 10K flip-flops [S-0036]. - Selectivity. Memory-side knobs affected LLM kernels selectively. Disabling compute cores degraded nearly every workload together [S-0036]. - Offline licensing (RAND). A secure message authenticated on the GPU might authorize, for example, 10^18 arithmetic operations, after which the GPU would fall back to 1% of full performance [S-0057].
Sources: [S-0036] Hardware Mechanisms to Dynamically Throttle AI Performance (2026) https://arxiv.org/abs/2607.18069; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-0006] Hardware-Enabled Mechanisms for Verifying Responsible AI Development (2025) https://arxiv.org/abs/2505.03742; [S-0056] Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing (2024) https://www.cnas.org/publications/reports/secure-governable-chips; [S-0035] Flexible Hardware-Enabled Guarantees for AI Compute (2025) https://arxiv.org/abs/2506.15093; [S-1204] Technical Options for Flexible Hardware-Enabled Guarantees (2025) https://arxiv.org/abs/2506.03409

## Hardware-enabled guarantees (flexHEG) and guarantee processors (M-0009, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1. The design is detailed, but nothing has been built or tested in public. - R1 met: the flexHEG series sets out the components, the claims that could be verified or enforced, the update governance and a threat model that includes state-level adversaries [S-0035] [S-1204] [S-1205]. RAND and CNAS describe related HEM designs and their threats [S-0057] [S-0056]. - R2 not met. As of September 2026 no public implementation or reproducible end-to-end results have been published, and no Implementation record realises this mechanism. Part II mentions that "an existing FlexHEG prototype" uses high-resolution power measurements, but gives no details or results [S-1204]. Claimed results that are not public do not count. Because that prototype could not be checked, confidence is medium rather than high.
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.
Hardware-enabled governance mechanisms (HEMs) are proposed chip features that would let a verifier check, or the chip itself enforce, rules about how AI compute is used. The flexHEG proposal pairs an open, auditable guarantee processor, which sees all data and instructions going to and from an accelerator, with a secure enclosure that reveals or responds to tampering. Rule changes, such as to a cap on training compute, could require approval from several parties. RAND and CNAS describe related designs, such as offline licensing. All are designs; the one prototype mentioned is unpublished. The main obstacles are physical security against state attackers, chipmaker cooperation, and international trust in chip design and manufacturing. The authors estimate that integrated hardware would take 3.7–7.9 years from the start of chipmaker work to displace other accelerators at the frontier. Whether a use is malicious cannot be checked on the chip.
## How it works

RAND defines hardware-enabled governance mechanisms (HEMs) as controls built into AI hardware that enable "enforcement and compliance verification" of policies [S-0057]. It analyses two designs [S-0057]:

- **Offline licensing** lets a GPU run a set amount of work under a renewable license, then refuse or slow further work.
- **The fixed set** limits high-bandwidth links to a small pod of pre-authorized chips.

CNAS proposes a hardened security module that enforces valid firmware and up-to-date operating licenses and supports remote attestation. It would be rolled out in stages, from firmware changes to tamper-evident and then tamper-proof hardware [S-0056]. An interdisciplinary workshop report by O'Gara et al. discusses HEMs for four uses: verifiable AI training and inference, verifiable cluster configuration, location verification and offline licensing [S-0006].

flexHEG (flexible hardware-enabled guarantees) combines two components [S-0035]:

- **Guarantee processor**: "an open-source, standardized, general-purpose processor that sits between the AI chip and the rest of the world". It can see all information and instructions going to and from the chip [S-0035].
- **Secure enclosure**: it houses the chip and the guarantee processor. If tampering is detected, secrets are wiped [S-0035].

When the guarantee processor sits directly on the data path, the design is called an **Interlock**. As the only way in, it can monitor or control the flow and encrypt data leaving the enclosure [S-1204]. The rules it applies form a **ruleset**, which anyone from the chip's owner alone up to "a quorum of states" might set [S-0035]. Changes could require k-of-n approval, and periodic licenses could force devices to stay current [S-1204].

Part II of the flexHEG series describes a range of implementations [S-1204]:

- **Integrated hardware**, built into the accelerator by its manufacturer.
- **Retrofits**, such as modified firmware or a replacement network interface card acting as the Interlock.
- **TEE-backed software**, which Part II judges relatively fast to deploy but probably not secure against sophisticated actors with unrestricted physical access.

Part III contrasts two kinds of agreement. In verification-based agreements, states detect violations and retaliate. In ruleset-based agreements, the devices enforce the rules and no state can rewrite them alone [S-1205].

## What it establishes
The authors list claims flexHEG could support [S-0035]:

- the total compute used to train a model;
- whether a model's score on an automated test stayed below, or rose above, an agreed level;
- deployment only to approved devices;
- a chip's approximate location;
- which architectures and training techniques were used.

A guarantee processor could also block any operation that would push a training run past a threshold [S-0035].

It cannot establish:

- **intent or downstream misuse**, which is not observable on the chip [S-0035];
- **whether a network is the whole system** or one expert in a larger one [S-0035];
- **a true FLOP count** if earlier results are hidden in external inputs [S-1204];
- **anything about compute without flexHEG hardware** [S-0035] [S-1205].

Fully automatic, on-device compliance checking "appears unlikely to be feasible" [S-0035]. Part III therefore discusses compromises that combine enforced rules with verification [S-1205].

## Threat model
In international use, "the primary attackers ... are the participating states themselves" [S-1205]. Devices would need to be open source, auditable and "robust to tampering even from state-level adversaries" [S-0035]. CNAS stresses that existing features "need to be hardened" before adversarial use [S-0056].

RAND defines three kinds of threat actor: unsubsidized commercial, state-subsidized commercial, and state. It groups attacks into four classes [S-0057]:

- **non-invasive**, for example side channels;
- **semi-invasive**, such as fault injection;
- **fully invasive**, such as focused ion beams and electron microscopy;
- **non-physical**, including design theft and cryptographic, firmware, supply-chain and resource-pooling attacks.

The design also assumes a trustworthy supply chain. Part III proposes manufacturing equipment locked to standard designs, independent testing, camera oversight, tamper-evident shipping, and extensive testing and detailed physical imaging of a random sample of finished devices [S-1205].

## Evidence
- **Design reports.** RAND and CNAS published design and analysis reports in 2024 [S-0057] [S-0056]. The three flexHEG parts followed in 2025, commissioned by ARIA [S-0035] [S-1204] [S-1205].
- **Timelines.** CNAS estimates that the needed hardware security could take as little as 18 months, and up to 4 years, of technical effort by leading firms [S-0056]. Part II estimates 3.7–7.9 years for integrated flexHEG to displace other accelerators at the frontier, counted from when a manufacturer starts work. It argues that to reach its full potential, flexHEG would likely need to be deployed at scale "by 2027 or sooner" [S-1204].
- **Prototype.** Part II says that "an existing FlexHEG prototype uses high resolution power measurements", with no further detail [S-1204].
- **Related work.** Part II notes TEE-based efforts by Mithril Security and EQTY Lab [S-1204].
- **Open questions.** O'Gara et al. ask how to verify license authenticity at scale and how to attest the integrity of fixed-set pods remotely [S-0006].

## Limitations
- **Enclosures.** The authors write that nation-state attackers "can likely compromise the best current secure enclosures" [S-1204].
- **Retrofits.** Designs that rely on Secure Boot are exposed to voltage glitching and probing [S-1204].
- **Supply chain.** Diversion and backdoors are open problems [S-1204] [S-1205].
- **Evaluations.** Making capability evaluations robust to models trained to underperform is "a very difficult open problem" [S-0035].
- **Algorithmic efficiency.** Gains lower the compute needed for a given capability over time [S-1205].

Physical protection is covered in Tamper evidence for verifier devices, interconnect limits in Bandwidth limits and compartmentalization and throttling in Hardware performance throttling and licensing.
Technical detail: - Interlock. A flexHEG component on the data path is called an Interlock. As the only path for data and instructions into the accelerator, it could monitor or control that flow and encrypt what leaves the enclosure. The candidate points are HBM, NVLink, PCIe and the cluster NIC [S-1204]. - Encryption cost. Part II roughly estimates that encrypting all NVLink traffic with AES-256-GCM would take about 3% of computing power, energy or board space, and encrypting all HBM traffic about 11% of power [S-1204]. - Checking and logging. Part II estimates that for a guarantee processor to double-check one streaming multiprocessor (SM) of a Blackwell chip would take roughly 1/192 of the chip's compute, assuming 192 SMs per chip [S-1204]. NVIDIA states that the Blackwell GPUs in its HGX B200 system normally have 148 SMs [S-1611]. Storing a FLOP log for 1M unique sources, such as a very large cluster, would take roughly 30 MB [S-1204]. - Updates. An update, or the lack of one, could require approval by k of n parties. Periodic licenses could specify a minimum firmware version, and signatures should ideally be quantum-resistant [S-1204]. A guarantee processor could be required to install a firmware update regularly, for example every three months, or it would block the chip [S-0035]. - Enclosure. Tamper evidence is sufficient for verification, while guarantees about future use need tamper response. Options include capacitor discharge or antifuses that disable the chip, PUF-derived keys, and sensors for radiation, voltage glitching, lasers and temperature [S-1204]. - Manufacturing oversight. Part III proposes extensive testing of a random sample, for example 1/1000 of finished devices, which would give a 63% chance of catching a batch of 1000 compromised devices at that stage [S-1205]. - RAND designs. An offline license might authorize 10^18 operations before the GPU falls back to 1% performance. A "fixed set" restricts high-bandwidth links to pre-authorized pods of fewer than 65 chips [S-0057].
Sources: [S-0035] Flexible Hardware-Enabled Guarantees for AI Compute (2025) https://arxiv.org/abs/2506.15093; [S-1204] Technical Options for Flexible Hardware-Enabled Guarantees (2025) https://arxiv.org/abs/2506.03409; [S-1611] Boost GPU Memory Performance with No Code Changes Using NVIDIA CUDA MPS (2025) https://developer.nvidia.com/blog/boost-gpu-memory-performance-with-no-code-changes-using-nvidia-cuda-mps/; [S-1205] International Security Applications of Flexible Hardware-Enabled Guarantees (2025) https://arxiv.org/abs/2506.15100; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-0056] Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing (2024) https://www.cnas.org/publications/reports/secure-governable-chips; [S-0006] Hardware-Enabled Mechanisms for Verifying Responsible AI Development (2025) https://arxiv.org/abs/2505.03742

## Memory wiping and proofs of secure erasure (M-0015, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, low confidence. R1: the protocols are peer-reviewed and the AI use is proposed, but no public run covers the timed challenge phase on data-centre hardware. - R1 met: the AI 2040 plan proposes periodic memory wipes on inference units so that only verified outputs persist [S-0067]. Peer-reviewed and preprint protocols define proofs of secure erasure and their assumptions [S-1304] [S-0032]. The MIRI overview specifies filling memory with incompressible data and challenging random samples [S-0018]. - R2 not clearly met: Amodo has run a Bursuc-style erasure on a Raspberry Pi 5 and benchmarked label generation on H200 and H100 GPUs, CPUs and NVMe drives [S-1302] [S-1303]. Its public code for the GPU-accelerated disk-wiping path runs on realistic hardware [S-1321]. But the repository excludes "the verifier, the RAM and GPU-HBM session code" [S-1321], the notes report fill throughput rather than timed challenge rounds [S-1302] [S-1303], and the GB200 figures are estimates scaled from component measurements [S-1302] [S-1303]. Bursuc et al. simulated a 32 KB erasure on a desktop computer [S-0032]. The mechanism's implementations, AI 2040 inference-only verification stack and Low-trust AI compute verification system overview, are proposed architectures at R1. Confidence is low because the public disk-wiping code on data-centre GPUs and drives could be read as meeting R2 in the hardware respect.
Overwriting all of a device's memory in a way a verifier can check, so that nothing from earlier, undeclared work survives the wipe.
Memory wiping overwrites a device's memory in a way a verifier can check, so nothing from earlier work survives. In AI verification, periodic wipes would help show that only verified outputs carry forward. The technique builds on proofs of secure erasure: the device fills its memory with data derived from a verifier's seed, then answers timed questions about it. The theory is peer-reviewed. Scaling from erasure runs on CPUs, GPUs and disks, Amodo estimates about 43 minutes to wipe the memory of one GB200 tray and about 2.5 hours for an NVL72 rack's storage. As of September 2026 no end-to-end wipe with timed challenges has been published for data-centre hardware. The main obstacles are wipe time and memory the wipe cannot reach, such as drive-controller DRAM. The largest known weakness is that the guarantee depends on ruling out outside help during challenges, which fast data-centre networks make harder.
## How it works

Proofs of secure erasure (PoSE), introduced by Perito and Tsudik for low-cost embedded devices, rely on the bounded memory of such devices [S-1304]. A verifier confirms that a device has erased its memory by having it fill that memory with data the verifier can check [S-0032]. Perito and Tsudik found this "particularly well-suited" to secure code update and to secure memory or storage erasure [S-1304].

A protocol has three phases [S-0032]:

1. **Fill.** The prover fills its memory. In the simplest version the verifier sends random data; in graph-based versions it sends a short seed, and the device computes a large set of hash-chained labels from it [S-0032].
2. **Challenge.** The verifier asks for randomly chosen blocks, several times, and times each answer [S-0032].
3. **Decide.** The verifier accepts only if every answer is correct and arrived within the time bound [S-0032].

The graph construction makes it slow to recompute any missing label, so a device that tried to keep other data must fail the deadline [S-0032] [S-1302].

In AI verification, the AI 2040 plan proposes "periodic memory wiping on the inference units (which we think can be done through forced memorization)" [S-0067]. The MIRI overview describes the same step: incompressible data is loaded until the device is full, and then random samples are challenged [S-0018]. Amodo generates the fill on the device from a verifier seed, following Bursuc et al. [S-1302].

## What it establishes
Amodo describes the goal as a verifier ensuring "the prover has fully overwritten its memory, with no information persisted across the wipe" [S-1302]. Amodo says wipes help to verify the "completeness" of declared workloads [S-1302]. In the AI 2040 plan they help ensure that the only persisting results are verified inference outputs [S-0067]; see This compute runs inference, not training.

Wipes limit what can carry over between verification cycles, not what runs between them. The AI 2040 plan therefore pairs them with network taps and partial recomputation (Network taps and certifiers, Sampled inference recomputation) [S-0067]. Amodo notes that all stores must be wiped at the same time, because otherwise "an attacker could simply move the data between the disks" [S-1302].

## Threat model
- **Bounded memory.** Perito and Tsudik assume bounded memory and a small read-only memory [S-1304].
- **Distant helpers.** Earlier software protocols assumed the device was isolated during the protocol [S-0032]. Bursuc et al. relax this: helpers may exist but must be far enough away that their round-trip times exceed the deadline [S-0032].
- **Round-trip time.** Amodo assumes a 1 ms round-trip time, "expected to be a safe overestimate" [S-1302].
- **No remote memory.** The MIRI overview says verification depends on ruling out remote memory access, "either via response latency or physical disconnection" [S-0018].

Timed challenges are covered in Timed challenge-response and memory-occupation challenges.

## Evidence
- **Protocols.** The core protocols are formally analysed [S-1304] [S-0032]. Bursuc et al. ran their prototype on a standard desktop computer and simulated the erasure of 32 KB, which took 0.25 seconds [S-0032].
- **First Amodo test.** Amodo ran the algorithm on a Raspberry Pi 5, erasing its RAM and a connected SSD [S-1302].
- **Amodo's July 2026 analysis.** Scaling measured GPU and CPU throughputs, with an assumed 1 ms round-trip time, gave 2,565 seconds (43 minutes) for the RAM and HBM of a GB200 tray [S-1302]. Drive writes slowed sharply after about 12 GiB, so Amodo estimated over 24 hours for a GB200 system with 15 TB of storage [S-1302]. Challenge-phase calculations were still to come [S-1302].
- **Amodo's September 2026 update.** Amodo attributed the slowdown to consumer drives' fast write cache running out [S-1303]. Six GPUs wiping one fast drive reached 6 minutes 41 seconds per TB [S-1303]. Amodo now expects "~2.5 hours to wipe an NVL72 system's storage", using a B200 label rate estimated from its GPU benchmarks, and reports that erasure speed, not drive speed, is the bottleneck [S-1303].
- **Public code.** Amodo has published code for the disk-wiping path, which fills every sector of an NVMe drive with graph labels generated on NVIDIA GPUs [S-1321]. The repository excludes the verifier and the RAM and GPU-HBM session code [S-1321].

## Limitations
- **Unreachable memory.** SSD controller DRAM sits on a private bus that host commands cannot access [S-1303]. Amodo's code notes that overwriting by logical block address cannot reach over-provisioned or remapped blocks either [S-1321]. The optimized algorithm's 25 GiB of working memory is "supposedly wiped but isn't attested" [S-1303]. Amodo lists many other stores in a GB200 system and asks how network-switch memory could be wiped [S-1302].
- **Outside help.** In data centres, remote memory round trips of about 1–2 µs compare with about 70–200 ns for local DRAM, which the MIRI overview puts at roughly a tenfold timing margin [S-0018]. Evasion by pre-staging data is closed only by unpredictable, capacity-filling challenges [S-0018].
- **Downtime.** Filling a pod's volatile memory takes tens of minutes, and SSDs take hours [S-0018].
- **Residual gap.** Memory between the erased region and full capacity could hold data [S-0032]. Bursuc et al. say that closing this gap needs future work [S-0032].
Technical detail: - Origin. Perito and Tsudik introduced proofs of secure erasure (PoSE) for embedded devices with bounded memory and a small ROM [S-1304]. - Bursuc et al.'s model. The adversary is a distant, memory-unbounded helper A0 and a local device A1 bounded to memory M. The protocol has an initialization phase (fill memory), r timed challenge-response rounds, and a verification phase that accepts only if the answers are correct and each round-trip time is at most Δ [S-0032]. - Variants. An unconditional variant fills memory with random bits sent by the verifier. A graph-based variant sends only a seed: the prover computes labels of a depth-robust graph with a hash function and stores the output labels, and a construction with in-place labelling needs only about the output size plus O(w) memory. A lightweight variant relaxes depth-robustness to a small constant for speed [S-0032]. - Prototype. Bursuc et al. ran their prototype on a standard desktop computer and simulated the erasure of 32 KB, which took 0.25 s; compiled for a 32-bit architecture, the program is 3.4 KB [S-0032]. - Amodo's implementation. It follows Bursuc et al.: node labels are L(n) = H(n ∥ L(p1) ∥ … ∥ L(pk)), only "robust" labels are stored and challengeable, and the scheme is secure if q < γ, where q is the number of hashes a cheater can compute within the round-trip time and γ is the minimum number of hashes needed to recompute a robust label [S-1302]. - Amodo's parameters and throughput. An assumed RTT of 1 ms; γ = 65,536 for host RAM and 32,768 for GPU HBM; Dual-AES-PRF on CPU and BLAKE3 on GPU. The measured throughputs, 126.3 MiB/s for 120 GB of RAM and 244.5 MiB/s for 140 GB of HBM, scale to 2,565 s for the memory sizes in a GB200 tray [S-1302]. - Disk path. A later optimization parallelized label generation across GPUs and reached 6 min 41 s per TB with 6 GPUs on one fast drive; it needs 25 GiB of working memory, which is left unattested if used on HBM [S-1303]. The NVL72 storage estimate assumes 30.72 TB of drives per tray and an estimated 840 MiB/s per B200 GPU, four GPUs per tray [S-1303]. Code for this path (CUDA graph labeller, multi-GPU disk-wipe benchmark with sample verification, wipe-time calculator) is public under the MIT licence [S-1321].
Sources: [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-1304] Secure Code Update for Embedded Devices via Proofs of Secure Erasure (2010) https://link.springer.com/chapter/10.1007/978-3-642-15497-3_39; [S-0032] Software-Based Memory Erasure with Relaxed Isolation Requirements (2024) https://ieeexplore.ieee.org/document/10664348/; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-1302] Memory Wipes - Performance Analysis (2026) https://amododesign.com/notes/2026-07-01-memory-wiping/; [S-1303] Improving Disk Wiping Speed for Memory Wipes (2026) https://amododesign.com/notes/2026-09-14-disk-wiping-speed/; [S-1321] Amodo-Design/PoSE-Memory-Wiping (GitHub repository) (2026) https://github.com/Amodo-Design/PoSE-Memory-Wiping

## Model identity attestation (M-0012, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2. Public code runs on production hardware, but the independent attacks published so far left flaws open, including a critical flaw in the trusted execution environments the enclave route relies on. - R1 met: designs and assumptions are published for both routes [S-0013] [S-0012] [S-0015]. - R2 met through Tinfoil's Modelwrap chain. Its code is open source [S-1209], it runs on NVIDIA H100, H200 or B200 GPUs with AMD SEV-SNP or Intel TDX (provider-reported) [S-1206], and it has been reported on models of up to 554 GB [S-0013]. Rinberg et al. publish code and results on models from 3B to 30B parameters [S-0015]. - R3 not met. Criterion (a) is met only on the provider's account: Tinfoil reports offering the feature in a production service [S-1207] [S-1208]. Criterion (b) fails, because the independent evaluations that exist left flaws open. TEE.fail used physical access to forge the Intel TDX attestation that the enclave route relies on. By pairing the forgeries with relayed H100 attestations, it made a vLLM proxy running outside TEE protection pass both the TDX and the NVIDIA confidential-computing checks [S-1202]. That flaw is critical and open. Kezins, at Delft University of Technology, attacked the exfiltration bound of Rinberg et al.'s recomputation check with chosen prompts. On a 30B mixture-of-experts model this raised leakage from 0.119 to 0.286 bits per token. The attack widens the covert channel and does not target the check that outputs match the declared model [S-1507].
Establishes that responses come from a specific, committed set of model weights, using enclave measurements or recomputation of sampled outputs.
Users, auditors and regulators often need to know that a provider is serving the model it declared, not a cheaper, altered or unevaluated one. There are two routes. First, the weights are committed to a hash, and the attestation from a trusted execution environment shows that the measured software enforced that commitment while the model ran. Second, a verifier that holds the declared weights recomputes a sample of logged outputs, which can also detect weights smuggled out in responses. Tinfoil reports running the enclave route in a commercial service, and its Modelwrap tool is open source. Research prototypes bind evaluations and inference to model hashes, and recomputation has been tested on models of up to 30 billion parameters. The enclave route inherits the weaknesses of TEEs, including published attacks that forge Intel TDX and AMD SEV-SNP attestations. Recomputation needs trusted logging and randomness, and must tolerate numerical nondeterminism.
## How it works

Two routes exist, and they can be combined.

### Commit and attest

This route runs inside a TEE (TEE remote attestation for AI workloads). It closes a gap: attestation "measures launch state, not runtime state", while weights are read from disk after boot [S-0013]. Three designs bind the weights to the attestation:

- **Tinfoil's Modelwrap** packs the weights into a read-only image and computes a Merkle-tree root hash. It places that hash on the kernel command line, which the enclave measurement covers, and the kernel's dm-verity layer checks every block read against it [S-0013]. Clients compare the attestation's measurements with values that Tinfoil's build pipeline publishes to the Sigstore transparency log [S-1207]. For a public model, anyone can rebuild the image from the same Hugging Face commit and compare root hashes [S-0013].
- **PAL\*M** puts hashes of each operation's inputs, including the model, and of its outputs into the Intel TDX report, for single prompts and multi-turn sessions [S-0012].
- **Attestable Audits** records the model hash when an audit runs. At inference time it checks that the served model matches, then returns each response with an attestation that links model, prompt, output and audit result [S-0009].

### Recompute and compare

This route uses sampled recomputation. A verifier that holds the declared weights scores logged outputs by the likelihood that each token was sampled from that model under a known seed. The estimators allow for legitimate numerical nondeterminism [S-0015]. Rinberg et al. frame the check as a way to catch weights hidden steganographically in responses, and it also shows whether outputs are consistent with the declared model [S-0015]. Deterministic inference is covered in Deterministic and bit-exact inference.

## What it establishes
The two routes establish different things:

- **Commit and attest** can show that the bytes served match a commitment [S-0013].
- **Recompute and compare** can show that logged outputs are consistent with the declared model's sampling procedure [S-0015].

Neither shows:

- **What a private model can do.** With unpublished weights, a user can confirm only that the same weights are served each time [S-0013]. An attested evaluation bound to the same hash can close part of that gap [S-0009].
- **Everything else that shapes behaviour.** Tinfoil measures the firmware, kernel, initrd and a configuration file as well as the weights [S-1207]. Gloria Z warns that unmeasured runtime flags can undermine integrity [S-0014].
- **Properties a weak hashing scheme leaves out.** Gloria Z also warns that a scheme that sequences values loosely, or checks the weights too early in loading, could let two models with significantly different properties share a hash "without breaking the hash function itself" [S-0014].

## Threat model
The enclave route trusts the hardware vendor and treats the host software as hostile. Tinfoil states "You trust the hardware manufacturer", but not the hypervisor or host OS [S-1206]. PAL\*M excludes side channels and physical attacks [S-0012].

The recomputation route assumes the following [S-0015]:

- the verification code is trusted;
- every input, output and seed is logged correctly;
- the attacker can neither predict nor manipulate which messages are sampled for verification;
- the verifier sees prompts and responses and holds the weights.

## Evidence
- **Tinfoil.** Modelwrap is published under an MIT license [S-1209]. Tinfoil reports a storage overhead of 0.8%, build times of up to 13 min 25 s for a 554 GB model, and slower cold loading but no inference slowdown [S-0013].
- **PAL\*M.** It reports inference attestation on an H100 across three models, with total observed overhead of 3.8–11.4% for multi-turn sessions and 45.5–66.4% for single prompts [S-0012].
- **Attestable Audits.** Its protocol binds inference to the audited model hash. The reported evaluation covers the audit step, for a 4-bit Llama-3.1-8B on CPU-only AWS Nitro Enclaves [S-0009].
- **Rinberg et al.** They tested Llama-3.1-8B, Llama-3.2-3B and two Qwen mixture-of-experts models, and publish their code. On the 30B model under benign prompt traffic, the detector cut exfiltratable information to under 0.5% at a false-positive rate under 0.01% [S-0015]. An independent study found that prompt control roughly doubles leakage per token [S-1507].

## Limitations
- **Inherited TEE attacks.** Using physical access, TEE.fail forged Intel TDX attestations and, by pairing them with relayed H100 attestations, passed a workload outside TEE protection [S-1202]. Battering RAM and RMPocalypse forged AMD SEV-SNP attestations, the second without physical access [S-1210] [S-1212]. Tinfoil's documentation acknowledges physical-access and side-channel risks [S-1206].
- **Audit-time checking.** Tinfoil does not provide a supported tool for querying its transparency records at audit time [S-1208].
- **Recomputation slack.** Nondeterminism concentrates at a few token positions, and very slow leaks remain possible [S-0015]. An adversary who controls prompts widens the leak [S-1507].
- **Recomputation dependencies.** The check depends on complete and trusted logging, and on the verifier holding the weights [S-0015].
Technical detail: - Modelwrap build (Tinfoil's description). The tool downloads a pinned model revision, normalizes its directory structure and builds an EROFS image. It computes a dm-verity root hash with veritysetup. The Merkle tree gives a 32-byte commitment to, for example, 140 GB of weights [S-0013]. - Binding and enforcement. The root hash is passed on the kernel command line, which the enclave measurement covers. dm-verity then checks every block read against it and returns an error on any mismatch [S-0013]. - Reported costs. Tinfoil reports a hash-tree overhead of about 0.8% of image size, and build times from 5 s for a 549 MB model to 13 min 25 s for a 554 GB model. Cold-cache loading takes about 80% longer, and inference is unaffected once the weights are in GPU memory [S-0013]. - PALM inference attestation. PALM sets the Intel TDX REPORTDATA field to the concatenation of the operation, a challenge, and hashes of the inputs and outputs. It supports single-prompt and multi-turn inference attestations. Across three models on an H100, total observed overhead was 3.8–11.4% for multi-turn sessions and 45.5–66.4% for single prompts [S-0012]. - Fixed-seed sampling likelihood. Rinberg et al. score the likelihood that each token was honestly sampled from the claimed model under a known seed, with estimators for inverse-probability-transform and Gumbel-max samplers. On a 30B mixture-of-experts model under benign prompt traffic, the check limits exfiltratable information to under 0.5% at a false-positive rate under 0.01%, a slowdown of more than 200 times for the adversary [S-0015]. An independent study found that an adversary who controls the prompts roughly doubles leakage per token, reducing the slowdown to 60–118 times [S-1507].
Sources: [S-0013] How Tinfoil Proves Exactly What Model Is Running (2026) https://tinfoil.sh/blog/2026-02-03-proving-model-identity; [S-0012] PAL*M: Property Attestation for Large Generative Models (2026) https://arxiv.org/abs/2601.16199; [S-0009] Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments (2025) https://arxiv.org/abs/2506.23706; [S-0015] Verifying LLM Inference to Detect Model Weight Exfiltration (2025) https://arxiv.org/abs/2511.02620; [S-1507] Adversarial Entropy Inflation Against Gumbel-Based Inference Verification (2026) https://arxiv.org/abs/2608.23375; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance; [S-1202] TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (2026) https://tee.fail/; [S-1210] Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing (2026) https://batteringram.eu/; [S-1212] RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP (2025) https://rmpocalypse.github.io/; [S-1213] SEV-SNP RMP Initialization Vulnerability (AMD-SB-3020) (2025) https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3020.html; [S-1206] A primer on secure enclaves (2026) https://docs.tinfoil.sh/verification/secure-enclave-primer; [S-1207] Backend infrastructure (2026) https://docs.tinfoil.sh/verification/attestation-architecture; [S-1208] How verification works in Tinfoil (2026) https://docs.tinfoil.sh/verification/verification-in-tinfoil; [S-1209] modelwrap: Reproducible dm-verity read-only image of Huggingface models (2026) https://github.com/tinfoilsh/modelwrap

## Network taps and certifiers (M-0013, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, low confidence. R1: the Secure Gateway Device and related designs are public, but no tapped prototype has run at production link rates or with an active warden. - R1 met: the Secure Gateway Device paper specifies the architecture, its goal (no covert exfiltration of results through tapped wires), its assumptions (physical monitoring, prover-held plaintext) and covert-channel estimates [S-1300]. Feasibility and cost analyses cover north-south, storage and compute-fabric taps [S-0031]. The MIRI overview places taps in a full reference architecture [S-0018], and the AI 2040 plan relies on them [S-0067]. - R2 not met: Amodo reports a passive fibre tap on a 1 Gbps uplink, with all 800 test inferences tapped and verified during a flood of non-whitelisted traffic [S-1312]. That result is provider-reported on a blog, at link rates far below production frontend links, and Amodo says the passive tap must become active to close side channels [S-1312]. No code is linked. The most mature Implementation, SASH's confidential network logger, has public code, but it runs a toy model through an inline software proxy that computes no hashes [S-1319] [S-1320]. AI 2040 inference-only verification stack and Low-trust AI compute verification system overview are proposed architectures assessed R1. The Secure Gateway Device paper states that empirical validation and red-teaming are still required [S-1300]. Confidence is low because the Amodo result (real tap hardware, a stated adversarial load) could reasonably be read as meeting R2 in one key respect.
Devices on a cluster's network links that copy and hash all traffic, so a verifier can later check sampled records against declared work.
Network taps copy the traffic on a data centre's cables. In verification proposals, a tap or "secure gateway" hashes everything entering and leaving a cluster. The verifier later asks the operator to reveal randomly chosen records, which are recomputed and checked. The aim is to show that outputs came from declared work, and that results of undeclared work cannot leave covertly through the tapped links. Designs, cost estimates and covert-channel analyses are public. Amodo's small tests have tapped 1–10 Gbps links; as of September 2026 no tap has been demonstrated at production link rates or red-teamed. The main obstacles are hashing at line rate on 400G-class links, and tapping copper or encrypted fabrics. The largest known weakness is covert signalling in model outputs: one design estimates about 40 Mbit/s for a 200,000-GPU inference cluster, even with replay checks, unless inference becomes deterministic.
## How it works

A network tap is a device that "mirror[s] network traffic without disrupting normal operation" [S-0031]. Verification proposals use taps to build a record of what crossed a link, which the verifier can check later [S-0031] [S-0018]. The MIRI system overview states the principle as "capture everything, challenge and audit random samples after" [S-0018].

In the most detailed designs, the verifier never receives plaintext [S-0018] [S-1300]. The tap hashes payloads over groups of packets, without knowing where objects such as prompts begin or end, and sends only hashes out; the operator (the prover) keeps the plaintext [S-0018] [S-1300]. Later the verifier picks stored hashes at random, the prover supplies the matching data, and a verification facility replays the computation and checks that the hashes match [S-1300]. A missing or mismatching preimage is a failure; a replay that does not reproduce points to false metadata or a technical fault [S-0018].

The AI 2040 plan proposes a simpler variant: passive taps on the frontend network copy all input and output traffic to a recomputation server (Sampled inference recomputation, Reproducible computation packets) [S-0067].

Taps can sit at three levels [S-0031]:

- **North-south (frontend) links** to the outside world, at an estimated material cost under 0.01% of the monitored data centre [S-0031].
- **The storage fabric**, which carries model loads, dataset reads and checkpoint saves, at an estimated 0.3–0.5% of data-centre cost [S-0031].
- **The compute (east-west) fabric**, at an estimated 0.2–1.5% of data-centre cost for its optical levels. Volumes there are so high that the note proposes sampling, for example 0.01% of traffic, about 20 Gb/s, through an optical circuit switch [S-0031].

For inference, the monitored perimeter could be as small as pods of a few hundred accelerators; monitoring training needs larger perimeters or taps on the compute and storage fabrics [S-0018].

A key aim of the "Secure Gateway Device" design is that no processor has to be trusted by both sides [S-1300]. It uses passive optical splitters, so that each party can watch the signals it must check, and coin-flip protocols to generate shared random values [S-1300]. It also acts as an "active warden", rewriting free header fields and re-timing packets to close timing, analogue and header channels that checks on hashes cannot address [S-1300].

SASH's planned next prototype would place an FPGA between the cluster and its gateway to issue "cryptographic certificates attesting to the encrypted traffic it has seen" [S-1320]; see SASH confidential network logger.

## What it establishes
The Secure Gateway Device paper aims to make it "infeasible to covertly exfiltrate the results of undisclosed workloads in the cluster through the tapped wires" [S-1300]. Combined with replay, it would show that recorded outputs match declared workloads [S-1300] [S-0067]; see This compute runs inference, not training and Model weights or data have not left the facility.

It does not establish:

- **Device state.** Taps capture flows, not device state; the MIRI overview treats memory probes as complementary [S-0018].
- **Absence of covert compute.** A north-south tap does not directly prevent covert workloads, only the exfiltration of their results [S-1300]. The paper judges it futile to block every single-bit leak. It argues that the residual risk, covert computation plus low-bandwidth signalling of results, needs other checks such as east-west taps and throughput accounting [S-1300].
- **Permissibility or compliance.** The paper does not decide which workloads should be allowed, or whether declared workloads comply [S-1300].

## Threat model
- The operator and the verifier distrust each other. The operator must not hide information in the traffic, and the verifier must learn nothing beyond hashes [S-1300].
- The facility is physically monitored, so that all traffic passes through the gateway [S-1300].
- The operator stores all hashed data for the agreement's duration [S-1300].
- Replay needs reproducible inference (Deterministic and bit-exact inference) [S-0018] [S-1300].
- The MIRI overview models a covert adversary, deterred when the likelihood of detection times the cost of being caught exceeds the expected gain [S-0018].

## Evidence
- **Designs and analysis.** The Secure Gateway Device paper, Cankaya's feasibility note and the MIRI overview are design studies [S-1300] [S-0031] [S-0018]. The paper states that empirical validation is still required and calls for red-teaming by specialists [S-1300].
- **Commercial precedent.** Taps are used for stock-exchange monitoring, packet capture, defence networks and lawful intercept [S-0018]. The MIRI overview says AI use needs changes for a nation-state covert adversary [S-0018].
- **Amodo's first tap test (March 2026).** A passive multimode splitter on a link of about 10 Gbps copied both directions of traffic to a monitoring machine [S-1309].
- **Amodo's tap survey (May 2026).** Commodity taps exist for 26 GBaud links, but none are advertised for 53 GBaud [S-1310].
- **Amodo's hashing benchmarks (July 2026).** On an AMD EPYC server CPU, no tested hash algorithm reached line rate with 64-byte frames, and the tested DPU fell short of the 400 Gbps target [S-1311].
- **Amodo's tapped prototype (September 2026).** A passive fibre tap on the 1 Gbps uplink of its inference-verification prototype fed a frame processor, which rebuilt inference requests and checked all other traffic against a whitelist [S-1312]. Amodo reports that all 800 test inferences were tapped and verified during a flood of about 1 Gbps of non-whitelisted traffic [S-1312].
- **SASH logger.** SASH's public prototype passes every request through an inline software logger and re-runs it on a 270-million-parameter model; it computes no hashes of the traffic [S-1319]. See SASH confidential network logger.

## Limitations
- **Output steganography.** The paper estimates about 40 Mbit/s of covert egress from output nondeterminism for a 200k-GPU cluster, even with replay checks [S-1300]. An attacker who chooses the prompts roughly doubles per-token leakage under Gumbel-based verification [S-1507]; see Deterministic and bit-exact inference and Bounding unexplained information in outputs.
- **Line rate.** On tested CPUs, no hash algorithm kept up with minimum-size frames, and the tested DPU was insufficient [S-1311].
- **Optics and copper.** Passive taps are impractical on 400GBASE-SR8 multimode links, and copper-connected racks are much harder to tap [S-0031]. For 53 and 106 GBaud links, Amodo says a new ASIC may be needed [S-1310].
- **Encryption.** TEE-protected fabrics would hide plaintext from both parties [S-0031].
- **Passive-tap side channels.** Amodo concludes that its passive tap must become active [S-1312].
- **Bypass.** Physical monitoring, and radio, power-line and thermal channels, are outside the network design [S-1300]; see Tamper evidence for verifier devices and Side-channel suppression for isolated facilities.
Technical detail: Secure Gateway Device (SeGaDev) [S-1300]: - Placement. The device sits on the north-south boundary, between TLS termination at the frontend gateway and the internal fabric. If traffic is end-to-end encrypted internally, the device hashes ciphertext and the prover stores session keys [S-1300]. - Pipeline. (1) Sanitization by an active warden, which replaces exploitable header fields (ephemeral source ports, TCP initial sequence numbers, session IDs) with pseudorandom values, keeps connection-tracking tables, and releases buffered packets on a fixed schedule to suppress timing and analogue modulation; (2) hashing of a configurable group of packets (the "hashing boundary") over payloads only; (3) transmission of hashes alone to the verifier on a dedicated fibre, with a passive splitter giving the prover a copy and a prover-controlled "timing warden" re-timing the hash stream [S-1300]. - Shared randomness and timestamps. Shared pseudorandom values come from a commit-then-reveal coin flip between prover- and verifier-supplied generators, precomputed in bulk and consumed in FIFO order. Timestamps are taken by both parties on receipt of hashes, not by the tap [S-1300] [S-0018]. - Audit. The verifier selects stored hashes; the prover returns preimages (prompt, output, token start index, token count) to a verification facility that replays the computation and compares hashes. With k random challenges, a misreported fraction p is detected with probability 1 − (1 − p)^k; k = 3,200 detects 0.1% misreporting at 96% confidence [S-1300]. - Storage. A pessimistic upper bound (100k Hopper GPUs at 2,000 tokens/s each, one token per streaming frame) is about 200 PB of SHA-256 hashes and 1,260 PB of prover-held plaintext per year, about €22.5 million in drives [S-1300]. - Dictionary attacks. Against verifier dictionary attacks on hashes of short outputs, the paper recommends at least 5 tokens per hashed template, or at least 10 if the attacker filters for likely tokens [S-1300]. - Residual covert channels. A 10 ms re-timing window at 100 Gbps holds up to about 625k packets, so packet-count modulation must be fixed per connection per window. Output nondeterminism leaves about 0.1 bit per token even with seed-synchronized replay, which gives about 40 Mbit/s for 200k GPUs at 2,000 tokens/GPU/s. Feigned hardware failures give about 1 kbit/day [S-1300]. - Line-rate hashing (Amodo). On an AMD EPYC 9354P with DPDK, all tested algorithms except BLAKE3 reached the receive baseline at 1500-byte frames once enough threads were used; at 64-byte frames none reached line rate within the CPU's physical core count. Offloading to the tested DPU did not reach the target. SipHash-1-3-128 was the leading candidate, and FPGA or ASIC hashing is expected to be needed for some plans [S-1311]. - Passive optics (Amodo). Amodo computes a 1.45 dB link margin for a representative 53 GBaud link; a 95/5 split costs about 0.25 dB on the live leg and about 13 dB on the monitor leg [S-1310].
Sources: [S-1300] Fingerprinting All AI Cluster I/O Without Mutually Trusted Processors (2026) https://arxiv.org/abs/2606.10724; [S-0031] The Fundamentals and Feasibility of Secure Network Taps for Verifying AI Datacenter Use (2026) https://nacicankaya.substack.com/p/research-note-the-fundamentals-and; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-1309] Network Taps — A First Test (2026) https://amododesign.com/notes/2026-03-20-network-taps-first-test/; [S-1310] Network Tapping for AI Verification: A Technical Assessment (2026) https://amododesign.com/notes/2026-05-03-network-tapping/; [S-1311] Network Traffic Hashing (2026) https://amododesign.com/notes/2026-07-03-network-traffic-hashing/; [S-1312] Fitting a Network TAP to our Inference Verification Prototype (2026) https://amododesign.com/notes/2026-09-15-network-tap-inference-verification/; [S-1319] inference-verification: Inference Verification Prototype (2026) https://github.com/sg-ai-safety-hub/inference-verification; [S-1320] Internationalising AI Verification (2026) https://www.aisafety.sg/blog/making-ai-verification-international; [S-1507] Adversarial Entropy Inflation Against Gumbel-Based Inference Verification (2026) https://arxiv.org/abs/2608.23375

## On-chip telemetry from timing, memory and performance counters (M-0010, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2. Detailed results exist on current GPUs against a stated adversary, but the data can be forged in software and no one outside the developers has evaluated the methods. - R1 met: primitives, claims and threat models are published [S-0033] [S-0034] [S-0037]. - R2 met through reproducible published results. Rahman and Tajdari report end-to-end results on nine NVIDIA GPU models, including H100, H200 and B200, over five monitor-evader rounds against a stated adversary. They state that code for their workloads is in the project repository, but give no repository URL [S-0037]; the rubric does not require code for this route. Monfared et al. report measurements on T4 and H100 GPUs with language models of up to 72B parameters [S-0033]. No Implementation record realises this mechanism, and the most mature work is the NVML classifier. - R3 not met. No source reports a party other than the developers relying on these signals for a verification decision, and as of September 2026 no independent evaluation has been published. Trustworthy collection also needs hardware protections that Rahman and Tajdari list as prerequisites [S-0037].
Uses timing, memory-residency and performance-counter signals measured on AI accelerators as evidence about which workloads they are running.
Accelerators already track quantities such as power, clock rates, memory use and operation counts, and challenge programs can time how quickly a chip completes set tasks. Researchers propose using these signals as evidence about workloads, for example to tell training from inference or to check that model weights are held in a chip's own memory. Studies on NVIDIA GPUs from the T4 to the B200 show that such signals can distinguish workloads. One classifier spotted training with 98.2% accuracy across its authors' corpus, but caught the hardest unseen disguised workloads only 43–87% of the time after five rounds of hardening. The biggest obstacle is trust in the data: an operator who controls the software stack can forge standard telemetry unless the read path is protected in hardware. The signals give statistical evidence, not proof. Counters can also leak secrets, and NVIDIA disables them in confidential-computing mode for that reason.
## How it works

Three families of signals are proposed.

**Built-in counters and management telemetry.** RAND notes that GPUs already have on-device counters for floating-point operations, instructions executed, NVLink and PCIe bandwidth, memory accesses and power. These can be reported per streaming multiprocessor or for the whole chip [S-0057]. O'Gara et al. list such counters as possible meters for compute accounting and licensing [S-0006]. Rahman and Tajdari train a classifier to spot training workloads from nine standard NVML counters sampled once a second. They describe these signals as content-agnostic [S-0037].

**Timing and memory challenges.** Monfared et al. have a challenger send puzzles to the GPU and time the answers [S-0033]:

- memory-hard proof-of-work puzzles probe parallel effort;
- verifiable delay functions probe sequential execution;
- matrix-multiplication puzzles probe the tensor cores;
- a residency test checks whether challenge data stayed in the GPU's own memory.

Co-running workloads compete for the same units, so contention shows up as shifts in the timing distributions [S-0033]. Gloria Z similarly suggests memory-residency and random challenges, which force an operator to keep false accounts consistent across every signal [S-0014]. Timed challenge-response in general is covered in Timed challenge-response and memory-occupation challenges.

**New memory-side hardware.** Guaranteeable Memory would place an open-source "guarantee chiplet" beneath the HBM stacks. The chiplet would observe memory traffic and attest to memory snapshots, GPU instructions, or random subsets of claimed computations [S-0034]. This connects to the guarantee processors of Hardware-enabled guarantees (flexHEG) and guarantee processors.

## What it establishes
These signals give statistical indicators of utilisation and workload type. Examples are whether a GPU is training [S-0037] and whether data is resident in its memory [S-0033]. They bear most directly on This compute runs inference, not training, and more weakly on Declared hardware is idle or shut down and There is no undeclared relevant compute.

They cannot establish:

- **Correct execution.** Monfared et al. state that their measurements are "not designed to deliver cryptographic proof of correct execution" [S-0033].
- **Which device answered.** The timing challenges do not identify the individual GPU [S-0033].
- **The content of the computation.** The counters do not access model weights or training data [S-0037].
- **That all activity was declared.** Gloria Z treats telemetry as one partial answer to resource accounting, and judges that it "seems extremely difficult to verify the completeness of workload declarations" [S-0014].

Classifying workloads from these and other signals is covered in Workload classification from telemetry and side channels.

## Threat model
The schemes trust different parts of the stack:

- **NVML classifier.** It assumes the counters are genuine. Rahman and Tajdari list the protections this would need: a tamper-resistant read path, an authenticated channel and secure boot of the monitoring software. They model two evaders: a cloud tenant with user-space control, and a hardware operator who controls the full software stack [S-0037].
- **Timing challenges.** Monfared et al.'s most adversarial case lets the host and GPU firmware be modified, virtualized or colluding. Only challenge generation, timing and verification are trusted, and the challenges run on the GPU being measured [S-0033].
- **Guaranteeable Memory.** It aims not to rely on any other component, including the main accelerator die [S-0034].

Confidentiality is only partial. Counters are content-agnostic [S-0037], but they are also a known side channel [S-0014]. NVIDIA disables them in full confidential-computing mode because they could provide an avenue for side-channel attacks [S-1200], which puts this mechanism in tension with TEE remote attestation for AI workloads.

## Evidence
- **Rahman and Tajdari.** They tested nine NVIDIA GPU models from four architecture generations, including A100, H100, H200 and B200, with up to eight GPUs per node. The classifier reached 98.2% binary accuracy at identifying training across their whole corpus. After five monitor-evader rounds covering 20 evasion strategy families, it reached 43–87% accuracy on the most challenging disguised workloads held out from training. The authors state that code for the workloads is in the project repository, but give no URL [S-0037].
- **Monfared et al.** They measured T4 and H100 GPUs running language models from 1.1B to 72B parameters. With 60 GB of challenge data on an H100, the residency test separated on-device from off-device data by more than 350 ms. Continuous puzzles caused noticeable losses in power and throughput, while the residency test's losses were negligible. The paper mentions no code release [S-0033].
- **Guaranteeable Memory.** It is a workshop proposal with no reported prototype [S-0034].

## Limitations
- **Forgery.** If the operator controls the software that reads the counters, the counters prove little [S-0037].
- **Disguise.** Adversarial disguise works in part: white-box LoRA fine-tuning was detected less than half the time [S-0037].
- **Outsourcing and virtualization.** Timing challenges can be answered by identical GPUs, and virtualization confounds attribution [S-0033].
- **Checking matrix results.** Floating-point rounding complicates the check [S-0033].
- **Error rates.** The timing primitives have no calibrated error rates [S-0033].
- **Evaluation scope.** The classifier was evaluated only on single nodes, with evasion at the PyTorch level and sampling at about 1 Hz [S-0037].
- **Power sampling.** Yang and colleagues found that on A100 and H100 GPUs the built-in power reading, which nvidia-smi obtains through NVML, samples only 25% of runtime. The GPU can draw very different power in the other 75% without the reading showing it [S-0073]. They also found the reading's error to be within about ±5% in most cases, against the ±5 W that NVIDIA claims [S-0073].
- **Leakage.** Richer counters risk leaking secrets [S-0014].
Technical detail: - Counter-based classification. Rahman and Tajdari sample nine always-available NVML counters at 1 Hz: GPU and memory utilization, memory used, power, temperature, SM and memory clocks, and PCIe TX/RX. They extract 166 features over 5–60 s windows, including memory slope and epoch periodicity from an FFT of power [S-0037]. - Memory-hard proof of work. In Monfared et al.'s challenge suite, these puzzles expose parallel effort and HBM use [S-0033]. - Verifiable delay functions. Based on sequential modular squaring, they expose sequential compute pressure [S-0033]. - GEMM puzzles. They target tensor-core throughput; the authors note that over 90% of LLM floating-point operations are GEMMs. Results can be checked with Freivalds' algorithm, subject to floating-point rounding discrepancies [S-0033]. - VRAM residency test. It runs bandwidth-bound Argon2id over challenge data. With 60 GB of challenge data on an H100, the response time for data held in HBM and for data in pinned host memory reached over PCIe differed by more than 350 ms [S-0033]. - Guaranteeable Memory. A guarantee chiplet beneath the HBM stacks would observe memory traffic directly. The author argues that the HBM standard makes it compatible with multiple leading accelerators [S-0034]. - Metering targets. Candidate targets for licensing include floating-point and integer arithmetic, memory, NVLink and PCIe transfer volume, energy and clock cycles [S-0006].
Sources: [S-0033] Timing and Memory Telemetry on GPUs for AI Governance (2026) https://arxiv.org/abs/2602.09369; [S-0034] Guaranteeable Memory: An HBM-Based Chiplet for Verifiable AI Workloads (2025) https://openreview.net/forum?id=uc79kOv0MV; [S-0037] Detecting Hidden ML Training With Zero-Overhead Telemetry (2026) https://arxiv.org/abs/2606.19262; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-0006] Hardware-Enabled Mechanisms for Verifying Responsible AI Development (2025) https://arxiv.org/abs/2505.03742; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance; [S-1200] NVIDIA Secure AI with Blackwell and Hopper GPUs (White Paper) (2025) https://docs.nvidia.com/nvidia-secure-ai-with-blackwell-and-hopper-gpus-whitepaper.pdf; [S-0073] Part-time Power Measurements: nvidia-smi's Lack of Attention (2023) https://arxiv.org/abs/2312.02741

## Proof-of-learning and training-transcript verification (M-0006, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, low confidence. R2 through Choi et al.'s peer-reviewed results; the original verification rule is broken, and the later defences are heuristic and have not been attacked independently. - R1 met: Jia et al. define proof-of-learning and its security goal [S-0028], and Shavit sets out training-transcript verification for rules on large training runs [S-0029]. - R2 met through Choi et al., not through the original scheme. The original authors demonstrated spoofs that pass verification across configurations at a fraction of the cost of earlier spoofing strategies [S-0027]. An earlier independent attack reported spoofs cheaper than honest training [S-1109], which the original authors dispute [S-0027]. These breaks invalidate the original demonstration, including the public code, which implements that rule [S-1111]. Choi et al. publish peer-reviewed end-to-end experiments against a stated set of spoofing attacks, training GPT-2 (124M) and testing published Pythia checkpoints up to 1B on GPUs [S-0030]. The paper links no code; the rubric does not require code for results described in enough detail to repeat. The open critical flaws concern the original rule, not the evidence the level rests on. No Implementation carries the level. - R3 not met. As of September 2026 no third party is known to rely on these checks, and no production-grade implementation or independent attack on the post-2023 defences has been published.
A trainer logs checkpoints, data order and settings, so a verifier can re-run sampled training segments and check that the claimed training happened.
Proof-of-learning asks a model trainer to keep a transcript of training: weight checkpoints, the data used at each step and the settings. A verifier re-runs a few segments and checks that they reproduce the logged checkpoints. It was proposed to show that compute was really spent on training, and later to check that training runs obeyed rules on compute and data. The original scheme has public code, and a later defence was tested on language models of up to 1 billion parameters. The biggest known weakness is that published attacks produced invalid proofs that passed verification, and the original authors later argued that no provably robust version exists without a better theory of deep-learning optimisation. Later defences are heuristic. The biggest obstacle for verification use is that the verifier must see the training data and weights and be able to re-run training segments.
## How it works

**The transcript.** Proof-of-learning (PoL) asks a trainer to record a transcript of training [S-0028]. It contains:
- weight checkpoints saved every k steps;
- the indices of the data batches used at each step;
- signatures of the training data;
- metadata such as hyperparameters, optimiser and architecture [S-0028].

**Checking it.** A verifier checks the transcript by re-running training for selected segments. For each epoch, it takes the Q largest weight updates and recomputes the k steps from the earlier checkpoint. It accepts if the result lies within a distance threshold δ of the logged checkpoint [S-0028]. The threshold absorbs the numerical noise from hardware and software nondeterminism [S-0028].

**Why forging should be costly.** The PoL code repository explains that gradient descent "accumulates secret information due to its stochasticity" [S-1111]. On this basis, Jia et al. claim a forger must spend "at least as much work than is needed for gradient descent itself" [S-0028].

**Use for rule verification.** Shavit adapts the idea to verifying rules on large training runs [S-0029]:
1. Chips log weight snapshots.
2. Inspectors sample chips.
3. The prover must show a training transcript that explains each logged snapshot.
4. The verifier re-runs only the segments concerned [S-0029].

**Tests on the training data.** Choi et al. add checks aimed at training data [S-0030]:
- the random seed, initialisation and data order are derived from a hash of the dataset;
- memorisation tests check that training points are fitted best just after their segment;
- suspicious segments are flagged for retraining [S-0030].

## What it establishes
**What it can establish.**
- If verification holds, the transcript is consistent with training that actually took place. This supports claims about ownership and the compute spent [S-0028].
- With data-focused tests, it also supports claims about "the amount and kind of data and compute used to train the model" [S-0030]. This bears on A training run stayed within declared limits.

**What it cannot establish.**
- **A link to derived models.** PoL cannot connect a model to a surrogate derived from it by extraction [S-0028].
- **Anything without reproducible training.** The approach relies on training being approximately reproducible from the hyperparameters, data order and seed [S-0029].
- **Online or reinforcement learning.** Where the data is not known in advance, these are not covered [S-0030] [S-0029].

## Threat model
The adversary tries to produce a valid-looking transcript for weights it did not train, or for a run that broke the rules, while spending less than honest training [S-0028] [S-0029].

The scheme assumes several things:
- the verifier can re-run training segments on comparable hardware [S-0030];
- honest noise is small compared with genuine updates [S-0028];
- the verifier receives the data and weights, since Jia et al. require that training data "be shared with verifier" [S-0028].

In Shavit's framework, three further assumptions tie transcripts to real chips [S-0029]:
- the chips support firmware attestation and logging;
- they have tamper-evident packaging;
- a trusted chip-owner directory exists.

## Evidence
- **Jia et al.** They evaluate PoL with ResNet-20 and ResNet-50 on CIFAR-10 and CIFAR-100 [S-0028]. Their code for creating and verifying proofs is public [S-1111].
- **Choi et al.** They train GPT-2 (124M) on about 8.8 billion OpenWebText tokens, and apply their tests to EleutherAI's published Pythia checkpoints of 70M, 410M and 1B parameters, using four A40 GPUs [S-0030]. They show detection of attacks from the PoL literature, including gluing, interpolation and data addition or subtraction [S-0030]. Sampling 1% of the points in each segment, they estimate that their new memorisation and data-order tests cost "just 1.3% of the original cost of training", in addition to retraining selected segments [S-0030].
- **Shavit.** His framework is a proposal, with estimates of how many chips inspectors would need to sample [S-0029].

## Limitations
**Independent attack.** Zhang et al. of Zhejiang University showed that adversarial-example-style perturbations let an attacker generate a passing proof "with significantly less cost" than honest training [S-1109]. Fang et al. dispute this. They state that the attack assumes the adversary chooses the checkpoint interval, which the verifier should set, and that a small interval prevents it [S-0027].

**Attack by the original authors.** Fang et al., whose authors include all seven original PoL authors, present cheaper spoofs that work across PoL configurations. They find that "current PoL verification is not robust to adversaries", and show that the assumptions needed for robust verification reduce to open problems in learning theory [S-0027].

**Gaps in later defences.** Choi et al. defend against several known attacks, but note that small-scale data changes and masked hyperparameters remain open [S-0030].

**Cost.** Storage is a burden: checkpoints may each take terabytes [S-0029]. Shavit identifies cheaper alternatives to retraining-based verification as future work [S-0029].

**Alternatives.** Zhang et al. suggest proofs built on verifiable computation as a countermeasure [S-1109]. Zero-knowledge proofs of training take that route, proving each training step cryptographically [S-0022].
Sources: [S-0028] Proof-of-Learning: Definitions and Practice (2021) https://ieeexplore.ieee.org/document/9519402/; [S-1111] Proof-of-Learning: code for Proof-of-Learning: Definitions and Practice (2021) https://github.com/cleverhans-lab/Proof-of-Learning; [S-1109] "Adversarial Examples" for Proof-of-Learning (2022) https://arxiv.org/abs/2108.09454; [S-0027] Proof-of-Learning is Currently More Broken Than You Think (2023) https://arxiv.org/abs/2208.03567; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0030] Tools for Verifying Neural Models' Training Data (2023) https://proceedings.neurips.cc/paper_files/paper/2023/hash/03e33e1f62e3302b47fe1d38a235921e-Abstract-Conference.html; [S-0022] Trustless Audits without Revealing Data or Models (2024) https://proceedings.mlr.press/v235/waiwitlikhit24a.html

## Proofs of useful work and resource exhaustion (M-0007, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, low confidence. R1. The scheme is proposed, and the only implementation proves work for blockchain consensus, not that hardware has no spare capacity. - R1 met: Attestable describes such a scheme, with its claim and a key assumption, namely a credible estimate of the actor's compute [S-1102]. The underlying proof-of-useful-work construction is publicly specified with its hardness assumptions [S-1609]. The capacity-bounding use rests on this one provider's blog proposal. - R2 not met for this use. The most mature implementation, Pearl, is assessed R2 only for the narrower claim that GPUs performed matrix-multiplication work. It is built for blockchain consensus, and no public implementation or result uses proofs of useful work to bound the spare capacity of declared hardware [S-1105] [S-1107].
Cryptographic evidence that hardware performed a given amount of agreed computation, proposed as a way to show no spare capacity remained for other work.
A proof of work shows that a certain amount of computation was done. Proofs of useful work make that computation something valuable, such as the matrix multiplications at the heart of AI models. For verification, the idea is to keep declared hardware fully occupied with agreed, provable work, so that little capacity is left for anything unmonitored. The cryptographic building block exists: a 2025 construction adds asymptotically negligible overhead to large matrix multiplications, and a company reports running a public blockchain built on it. Using it to show that hardware has no spare capacity is only proposed. The biggest obstacle is that the verifier needs a credible estimate of how much compute the prover actually has. The biggest weakness is that such proofs show work was done, but cannot find hardware that was never declared, and do not show what the work was for.
## How it works

**Proofs of work.** A proof of work gives confidence that some declared amount of computation took place. In cryptocurrency mining, workers hash variants of a message until one hash meets a target, and a verifier can check it quickly [S-0005]. Scher and Thiergart note that applying proof of work "could verify that compute declared to be doing crypto mining is indeed doing it" [S-0005].

**Proofs of useful work.** A proof of useful work (PoUW) makes that computation serve another purpose. Ball et al. gave constructions for problems such as Orthogonal Vectors, 3SUM and All-Pairs Shortest Path [S-1608]. Komargodski and Weinstein give a PoUW for arbitrary matrix multiplication, which lets the miner choose its own matrices [S-1609]. Their protocol works in three steps [S-1609]:
1. Low-rank random "noise" matrices are derived from public randomness and added to the inputs.
2. The noised product is computed in blocks, and the transcript of intermediate blocks is hashed.
3. A hash below a difficulty threshold is a winning proof.

The noise can then be subtracted cheaply to recover the useful product [S-1609]. Hardness rests on the transcript rather than the output, so choosing trivial matrices gives no shortcut [S-1609].

**Pearl's variant.** Pearl's floating-point specification adapts this to FP8 matrix multiplication on GPUs [S-1105]:
- quantising after the noise is added lets output tiles be hashed directly;
- the verifier "checks one tile of the matmul, never the whole product", recomputing it bit for bit [S-1105].

**Use for resource exhaustion.** Attestable proposes proof-of-work accounting to bound compute available for unmonitored activity [S-1102]. In its scheme, "Useful, approved inference contributes to the required work budget". When demand falls short, "additional protocol-defined work fills the shortfall" [S-1102].

**Memory analogues.**
- Proofs of space require dedicating "a significant amount of disk space" [S-1607].
- A verification system design proposes filling device memory with incompressible noise and challenging random samples [S-0018] (see Memory wiping and proofs of secure erasure).

## What it establishes
**What it can establish.**
- A valid proof of useful work shows that a stated amount of matrix-multiplication work was performed on inputs committed through the noise derivation [S-1609] [S-1105].
- If the verifier knows the capacity of declared hardware, a sustained rate of such proofs could bound the capacity left for other work. This is Attestable's proposal [S-1102], and it bears on There is no undeclared relevant compute and Declared hardware is idle or shut down for declared hardware.

**What it cannot establish.**
- **Undeclared hardware.** Attestable states that a proof "cannot discover a datacenter that was never declared" [S-1102].
- **What the work was for.** The proof does not show which AI workload, if any, the matrices came from. Komargodski and Weinstein do not address auditing whether matrices come from real AI workloads [S-1609]. On Pearl's network, an independent study found that verification "does not check whether the matrices originate from an AI model" [S-0071]. Attestable proposes pairing work accounting with proofs of inference for that [S-1102].

## Threat model
The adversary is a miner who tries to produce accepted proofs faster than honest work would allow [S-1609]. Security holds in the random-oracle model under a "direct-product" hardness assumption about intermediate values of multiplying random low-rank matrices [S-1609]. Pearl's variant assumes that computing quantised products of noised matrices "is not substantially easier than generic quantized products" [S-1105]. It also relies on deterministic, reproducible GPU arithmetic for bit-exact verification [S-1105].

For capacity bounding, the verifier also needs "a credible estimate of the compute available" to the actor [S-1102].

## Evidence
- **Theory.** Komargodski and Weinstein prove a multiplicative overhead of 1 + o(1) over naive matrix multiplication [S-1609].
- **Pearl.** Pearl publishes the code of a network built on this construction [S-1107], and reports that the chain went live when the node code became public [S-1106]. It also reports a benchmark on four H200 GPUs. Its "two-for-one" variant of Llama 3.3 70B, which re-implements a layer with a new quantisation mechanism, reached up to 18,291.66 tokens per second. The original model's best configuration reached 15,269.81 tokens per second; with the four-way data parallelism that gave the variant its best figure, the original bf16 model ran out of memory [S-1106].
- **Independent measurement of Pearl.** Basu studied Pearl's mainnet in May 2026. String analysis suggests that the dominant mining software, from a third party, contains no inference code and generates matrices from random seeds. Random matrices passed verification in the study's tests [S-0071].
- **Capacity bounding.** As of September 2026 no public result applies proofs of useful work to bounding the capacity of declared AI hardware. Attestable describes its proposal as near-term work [S-1102].

## Limitations
**Verification cost.** Komargodski and Weinstein note that plain verification is "relatively expensive on the verifier's side", and suggest the prover can use a zkSNARK to lighten it [S-1609]. They also note that storing the transcript takes significant memory [S-1609].

**Known shortcuts.** Pearl lists known mining speedups: crafted inputs, precision shortcuts, seed grinding and work reuse. It adds checks to limit them [S-1105]. It describes faster kernels or hardware as "not an attack on the protocol" [S-1105].

**Assumptions and scope.** Open problems include PoUW from more standard assumptions, and PoUW for tasks beyond matrix multiplication [S-1609].
Sources: [S-1609] Proofs of Useful Work from Arbitrary Matrix Multiplication (2025) https://arxiv.org/abs/2504.09971; [S-1105] Pearl Floating Point Scheme Specification (2026) https://pearlresearch.ai/Pearl_Whitepaper.pdf; [S-1106] Pearl INT Whitepaper (2026) https://pearlresearch.ai/research/int-whitepaper; [S-1107] pearl: Monorepo for the Pearl network (2026) https://github.com/pearl-research-labs/pearl; [S-0071] The Usefulness Gap in Proof-of-Useful-Work: An Empirical Study of Pearl's cuPOW Protocol (2026) https://arxiv.org/abs/2606.04819; [S-1102] Pacing AI Requires Proof (2026) https://attestable.com/blog/pacing-ai-requires-proof; [S-1608] Proofs of Useful Work (2017) https://eprint.iacr.org/2017/203; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-1607] Proofs of Space (2015) https://eprint.iacr.org/2013/796

## Remote detection of data centres (M-0020, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, low confidence. R1. Public results so far monitor sites whose locations were already known; none shows a search that finds undeclared facilities. - R1 met: Halstead and Larsen describe heat, imagery and other detection signals, ways to conceal a facility and the odds of detecting covert ones [S-1410]. Baker et al. place satellite imagery among supplementary verification mechanisms [S-0002]. - R2 not met for this use: Krawec's case studies track known sites [S-1409]. Epoch AI's public dataset estimates the capacity of known large facilities [S-1411]. Krawec states that automated data-centre detection "remains primarily conceptual at present" [S-1409]. Confidence is low because the level depends on scope. The public Epoch dataset and Krawec's case studies could arguably meet R2 for the supporting use of estimating the capacity of known sites (Compute stock is at most a declared amount).
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.
Remote detection of data centres is a set of methods for finding facilities and estimating their size from outside. Large AI data centres need buildings, substations and cooling equipment, and they shed roughly as much heat as the electricity they use. These features can be seen without the operator's cooperation. Analysts already combine satellite imagery with permits and utility filings to track the construction of known large facilities and estimate their power capacity. For verification, the harder task is finding facilities nobody has declared. As of September 2026 that has not been demonstrated, and automated detection of data centres remains mainly conceptual. Imagery also cannot see inside buildings or count chips. The main weaknesses are concealment, such as disguising a facility as other industry or building it underground, and sites too small to stand out. Verification frameworks treat these signals as supplements to stronger mechanisms.
## How it works

Remote detection infers the existence, size and status of data centres without entering them [S-1409]. Electro-optical satellite imagery shows these features [S-1409]:

- large data halls;
- substations and switchyards;
- on-site gas turbines and backup generators;
- cooling towers and chillers;
- construction progress.

Analysts combine imagery with permits, utility filings, company announcements and other open sources [S-1409]. Free imagery comes from archives such as the ESA Copernicus Sentinel and NASA Landsat missions [S-1409]. Paid commercial imagery reaches sub-metre resolution, from providers such as Planet Labs, Airbus and Vantor [S-1409].

Capacity can be estimated from cooling equipment [S-1411] [S-1409]. Epoch AI's Frontier Data Centers Hub finds chillers and cooling towers in satellite images and checks them against permits and public disclosures [S-1411]. From these it infers each facility's power capacity, and then the compute installed, in H100-equivalents [S-1411].

Halstead and Larsen treat waste heat as the main obstacle to hiding a facility [S-1410]. They note that "each megawatt of electricity going into a datacenter must be matched with a megawatt going out in some form (mostly as heat)" [S-1410]. They list other signals [S-1410]:

- Infrared satellites can see exhaust air and cooling plumes.
- Radar interferometry can reveal ground movement from excavation.
- Ground moving-target radar can track logistics vehicles.

Ansari also notes that infrared remote sensing can detect undeclared data centres through their heat signatures [S-0007].

Verification frameworks usually give these signals a supporting role [S-0002]. Baker et al. list satellite or aerial images, open-source intelligence, information from data-centre suppliers and financial audits as "less robust mechanisms" that could supplement the main ones [S-0002]. One of their main layers is national intelligence activities, which can draw on human, cyber and signals intelligence [S-0002]. Remote detection complements chip accounting (Chip registries and manufacturing records) and workload classification (Workload classification from telemetry and side channels).

## What it establishes
From outside, analysts can see construction progress, site layout and power and cooling infrastructure, and can estimate power capacity approximately [S-1409] [S-1411]. In one of Krawec's case studies, Epoch AI's capacity estimates from cooling equipment ranged from about 200 to 500 MW, against a published expected capacity of 300 MW [S-1409]. Imagery can also reveal gaps between announced and observed construction [S-1409].

Remote detection has four gaps:

- Electro-optical imagery "can only view the outside of buildings", so it gives no chip counts, chip types or actual power consumption [S-1409].
- Capacity figures from cooling equipment are approximations, not measurements of energy use [S-1409].
- Power figures alone cannot distinguish AI training from other high-performance computing [S-0007].
- Chips that have been produced but not yet installed in data centres are hard to find this way [S-1410].

## Threat model
Remote detection assumes that large facilities have physical signatures that are hard to remove, such as buildings, substations, cooling equipment and waste heat [S-1410] [S-1409]. It uses imagery and public records, so it needs no cooperation from the operator [S-1409].

The adversary may try to hide a facility [S-1410]. Halstead and Larsen consider disguising sites as industrial facilities, and underground designs whose cooling avoids visible plumes [S-1410].

The approach also assumes access to recent imagery and skilled analysts. Krawec lists cloud cover, smoke and weather, the cost of recent high-resolution imagery and the need for trained analysts as constraints [S-1409].

## Evidence
- Krawec's May 2026 report for the Federation of American Scientists presents two case studies [S-1409]. One tracks a facility's construction over 2024 and 2025 against public announcements [S-1409]. The other counts infrastructure at an operating AI facility and checks it against utility records and permits [S-1409].
- Epoch AI's hub covered 13 large US data centres at its launch in November 2025 [S-1411]. Epoch estimated that they held about 2.5 million of the roughly 15 million H100-equivalents delivered to customers worldwide in recent years [S-1411]. The data are released under a Creative Commons Attribution licence [S-1411].
- Halstead and Larsen estimate the chance that unilateral detection methods find a covert project within ten years of an international agreement [S-1410]. For a single site they give 26% at 10 MW, 35% at 100 MW and 50% at 1 GW [S-1410]. For ten sites of each size they give 37%, 67% and 85% [S-1410]. They call these estimates highly speculative, based entirely on intuition and qualitative reasoning [S-1410].
- Krawec recommends satellite imagery as one element of verification for future agreements, and points to the IAEA's satellite imagery analysis team for nuclear safeguards [S-1409]. The report names thermal infrared, synthetic-aperture radar and multispectral imaging as directions for further research [S-1409].

## Limitations
- Facilities can be disguised as other industry or placed underground [S-1410].
- A sufficiently small covert project could not be ruled out with confidence [S-1410]. Small data centres in existing buildings may lack distinctive signatures [S-1409].
- Without a known location, telling data centres apart from other industrial facilities is hard, and automated detection is mainly conceptual [S-1409].
- Chip counts, chip types and actual energy use cannot be observed [S-1409].
- Cooling and power features vary across companies and countries, and not every site generates its own power [S-1409].
Sources: [S-1409] Tracking Hyperscale AI Data Center Growth with Satellite Imagery (2026) https://fas.org/publication/tracking-hyperscale/; [S-1411] Introducing the Frontier Data Centers Hub (2025) https://epoch.ai/latest/introducing-the-frontier-data-centers-hub; [S-1410] Covert AI Projects (2026) https://ai-2040.com/supplements/covert-ai-projects; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0007] Hardware-Level Governance of AI Compute: A Feasibility Taxonomy for Regulatory Compliance and Treaty Verification (2026) https://arxiv.org/abs/2604.04712

## Reproducible computation packets (M-0003, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, low confidence. R1: the design, its claim and its assumptions are public, but nothing beyond single-request inference recomputation has been built. - R1 met: the AI 2040 verification plan describes the design (discrete, reproducible packets visible to a recomputation server, with random partial recomputation), the claim it serves (correct outputs in an inference-only regime, later R&D verification) and its assumptions (reproducibility, an intact recomputation server, physical security) [S-0067]. Amodo gives a comparable written design at the level of single training steps [S-0017]. The plan is the only Implementation record for this mechanism (AI 2040 inference-only verification stack, assessed R1). - R2 not met: no public implementation or end-to-end result organizes whole workloads into reproducible packets. The demonstrations are single-request inference recomputation prototypes [S-1006], and Amodo rates network reproducibility "not on track" [S-1008]. Confidence is low because the design is described only at a high level, and the plan's appendix of calculations remains unread.
Organizing all AI workloads in a facility into discrete, reproducible units, so that a verifier can recompute a random sample and check each one.
The AI 2040 verification plan proposes that every AI workload in a monitored facility be organized into discrete, reproducible "packets" that a verifier's recomputation server can see. The verifier re-runs a random sample of packets to check that they were computed as declared. In the plan's illustrations, smaller packets raise the chance of catching a rogue workload. As of September 2026, no implementation beyond recomputation of single inference requests has been published. The main obstacles are that workloads and network traffic are not reproducible by default, that the recomputation server must be secured, and that compute outside declared packets is not covered. The plan itself does not verify that spare compute is unused, and notes that non-compliant work might be hidden inside compliant-looking workloads.
## How it works

For an inference-only retrofit, the AI 2040 verification plan proposes passive network taps that copy all input and output traffic to a recomputation server [S-0067]. All AI workloads, including inference and agentic tool use, would be organized into "discrete and reproducible packets, which are transparent to the recomputation server" [S-0067]. The server recomputes random samples of the packets to check that they are correct [S-0067]. Reproducibility is required because the correctness checks depend on it, and inference is not reproducible by default [S-0067].

For later verification of R&D, the plan breaks workloads into a hierarchy of steps: full training run, training phases, gradient steps, layer forward and backward passes, GPU kernel calls and individual instructions [S-0067]. If each step can be made reproducible (the plan notes that seeded randomness is acceptable), the granularity of evidence collection maps predictably to the level of assurance [S-0067]. The same plan would also split data centres into isolated inference units by removing much of the back-end ("east-west") networking [S-0067]; see Bandwidth limits and compartmentalization.

The plan illustrates the approach for 2034 [S-0067]:

- a pool of about 33 billion H100-equivalents, its projected build-out for that year;
- a recomputation budget of 1%;
- packets of 100 H100-equivalent hours.

It charts, by the deployment's size, the probability of catching a rogue internal deployment within an hour, a week or a month [S-0067]. The plan states that detection improves as packet size decreases [S-0067].

Amodo describes a related design for pre-training, in which each training step is the unit [S-0017]:

- The prover commits a hash of sampled weight positions before learning whether the step will be audited [S-0017].
- For audited steps, the verifier re-runs the step and accepts if the result agrees with the committed checkpoint within a calibrated tolerance [S-0017].
- Because the verifier's hardware is much slower than the prover's, the audit rate follows from the slowdown: about 0.1% of steps if recomputing a step takes 1,000 times as long as the step itself [S-0017].

Amodo reports a prototype that recomputes individual inference requests, which Sampled inference recomputation covers [S-1006].

## What it establishes
The plan argues that random partial recomputation can verify all outputs with very high probability while using a small fraction of the original compute [S-0067]. Like other recomputation schemes, it checks whether declared workloads were computed correctly, not whether other work ran outside them [S-0017]. The plan states that it does not verify that spare compute is left unused for unapproved workloads [S-0067].

## Threat model
- **Recomputation server.** The plan calls its integrity "an extremely important aspect" of the retrofit [S-0067].
- **Physical security.** The plan relies on strong physical security to protect the verification measures from tampering [S-0067].
- **Cooperation.** Amodo's schemes assume the prover cooperates and lets the verifier install a recomputation server in its data centre [S-0017].
- **Commit before audit.** In Amodo's training-step design, the prover commits its evidence before it learns which steps will be audited [S-0017].

## Evidence
- **Whole-workload packets.** As of September 2026, no implementation or end-to-end result of organizing whole workloads into reproducible packets has been published.
- **Inference recomputation.** Amodo reports demonstrations of inference recomputation systems that work around nondeterminism [S-1008], including its own single-request prototype [S-1006].
- **Reproducibility status.** Amodo rates a reproducible inference stack as not started [S-1008]. It rates network reproducibility as not on track, because optimizations throughout the networking stack mean that network packets are not individually reproducible by default [S-1008]. It suggests schemes that do not need exact packet replication as a possible alternative [S-1008].

## Limitations
- **Reproducibility cost.** Making inference reproducible "may involve some cost overhead" [S-0067]. For training, writing a checkpoint at every step would cost more than 100% overhead, which Amodo's design avoids by keeping a spare replica [S-0017].
- **Hidden work.** The plan notes that a company might try to encode a non-compliant workload inside one that looks compliant [S-0067]. Work outside declared packets, including on spare compute, is not covered [S-0067] [S-0017].
- **Dependencies.** The scheme relies on deterministic execution (Deterministic and bit-exact inference), complete traffic capture (Network taps and certifiers) and a secure recomputation server [S-0067].
Sources: [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-0017] Example Schemes for Verifying High-Stakes AI Agreements (2026) https://amododesign.com/notes/2026-06-23-verification-algorithms/; [S-1006] Scaling Recomputation Inference Verification (2026) https://amododesign.com/notes/2026-09-02-scaling-recomputation-inference-verification/; [S-1008] AI 2040 Plan A — Verification SITREP (2026) https://amododesign.com/ai-verification/plan-a-sitrep/

## Safeguard attestation (M-0023, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, low confidence. R2, narrowly. One prototype with public code attests a guardrail end to end on cloud enclaves. Nothing has been independently evaluated or relied on. - R1 met: designs that state the claim (a response was produced after a specific guardrail ran) and their trust assumptions are published [S-1500], alongside designs for attesting inference properties [S-0012] and plan-scoped monitoring [S-1503]. - R2 met through the proof-of-guardrail prototype. Its code is public [S-1501], and its authors report end-to-end results on production cloud enclave hardware (AWS Nitro Enclaves) against a stated adversary, a developer who skips or modifies the guardrail [S-1500]. PALM adds attested session inference on Intel TDX with an H100 GPU, but its properties do not cover safeguards [S-0012]. - R3 not met. Criterion (a) fails: no party other than a developer is documented as relying on safeguard attestation, and the code is described as a proof of concept that is not production-ready [S-1501]. Criterion (b) fails: no independent audit or red-team has been published, and the monitoring prototype has not been stress-tested by a counterparty [S-1504]. Confidence is low because the demonstration is far from a frontier serving stack. It reaches both its guardrail model and the agent's backend model through external APIs, attests only the responses for which attestation is offered, and runs on CPU enclaves [S-1500]. Its README states that the enclave does not yet restrict the agent's command execution, which could be used to bypass the guardrail [S-1501]. Intel TDX attestations have also been forged by attackers with physical access to the memory bus [S-1202].
Hardware-signed evidence that an AI service ran its declared safeguards, such as a guardrail classifier or monitor, when producing a given response.
Safeguard attestation aims to let users, auditors or other governments check that an AI service ran the safeguards it declares, such as a safety classifier, filter or usage monitor. Published designs run the safeguard inside a trusted execution environment (TEE), whose hardware signs a measurement of that code with a hash of each input and response. A research prototype with public code does this for an AI agent and an open-source guardrail on AWS Nitro Enclaves, though it calls the guardrail model through an outside API. Related work attests which model answered, and limits monitoring to a jointly signed plan. As of September 2026 no system has been independently evaluated or relied on by another party. The main obstacles are showing that all traffic took the attested path and scaling to frontier GPU clusters. Attestation shows a safeguard ran, not that it works: a guardrail can still be jailbroken.
## How it works

Users of AI services often have to rely on a developer's word about how safety is enforced, so safety measures could be falsely advertised [S-1500]. A paper on frontier AI auditing notes that swapping in a different safety classifier or relaxing a filter threshold can materially change how easily a system is misused [S-0003]. A governance analysis of trusted execution environments (TEEs) lists "policy adherence" as a property a verifier needs: a workload should show that it uses the approved model or enforces access controls and safeguards [S-0014].

The published designs follow one pattern: run the safeguard inside a TEE and have the hardware sign what ran [S-1500] [S-0012] [S-1503].

- **Proof of guardrail.** A wrapper program containing a public guardrail and its configuration mediates all of an agent's inputs and outputs inside the enclave [S-1500]. When a user asks for it, or the agent offers it, the enclave signs a document containing a hash of the wrapper and a hash of the input and response [S-1500] [S-1501]. A user compares the wrapper hash with the published open-source build and checks the signature offline, while the developer's agent stays private [S-1500].
- **Property attestation.** PAL\*M runs inference in a confidential virtual machine with a GPU, and attests that a response came from a specific model and tokenizer on a given query or chat history [S-0012]. Its defined inputs are the query, model and tokenizer; it has no separate safeguard input [S-0012].
- **Audit-to-deployment binding.** Attestable Audits returns, with each response, an attestation that links the model, its earlier audit result, the prompt and the response [S-0009]. Binding weights to attestation is covered in Model identity attestation.
- **Scoped monitoring.** The monitoring party and the monitored party co-sign a plan, which an open-source classifier runs inside an attested TEE [S-1503]. Queries outside the plan's scope are never evaluated [S-1503].

Two approaches do not use TEEs:

- **Verifier-side screening.** In a low-trust system design, the verifier re-executes sampled records and screens them itself for compliance, for example for blacklisted uses [S-0018]. See Sampled inference recomputation and Low-trust AI compute verification system overview.
- **Black-box testing.** Prompt Detective compares output distributions to judge whether a given system prompt was used [S-1502]. It was developed to detect reuse of proprietary prompts, not to audit declared safeguards [S-1502].

## What it establishes
It can establish:

- that the declared guardrail code ran for an attested response, without revealing the developer's agent [S-1500];
- that tampering is visible: in the authors' tests, modified guardrail code, modified attestation bytes and modified responses were all detected [S-1500];
- in scoped monitoring, that the monitor evaluated only what the co-signed plan allows [S-1503].

It cannot establish:

- that the safeguard works, since guardrails make errors and can be jailbroken [S-1500];
- that all traffic was covered, since attestations are per response and the prototype offers them for high-stakes questions [S-1500];
- anything the measurement leaves out, such as configuration, flags or later changes at runtime [S-0014].

## Threat model
- **Proof of guardrail** assumes a developer who might skip or modify the guardrail [S-1500]. It trusts the cloud provider's enclave hypervisor to measure code and protect keys, and it needs an open-source guardrail so that verifiers know the expected measurement [S-1500].
- **PAL\*M** assumes an adversary who controls the host, hypervisor and disk [S-0012]. It trusts the Intel TDX module and the H100 GPU [S-0012]. It treats side-channel defences as orthogonal and places physical attacks, such as memory-bus interposition, out of scope [S-0012].
- **Treaty setting.** A governance analysis contrasts the confidential-computing adversary, a dishonest operator, with a treaty adversary: a state with physical access to data centres and leverage over hardware vendors [S-0014].

## Evidence
- **Proof of guardrail.** The authors implemented it for OpenClaw agents on AWS Nitro Enclaves, with Llama Guard 3 for content safety and a fact-checking tool [S-1500]. They report 34% added latency on average compared with running outside the enclave [S-1500]. The code is public; its README calls it a proof of concept that is not production-ready [S-1501].
- **PAL\*M.** Implemented on Intel TDX with an NVIDIA H100 [S-0012]. The authors report 3.8–11.4% overhead for session inference over the same machine without PAL\*M, and they modelled the protocol formally with the Tamarin prover [S-0012].
- **Attestable Audits.** A prototype ran a 4-bit 8-billion-parameter model in CPU-only AWS Nitro Enclaves at 1.84 tokens per second [S-0009].
- **Scoped monitoring.** A reference implementation runs in Tinfoil confidential virtual machines [S-1504]. Its authors state that user data and plan execution in the demo are not actually secure, and that the system has not been stress-tested by a counterparty [S-1504].

## Limitations
- **Effectiveness gap.** An attested guardrail can still be jailbroken [S-1500].
- **Selective attestation.** Provers might attest only favourable executions [S-0012] [S-1500].
- **Outside the boundary.** The prototype called its guardrail model and backend model through external APIs [S-1500].
- **Hardware attacks.** With physical access to the memory bus, researchers forged Intel TDX attestations and, by pairing them with relayed H100 attestations, made a workload outside TEE protection pass as GPU confidential computing [S-1202]. Other attacks forged AMD SEV-SNP attestations, one through a DDR4 interposer and one from software alone before AMD's fix [S-1210] [S-1212].
- **Scale.** Frontier model inference typically needs several GPUs [S-0014]. CPU inference, which the enclave prototype had to use, cost 21.7 times as much per token as GPU inference and ran about 100 times slower [S-0009].

For confidential workflows that combine several parties' private inputs, see Confidential multi-party verification.
Technical detail: - Proof-of-guardrail protocol. (1) A wrapper program f bundles the public guardrail g, its configuration and the mediation of all agent inputs and outputs. (2) When f is loaded, the enclave records a measurement m, a hash that depends on the binary of f. (3) The private agent is loaded afterwards as a secret input, so it is not part of m. (4) For a user input x and response r, f returns a document signed with the platform's attestation key that contains m and d = Hash(x, r). (5) The verifier checks the certificate chain against the platform's published root, compares m with the expected measurement of the open-source f, and checks d [S-1500]. - Prototype costs. On AWS Nitro Enclaves, the authors report 34% added latency on average over the same agent and guardrail run outside the enclave, 97.8 ms to generate an attestation and 5.1 ms to verify it. Holding the whole guardrail runtime in enclave memory needs an m5.xlarge instance, which costs 18.5 times as much per hour as a t3.micro [S-1500]. - PALM. It defines single and session inference properties, r = M(Mtok(q)) and its multi-turn form over the chat history. It binds hashes of the query, tokenizer, model and response into an Intel TDX quote, together with an NVIDIA H100 attestation token and a verifier challenge [S-0012]. Compared with the same TDX machine without PALM's measurements, session inference cost 3.8–11.4% more and single-prompt inference 45.5–66.4% more, across Llama-3.1-8B, Gemma-3-4B and Phi-4-Mini [S-0012].
Sources: [S-1500] Proof-of-Guardrail in AI Agents and What (Not) to Trust from It (2026) https://arxiv.org/abs/2603.05786; [S-1501] Verifiable-ClawGuard: proof-of-guardrail reference code (2026) https://github.com/SaharaLabsAI/Verifiable-ClawGuard; [S-0012] PAL*M: Property Attestation for Large Generative Models (2026) https://arxiv.org/abs/2601.16199; [S-0009] Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments (2025) https://arxiv.org/abs/2506.23706; [S-1503] Enabling Verifiably-Scoped Monitoring through Large Language Models and Trusted Compute (2026) https://icml.cc/virtual/2026/78630; [S-1504] Auditor-in-a-Box: Tools for Third-Party Auditing (2026) https://www.lesswrong.com/posts/uWYk7MM9hAf9GEbGe/auditor-in-a-box-tools-for-third-party-auditing; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance; [S-0003] Frontier AI Auditing: Toward Rigorous Third-Party Assessment of Safety and Security Practices at Leading AI Companies (2026) https://arxiv.org/abs/2601.11699; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-1502] Has My System Prompt Been Used? Large Language Model Prompt Membership Inference (2025) https://arxiv.org/abs/2502.09974; [S-1202] TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (2026) https://tee.fail/; [S-1210] Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing (2026) https://batteringram.eu/; [S-1212] RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP (2025) https://rmpocalypse.github.io/; [S-1213] SEV-SNP RMP Initialization Vulnerability (AMD-SB-3020) (2025) https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3020.html; [S-0013] How Tinfoil Proves Exactly What Model Is Running (2026) https://tinfoil.sh/blog/2026-02-03-proving-model-identity

## Sampled inference recomputation (M-0001, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2. Public code and reproducible results exist, but no one has independently evaluated the check. Assessed for checking that recorded outputs came from the declared model and settings (The declared model is the one being served). - R1 met: the design, the claim it verifies and its trust assumptions are published. They include a formal security game for steganographic weight exfiltration [S-0015]. - R2 met through DiFR and TOPLOC, both assessed R2. DiFR has MIT-licensed code with a vLLM integration [S-1005]. It has reproducible results on A100 and H200 GPUs with models of 8 to 30 billion parameters [S-0016]. TOPLOC is an installable package [S-1001] with peer-reviewed results [S-1000]. Rinberg et al. evaluate the method against a stated adversary who controls the inference server [S-0015]. - R3 not met. Criterion (a), reliance by another party or production-grade availability, is arguable. TOPLOC is publicly available, and its developer uses it to accept or reject work from untrusted nodes [S-1001] [S-1003]. No other party is documented relying on sampled recomputation for a verification decision. Criterion (b), an independent evaluation, fails. As of September 2026 no independent audit, red-team or peer-reviewed security analysis of the consistency check has been published. Amodo lists recomputation red-teaming as not started [S-1008]. The one independent attack study targets the weight-exfiltration bound built on this mechanism [S-1507]. That bound is a supporting use, assessed under Bounding unexplained information in outputs.
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.
Sampled inference recomputation is a check that an AI provider's recorded outputs came from the model and settings it declared. The provider logs each query and response. A verifier's server re-runs a random sample on a trusted copy of the model. It flags outputs that differ by more than benign numerical noise allows. Checking costs less than generating because the verifier processes each sequence in one pass. Two schemes, TOPLOC and DiFR, have public code. DiFR has reproducible results on A100 and H200 GPUs with models of 8 to 30 billion parameters. TOPLOC's developer uses it to accept or reject work from untrusted computers. No independent red-team of the check has been published. Deployment needs full traffic capture and a secure verifier server inside the provider's facility. Unrecorded work is never checked. The noise tolerance also leaves a covert channel. An adversary who controls the prompts can widen it.
## How it works

The provider records its inference traffic, and a verifier re-runs a random sample of it. The provider's serving system logs each request and response with the exact model release, code version and random seed used [S-0015]. Proposals for verifying international agreements use passive network taps on the front-end network to copy all input and output traffic to a recomputation server [S-0067]. A verification server then re-runs a random subset of the logged inferences with a trusted copy of the model and code [S-0015].

Checking is cheaper than generating [S-0015]. The verifier feeds the prompt and the claimed output through the model as one sequence. This gives the model's predictions for every position at once [S-0016]. Generation must produce tokens one at a time, which typically uses hardware 3–5 times less efficiently than the single pass [S-0015].

The comparison must tolerate numerical noise. Re-running the same inference often gives slightly different results, because floating-point arithmetic is not associative [S-0016] [S-0017]. Published schemes handle this in three ways:

- TOPLOC compares activation fingerprints. The provider records a compact encoding of the largest last-layer activations. The verifier accepts if its recomputed values differ by less than preset thresholds [S-1000] [S-0017].
- Token-DiFR, part of DiFR, checks tokens under a shared sampling seed. The verifier scores how far each claimed token departs from the token the reference model would have chosen [S-0016].
- Exact replay needs no tolerance. Recomputation can match bit for bit if the verifier knows the hardware model, deployed weights, parallelism layout, software versions and batch size [S-0018] [S-0020].

A modest random sample gives statistical assurance about the whole recorded stream [S-0018] [S-0067]. For example, if 0.1% of outputs are false, checking 3,000 random samples finds at least one with 95.03% probability [S-0018].

## What it establishes

Sampled recomputation can establish two things:

- It can show that recorded outputs are consistent with the declared model and settings. In DiFR's experiments, recomputation detected 4-bit quantization, a quantized key-value cache, a wrong temperature, a wrong seed and simulated sampling bugs [S-0016]. TOPLOC detected changes to the model, the prompt and the numerical precision [S-1000].
- It can limit how much information a compromised server can hide in its responses [S-0015].

It cannot establish three things:

- It checks only recorded workloads, so it cannot show that no other workloads ran unrecorded [S-0017]. Rinberg et al. say their weight-exfiltration scheme cannot be a defence on its own [S-0015].
- Schemes that tolerate small differences can bound an adversary's covert bandwidth but cannot close it [S-0020].
- Checks based only on activations cannot verify that tokens were sampled correctly [S-0016].

## Threat model

The adversary controls the inference server [S-0015]. Rinberg et al.'s exfiltration study makes these trust assumptions, among others [S-0015]:

- There are no side channels.
- The verification code is trusted.
- The log is secure and append-only.
- Input and output messages are paired.
- The adversary can neither see nor manipulate the sample selection.

The study's published bound assumes benign prompt traffic, and an adversary who controls the prompts can widen it [S-1507]. The verification server's isolation can range up to a full air gap [S-0015].

The prover must cooperate. It must let the verifier install a recomputation server in its data centre [S-0017]. The verifier must hold the model weights and know the provider's sampling procedure [S-0016]. Tolerance thresholds come from calibration runs on trusted hardware [S-0016]. One low-trust system design treats physical security of the installed devices as a prerequisite [S-0018].

## Evidence

- **DiFR** detected 4-bit quantization with an AUC above 0.999 within 300 output tokens in its authors' tests [S-0016]. They tested Llama 3.1 8B, Qwen3-8B and Qwen3-30B-A3B on A100 and H200 GPUs, with and without tensor parallelism [S-0016]. The code is public [S-1005].
- **TOPLOC** had no false positives or negatives in the evaluations reported in its peer-reviewed paper. The hardware tests used A100 and RTX 4090 GPUs [S-1000]. Prime Intellect reports using TOPLOC to verify work from untrusted inference workers in a decentralized training run. It evicted nodes whose work failed the checks [S-1003].
- **Rinberg et al.** tested weight-exfiltration detection on open-weight models of 3 to 30 billion parameters [S-0015]. On a 30-billion-parameter mixture-of-experts model under benign prompt traffic, they report that their detector cut exfiltratable information to under 0.5% at a false-positive rate below 0.01%. That slows an adversary more than 200-fold [S-0015]. An independent study found that choosing the prompts roughly doubles the leakage per token and cuts the slowdown to 60–118 times [S-1507].
- **Amodo** re-implemented DiFR with a traffic-capturing proxy and a ledger on Kubernetes [S-1006] [S-1007]. It tested models of 1.5 to 120 billion parameters on H100 and H200 GPUs and reported a 2–8 times performance advantage for the verifier [S-1006]. Of 14,891 events, 13,489 passed and 1,402 failed. Amodo's note does not give the cause of the failures [S-1006]. Amodo also reports that TOPLOC and DiFR are well described and are now being tested on relevant hardware and models [S-1008].

## Limitations

- Tolerance margins leave a small covert channel [S-0020] [S-0015]. An adversary who controls the prompts can widen it [S-1507].
- Benign differences between A100 and H200 deployments made the smallest tested deviation harder to detect [S-0016].
- DiFR's authors show that tuning the sampling temperature fools a naive cross-entropy check. Token-DiFR still detects the change [S-0016].
- TOPLOC's authors state it cannot detect speculative decoding with a cheaper model [S-1000]. Amodo expects recomputation algorithms to need updating as model architectures and inference techniques change [S-1008].
- TOPLOC's authors name spoofed last-layer activations and deliberately "unstable" prompts as possible attacks, which remain untested [S-1000].
- A mismatch does not reveal whether evasion, a hardware fault or an evaluation error caused it [S-0018].
- Amodo rates recomputation red-teaming as not started, and security of the recomputation server as not on track [S-1008].

Zero-knowledge proofs of inference are an alternative. They need deterministic computation as a precondition [S-0020].
Technical detail: The reference protocol has five steps [S-0015]: 1. The serving stack writes every request and response to an append-only log, with the model release, code version and sampling seed [S-0015]. 2. An isolated verification server draws a private random sample of logged pairs. Its isolation can range from access controls and containers to a full air gap [S-0015]. 3. The server runs one prefill pass over the prompt and claimed output with the trusted model and code. This gives the next-token distribution at every position [S-0015] [S-0016]. 4. The server scores how far the claimed output diverges from the reference. Token-DiFR uses the clipped Gumbel-Max logit margin under a shared seed. Activation-DiFR uses the distance between random projections of activations [S-0016]. TOPLOC counts exponent and mantissa mismatches in the top-128 last-layer activations [S-1000]. 5. Scores beyond a threshold calibrated on trusted hardware are escalated for review [S-0015] [S-0016]. Verification is cheap because it needs only the prefill pass. Decoding typically runs at 3–5 times lower hardware utilization than prefill [S-0015]. Amodo's prototype measured a 2–8 times performance advantage for the verifier with models of 1.5 to 120 billion parameters on H100 and H200 GPUs [S-1006]. The number of samples sets the chance of detection. For a false-output rate p, the chance of catching at least one false output in k independent samples is 1 − (1 − p)^k [S-0020]. With 3,000 samples, a 0.1% rate is caught with 95.03% probability [S-0018]. Recomputation can also match bit for bit, which makes the check pass/fail. This exact variant needs a known hardware model, deployed weights, parallelism topology, software versions and per-pass batch size, and no atomic operations [S-0018] [S-0020].
Sources: [S-0015] Verifying LLM Inference to Detect Model Weight Exfiltration (2025) https://arxiv.org/abs/2511.02620; [S-0016] DiFR: Inference Verification Despite Nondeterminism (2025) https://arxiv.org/abs/2511.20621; [S-0017] Example Schemes for Verifying High-Stakes AI Agreements (2026) https://amododesign.com/notes/2026-06-23-verification-algorithms/; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0020] Bit-Exact AI Inference Verification Without Performance Tradeoffs (2026) https://arxiv.org/abs/2606.00279; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-1000] TOPLOC: A Locality Sensitive Hashing Scheme for Trustless Verifiable Inference (2025) https://proceedings.mlr.press/v267/ong25a.html; [S-1001] PrimeIntellect-ai/toploc (GitHub repository) (2025) https://github.com/PrimeIntellect-ai/toploc; [S-1003] INTELLECT-2: A Reasoning Model Trained Through Globally Decentralized Reinforcement Learning (2025) https://arxiv.org/abs/2505.07291; [S-1005] adamkarvonen/difr (GitHub repository) (2025) https://github.com/adamkarvonen/difr; [S-1006] Scaling Recomputation Inference Verification (2026) https://amododesign.com/notes/2026-09-02-scaling-recomputation-inference-verification/; [S-1007] Amodo-Design/Inference-Recomputation-Prototype (GitHub repository) (2026) https://github.com/Amodo-Design/Inference-Recomputation-Prototype; [S-1008] AI 2040 Plan A — Verification SITREP (2026) https://amododesign.com/ai-verification/plan-a-sitrep/; [S-1507] Adversarial Entropy Inflation Against Gumbel-Based Inference Verification (2026) https://arxiv.org/abs/2608.23375

## Side-channel suppression for isolated facilities (M-0022, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1: one public design study with costs and assumptions; nothing has been built or measured. - R1 met: Cankaya publicly describes a design with its goal (bounding covert capacity around a verified enclosure to a tolerable rate), the channel classes it addresses, defences, cost estimates and assumptions [S-0038]. - R2 not met: Cankaya describes the work as a two-week research sprint that is far from conclusive, and calls for prototyping and red-teaming [S-0038]. Components such as shielded enclosures and commercial power-line filters exist as products [S-0038], but as of September 2026 no integrated build for an AI facility, or measurement of one, has been published. The mechanism's implementations, RAND secure inference data center (SIDC) design, AI 2040 inference-only verification stack and Low-trust AI compute verification system overview, are proposed architectures at R1. Confidence is medium: a single tier C source carries the design, but its author states plainly that nothing has been prototyped.
Shielding, filtering, jamming and inspecting an AI facility so that no hidden physical channel can bypass the checks placed on its official links.
Some verification designs watch every official network link out of an AI cluster. They only work if data cannot leave or enter by another route, such as radio emissions, sound, vibration or signals on power lines. Side-channel suppression retrofits the facility with metal enclosures, filters, jamming, vibration isolation and inspections. The aim is to push any hidden channel's capacity down to a tolerable few kilobits per second. One published design estimates the cost at about 0.1–0.5% of hardware cost. Its author calls it a first-pass study. As of September 2026 no build has been prototyped, measured or red-teamed; that validation gap is the main obstacle. The biggest known weaknesses are hardware implanted in the supply chain, which inspection may miss, and the difficulty of keeping shielding intact around airflow, cabling and optical links.
## How it works

Several verification designs place checks on the official links of an AI cluster, for example network taps between accelerators (Network taps and certifiers) [S-0038]. Cankaya points out that these checks only hold if the facility cannot move significant data by some other physical route [S-0038]. Side-channel suppression retrofits an untrusted facility so that any such route has negligible capacity [S-0038].

Cankaya surveys these classes of physical channel [S-0038]:

- electromagnetic radiation, through the air and through optical fibre;
- airborne acoustics;
- acoustic signals carried through solids and through coolant water;
- signals conducted along power lines and water columns;
- physical access, such as covert devices.

Instead of eliminating every channel, the design accepts a small residual rate, in the single-digit kilobits per second, to keep defence costs manageable [S-0038]. It reasons from information theory: a channel's capacity depends on its bandwidth and its signal-to-noise ratio, so defences either weaken the signal or raise the noise [S-0038].

The proposed defences, grouped by channel, are [S-0038]:

- **Electromagnetic.** Sheet-metal enclosures with bent cable conduits, metal barriers between racks, directional radio jamming, and radio sensors that monitor during or between jamming.
- **Power lines.** Commercial TEMPEST-grade filters.
- **Optical fibre.** Optical-electrical-optical conversion at the enclosure boundary, and inspection for undeclared optical components.
- **Acoustic.** Enclosures and air vents that do not face each other, plus air gaps and vibration isolation between and under racks.
- **Inspection.** Guards, unannounced inspections and destructive teardowns looking for hidden antennae.

## What it establishes
If it works as designed, suppression bounds the capacity of unmonitored physical channels out of an enclosure [S-0038]. Other checks can then treat the monitored links as the only significant path for data (Bandwidth limits and compartmentalization, Bounding unexplained information in outputs) [S-0038].

It does not establish:

- **What the computation is.** It only makes the other verification layers harder to bypass [S-0038].
- **Zero leakage.** The design deliberately tolerates single-digit kilobits per second [S-0038].

Side-channel attacks on verification hardware itself are a separate concern [S-0007]. Ansari notes that differential power analysis and electromagnetic attacks on compact cryptographic implementations are within reach of commercially available tooling [S-0007].

## Threat model
- **Adversary.** Cankaya assumes a well-resourced, nation-state adversary constrained only by physics [S-0038]. He argues that verification favours the defender because "the attacker loses if caught even once" [S-0038].
- **Physical security.** Physical security involves several organizations and includes guards and unannounced inspections [S-0038].
- **Inspection.** Inspections of sampled units catch any flaw present, which allows statistical bounds from sampling [S-0038].

## Evidence
Peer-reviewed attacks show that ML hardware leaks information through physical side channels:

- **BarraCUDA** used correlation electromagnetic analysis to recover parameters of convolutional networks running on NVIDIA Jetson devices [S-0043].
- **Kraken** extracted parameters from GPU Tensor Core units, and showed that GPU electromagnetic radiation leaks even 100 cm away through a glass obstacle [S-0044].
- **DeepTheft** recovered the structure of DNN models on general-purpose processors through the RAPL power interface, reporting 99.75% Levenshtein-distance accuracy [S-0046].

These attacks show leakage, not deliberate covert signalling [S-0043] [S-0044] [S-0046]. Cankaya also surveys published covert-channel demonstrations across the channel classes above [S-0038].

For suppression itself, the evidence is one paper design [S-0038]. It estimates $35,000–$150,000 per 8-rack scalable unit, about 0.1–0.5% of hardware cost at an assumed $4 million per rack [S-0038]. Cankaya describes it as a first-pass viability study and asks for prototypes and adversarial feedback [S-0038].

## Limitations
- **Untested design.** It has not been prototyped or red-teamed [S-0038].
- **Supply-chain implants.** Hardware implanted in purchased components may evade inspection [S-0038].
- **Openings.** Airflow, power cabling and optical links complicate shielding [S-0038].
- **Inspection limits.** It is unclear whether destructive teardown favours defender or attacker [S-0038].
- **Cost uncertainty.** Filter costs vary widely, and optical conversion depends on the supply of many high-performance transceivers per pod [S-0038].
- **Deterrence assumptions.** Keeping sensor capabilities unknown to the prover may deter attacks, but it makes the adversary assumptions hard to test [S-0038].
Technical detail: - Capacity target. Cankaya frames suppression with the Shannon-Hartley limit C = B log2(1 + SNR). Defences either lower the signal power or raise the noise floor. Holding capacity to 1 kbit/s over 1 GHz of bandwidth needs an SNR of about −62 dB or less [S-0038]. - Shielding. Enclosures built to NSA specification 94-106 are cited at −100 dB of attenuation from 100 MHz to 10 GHz [S-0038]. Cable conduits should have at least two right-angle turns, and each turn gives an estimated 15–25 dB of diffraction loss at ultrasonic wavelengths. Air vents should not face each other [S-0038]. - Jamming and monitoring. Radio monitoring can run behind jamming using continuous or interrupted look-through, and a commodity-radio demonstration of continuous look-through is cited at 39 dB of suppression [S-0038]. - Cost. Each 8-rack scalable unit has 64 power cables ("whips") to filter. Cankaya's bill of materials for one scalable unit totals $35,000–$150,000, about 0.1–0.5% of the hardware cost at an assumed $4 million per rack [S-0038].
Sources: [S-0038] Suppressing Side Channels in an Untrusted Data Center via Retrofitted Defenses (2026) https://techgov.intelligence.org/blog/suppressing-side-channels-in-an-untrusted-data-center-via-retrofitted-defenses; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0043] BarraCUDA: Edge GPUs do Leak DNN Weights (2025) https://www.usenix.org/conference/usenixsecurity25/presentation/horvath; [S-0044] Kraken: Higher-order EM Side-Channel Attacks on DNNs in Near and Far Field (2026) https://arxiv.org/abs/2603.02891; [S-0046] DeepTheft: Stealing DNN Model Architectures through Power Side Channel (2024) https://doi.org/10.1109/SP54263.2024.00250; [S-0007] Hardware-Level Governance of AI Compute: A Feasibility Taxonomy for Regulatory Compliance and Treaty Verification (2026) https://arxiv.org/abs/2604.04712

## Tamper evidence for verifier devices (M-0017, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2: peer-reviewed tamper-detection results exist under stated adversaries, one in a running server, but no enclosure has been built or evaluated for AI verifier devices. - R1 met: enclosure designs with stated attacker models are published [S-1315] [S-0052], and the MIRI overview describes their role in protecting verification hardware in a host-controlled facility [S-0018]. - R2 met: published end-to-end results exist under a stated adversary. Anti-Tamper Radio reliably detected needle insertions in a running 19-inch server over a 10-day experiment [S-0052]. Immler et al. report statistics over 115 batteryless covers, plus physical attacks against a stated 300 µm penetration model and environmental tests [S-1315]. On-chip impedance sensing detected board- and package-level tampering on commercial FPGA kits [S-0051]. All three are peer-reviewed; no public code or design files are cited for them. - R3 not met for this use: production-grade, independently validated tamper-respondent modules exist (the IBM 4765 is validated at FIPS 140-2 Level 4) [S-0050], and tamper-indicating enclosures are used in safeguards and arms control [S-1316]. None has been built for, or evaluated on, AI verifier devices such as optical taps, FPGA gateways or recomputation servers. The MIRI overview lists "tamper-evident, rapidly mass-manufacturable and retrofittable enclosures" as an open research question [S-0018]. The mechanism's only implementation, AI 2040 inference-only verification stack, is a proposed architecture at R1. Confidence is medium, because how far the server-scale and HSM results transfer to AI verifier hardware is a judgment call.
Enclosures, seals and sensors that make physical interference with verification hardware either visible or self-defeating.
Verification devices such as network taps, gateways and recomputation servers would sit in facilities controlled by the party being checked. Tamper-evident and tamper-resistant enclosures aim to make physical interference visible, or to destroy secrets when it happens. Tamper-respondent modules such as the IBM 4765 are validated at FIPS 140-2 Level 4 and erase their secrets when breached. Nuclear safeguards and arms control use tamper-indicating enclosures. Peer-reviewed prototypes detect probing through capacitive covers, radio waves inside server cases, or on-chip impedance sensing. As of September 2026 none has been built or evaluated for AI verifier hardware, and the MIRI overview lists retrofittable, mass-manufacturable enclosures as an open problem. The main obstacles are scale, batteries and inspection burden. The largest known weakness is that seals are often defeated with simple methods: a 1996 Los Alamos study defeated all 94 seals it examined. Any enclosure is only as good as its inspection protocol.
## How it works

Verification hardware placed in a facility run by the party being checked needs protection against physical interference [S-0018]. The MIRI system overview relies on monitoring of the facility and on occasional random inspections of analog components and anti-tamper seals [S-0018]. Obermaier and Immler review enclosures from battery-backed monitoring to PUF-based designs [S-0049]. Published approaches fall into four groups:

- **Tamper-respondent modules.** The IBM 4765 coprocessor uses a "protective, tamper-respondent matrix to monitor for intrusion and adverse physical conditions" [S-0050]. On a hard tamper, it actively erases its core secrets within microseconds [S-0050].
- **Batteryless tamper-resistant covers.** Immler et al. wrap the protected system in a flexible circuit-board cover with a fine electrode mesh [S-1315]. A key is derived from the mesh's capacitances, which act as a physical unclonable function (PUF), and decrypts the system's sensitive data only if the cover is intact [S-1315].
- **System-level sensing.** Anti-Tamper Radio monitors how radio waves propagate inside a metal case, so inserted objects change the measured response [S-0052]. ImpedanceVerif uses on-chip network analyzers on FPGAs to detect changes in a board's power distribution network, "without any modifications to the system" [S-0051].
- **Tamper-indicating enclosures.** In safeguards and arms control, these leave physical evidence of attack [S-1316]. They cover the case where an adversary bypasses a sealed opening, for example by drilling through a side [S-1316].

In AI proposals, flexHEG pairs a guarantee processor with "a secure enclosure providing physical tamper protection" [S-0035]; see Hardware-enabled guarantees (flexHEG) and guarantee processors. The AI 2040 plan lists tamper-evident enclosures among physical security measures [S-0067]. The MIRI overview notes that standards exist for secure facilities (SCIFs) [S-0018]. What is less established, it says, is "what defenses can be retrofitted at a massive scale to prevent bypassing of network taps" [S-0018].

## What it establishes
Enclosures can show that a device was physically accessed [S-1316], or can make a breach destroy the keys or data an attacker wants [S-0050] [S-1315]. They protect the integrity of other mechanisms, such as taps (Network taps and certifiers) and bandwidth shapers (Bandwidth limits and compartmentalization), rather than proving a claim on their own [S-0018]. Johnston argues that "a seal is no better than the protocols for using it" [S-1318].

## Threat model
- **Cover.** Immler et al. "assume penetrations to be at least 300µm in diameter" [S-1315]. They deem cover removal impractical and do not assess chemical solvents [S-1315].
- **Radio sensing.** Anti-Tamper Radio defines success for the attacker as inserting a needle into a sensitive region without detection [S-0052].
- **AI facilities.** The host controls the facility, so the MIRI overview combines enclosures with continuous monitoring and random inspection [S-0018].

## Evidence
- **IBM 4765.** Validated at FIPS 140-2 Level 4, overall and for physical security [S-0050].
- **Batteryless covers.** Immler et al. report statistics over 115 flexPCB covers, physical attacks and environmental testing, aiming at a physical security level comparable to FIPS 140-2 Level 3 [S-1315].
- **Anti-Tamper Radio.** In a running 19-inch server over 10 days, it reliably detected 40 mm insertions of 1 mm needles [S-0052].
- **ImpedanceVerif.** It detected tampering on commercial FPGA development kits, including the proximity of contactless EM probes and a slightly polished chip package [S-0051].
- **Tamper-indicating enclosures.** They support IAEA safeguards and arms-control chain-of-custody regimes [S-1316].

As of September 2026 no enclosure for AI verifier hardware has been evaluated in public. The MIRI overview lists "tamper-evident, rapidly mass-manufacturable and retrofittable enclosures" as an open question [S-0018].

## Limitations
- **Seal defeats.** In 1996 a Los Alamos team defeated all 94 seals it examined, with 132 defeats using low-tech methods; one practised person needed 4.3 minutes on average [S-1317]. Johnston reports that "high-tech seals are often easier to defeat than low-tech seals" [S-1318].
- **Batteries.** Battery-backed designs add bulk, limit the operating temperature range and fail when discharged [S-1315].
- **Inspection and power.** Visual methods on large enclosures face access limits, active approaches need power, and sensor data must be authenticated [S-1316].
- **Drift.** Anti-Tamper Radio's reference measurement can drift as the environment or the measurement system ages, which the authors suggest handling by gradually renewing the reference [S-0052].
Technical detail: - IBM 4765. FIPS 140-2 Level 4 overall and for physical security. A tamper-respondent matrix monitors for intrusion and adverse conditions, with moderate and severe out-of-range temperature and voltage sensing. A hard tamper triggers active wiping of secrets: the high-speed-erase battery-backed RAM holding core secrets is erased within microseconds, and the module is zeroized and left inoperable [S-0050]. - Batteryless PUF cover. A 140 mm × 140 mm flexPCB cover with 16 × 16 electrodes (256 sensor nodes, 128 used differentially) and 100 µm line and space, checked by an STM32F303 microcontroller. After open- and short-circuit checks pass, a key is derived from the differential capacitances, about 5.2 bits of entropy per node with 10x oversampling (about 665 bits in theory). The attacker model assumes penetrations of at least 300 µm; single 0.3 mm holes made key reconstruction infeasible; a full-cover measurement with 10x oversampling takes 384 ms; power is about 0.6 W; testing spanned −20 °C to +60 °C [S-1315]. - Anti-Tamper Radio. Two wideband antennas inside a metal case, measured with a vector network analyzer (2–9 GHz) or ultra-wideband transceivers (2.496–7.488 GHz). In a Dell PowerEdge 2850 over 10 days, 40 mm insertions of 1 mm needles were reliably detected; in an empty aluminium box, 16 mm insertions of needles as thin as 0.1 mm were detected. UWB transceivers cost less than US$5 [S-0052]. - ImpedanceVerif. An embedded network analyzer on an FPGA measures the frequency response of the power distribution network, and Wasserstein distance is used as the detection statistic [S-0051].
Sources: [S-0050] IBM 4765 Cryptographic Coprocessor Security Module: Security Policy (2012) https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp1505.pdf; [S-0049] The Past, Present, and Future of Physical Security Enclosures: From Battery-Backed Monitoring to PUF-Based Inherent Security and Beyond (2018) https://link.springer.com/article/10.1007/s41635-018-0045-2; [S-1315] Secure Physical Enclosures from Covers with Tamper-Resistance (2019) https://tches.iacr.org/index.php/TCHES/article/view/7334; [S-0052] Anti-Tamper Radio: System-Level Tamper Detection for Computing Systems (2022) https://ieeexplore.ieee.org/document/9833631/; [S-0051] ImpedanceVerif: On-Chip Impedance Sensing for System-Level Tampering Detection (2023) https://eprint.iacr.org/2022/946; [S-1316] Tamper-Indicating Enclosures, A Current Survey (2015) https://www.osti.gov/servlets/purl/1256541; [S-1317] Physical Security and Tamper-Indicating Devices (1996) https://www.osti.gov/servlets/purl/459707; [S-1318] Tamper Detection for Safeguards and Treaty Monitoring: Fantasies, Realities, and Potentials (2001) https://www.nonproliferation.org/wp-content/uploads/npr/81john.pdf; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-0035] Flexible Hardware-Enabled Guarantees for AI Compute (2025) https://arxiv.org/abs/2506.15093

## TEE remote attestation for AI workloads (M-0008, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2. Working implementations run on current GPUs, but the independent evaluations left critical flaws open. Assessed for verification by a party that does not trust the operator, including one that physically holds the hardware, and not for commercial confidentiality against software-only attackers. - R1 met: designs with stated claims and assumptions are published for audits, property attestation and policy enforcement [S-0009] [S-0012] [S-0014]. - R2 met through Tinfoil's model-identity chain. It is an open-source production deployment on NVIDIA H100, H200 or B200 GPUs with AMD SEV-SNP or Intel TDX (provider-reported) [S-1206] [S-1208] [S-1209]. Attestable Audits and PALM add end-to-end results against stated adversaries [S-0009] [S-0012]. - R3 not met. The first criterion, production-grade availability, holds in the commercial sense, because GPU confidential computing is a documented product feature [S-1200]. The second criterion fails. The independent public evaluations (TEE.fail, Battering RAM, WireTap and RMPocalypse) all found critical flaws, and the three that need physical access remain open. TEE.fail used physical access, root privileges and under $1000 of equipment to extract a CPU's Intel attestation signing key and forge TDX attestations. Paired with relayed H100 attestations, the forgeries let a workload outside TEE protection pass both checks [S-1202]. On DDR4 servers, Battering RAM and WireTap forged SGX attestations with interposers costing under $50 and under $1000, and Battering RAM also broke SEV-SNP attestation [S-1210] [S-1211]. These physical attacks defeat the main claim when the prover controls the hardware. NVIDIA lists sophisticated physical attacks as out of scope [S-1200]. Intel and AMD treat interposer and other physical attacks on memory as out of scope, according to the researchers [S-1202] [S-1210] [S-1211]. RMPocalypse forged SEV-SNP attestations from a malicious hypervisor, with no physical access [S-1212]. AMD reports firmware fixes for it [S-1213]. The breaks do not invalidate the R2 evidence, which concerns working implementations on realistic hardware.
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.
TEE remote attestation lets a remote party check which software processed an AI workload. A trusted execution environment (TEE) isolates a workload from the machine's operator and signs a report of the code and configuration it loaded. NVIDIA's Hopper and Blackwell GPUs support this when paired with Intel TDX or AMD SEV-SNP confidential virtual machines. Research prototypes use it to show which model produced a result without revealing weights, and Tinfoil reports running a production inference service on it. It is not ready for verification between rival states, where the party being checked holds the hardware. The chip vendors treat sophisticated physical attacks as out of scope. Independent researchers with memory-bus devices costing under $50 to under $1000 forged Intel and AMD attestations, and a software-only attack forged AMD attestations until AMD patched it. An attestation covers one deployment at launch, and trust rests on a few hardware vendors.
## How it works

A trusted execution environment (TEE) is a hardware-enforced boundary around a computation. TEEs aim to protect confidentiality and integrity even from an attacker who controls all of the host's software [S-1202]. In a confidential virtual machine (CVM), the CPU encrypts the VM's memory so that the hypervisor and other privileged software cannot read or tamper with it [S-1207].

The hardware measures each piece of software before it runs. It signs a report of those measurements with keys that chain to the manufacturer [S-1206]. A remote verifier checks the signature chain back to the vendor's root certificate. It then compares the measurements with expected values, which may come from reproducible builds published to a transparency log [S-1207].

NVIDIA extends attestation to its GPUs. In NVIDIA's description, an on-die root of trust checks the GPU's fused identity key and permits only signed firmware. The driver then opens an authenticated session with the GPU and obtains a signed attestation report [S-1200] [S-1201]. The GPU must be paired with a CPU TEE, either Intel TDX or AMD SEV, and NVIDIA recommends SEV-SNP [S-1200].

Other designs attest the accelerator alone. GuardAIn gives a discrete neural processing unit (NPU) measured boot and task attestation without relying on a CPU TEE [S-0010].

Several verification schemes build on these reports:

- **Attestable Audits** has the model provider and the auditor each send encrypted inputs to an enclave. The enclave runs the audit and publishes an attestation that links the model hash, the audit and the result. Later inference is checked against the audited hash [S-0009].
- **PAL\*M** attests dataset, training, fine-tuning, evaluation and inference operations on Intel TDX with an H100 [S-0012].
- **Tinfoil** binds the served weights to the attestation, as described under Model identity attestation [S-0013].
- **Gloria Z** proposes running auditable, reproducibly built software inside a CVM to enforce access control, audit logging and safety classifiers [S-0014].
- **The Future of Life Institute (FLI) and Mithril Security** built an Intel SGX proof of concept for leasing a model with protected weights, usage telemetry and an off-switch [S-1203].

## What it establishes
An attestation can show two things, provided the hardware is sound and the vendor's keys are not compromised:

- A specific, measured software stack produced a given output from inputs identified by hash [S-0012].
- The stack ran on genuine vendor hardware in confidential mode [S-1207].

This supports positive claims, such as which model answered (The declared model is the one being served) or which policy code wrapped it (Declared safeguards were applied during inference).

An attestation has three gaps:

- It reflects the launch state, so it does not cover weights or other data loaded afterwards. These must be bound separately [S-0013].
- It does not cover anything that was never measured. Gloria Z calls gaps in measuring feature flags, environment variables and invocation arguments "perhaps the most likely failure mode" [S-0014].
- It covers one deployment, not everything the chip does [S-0014]. Chip-level signals that bear on negative claims, such as that no training happened, are covered in On-chip telemetry from timing, memory and performance counters and Workload classification from telemetry and side channels.

## Threat model
TEE designs treat the operator's software as hostile, including the host operating system, the hypervisor and the cloud stack [S-1206] [S-0012]. They trust the hardware and its vendor [S-1206] [S-0009]. Each vendor and research design lists attacks it does not defend against:

- **NVIDIA** lists software, basic physical, rollback, cryptographic and replay attacks as in scope. Sophisticated physical attacks and denial of service are out of scope [S-1200].
- **Intel and AMD** consider memory-bus interposer attacks and other physical attacks on memory out of scope, according to the TEE.fail, Battering RAM and WireTap authors [S-1202] [S-1210] [S-1211].
- **PAL\*M** excludes side channels and physical attacks such as memory-bus interposition or swapping GPUs [S-0012].
- **GuardAIn** excludes side channels and denial of service [S-0010].

International verification faces a stronger adversary. Gloria Z describes it as a nation-state that may have advance physical access to data centres and leverage over hardware vendors [S-0014]. Other analysts also doubt that TEEs hold up against physical access:

- **The flexHEG authors** judge TEE-backed software "probably not secure against sophisticated actors if they have unrestricted physical access" [S-1204].
- **The Center for a New American Security (CNAS)** says existing features need hardening before they can be relied on in adversarial settings [S-0056].
- **RAND** notes that an attacker with physical access may be able to extract both the keys and the protected data [S-0057].

## Evidence
- **NVIDIA** documents confidential computing for Hopper and Blackwell GPUs [S-1200].
- **Tinfoil** reports support for H100, H200 and B200 GPUs [S-1206] and a production inference deployment [S-1208]. Its model-identity tool is open source [S-1209].
- **PAL\*M** reports under 11% overhead for common operations on Intel TDX with an H100. For inference attestation across three models, total observed overhead was 3.8–11.4% for multi-turn sessions and 45.5–66.4% for single prompts. Its code is "to be released after peer review" [S-0012].
- **Attestable Audits** ran its prototype on CPU-only AWS Nitro Enclaves with a 4-bit Llama-3.1-8B. CPU inference cost 21.7 times as much per token as GPU inference, and the enclave roughly doubled the CPU cost. The authors expect a production version on confidential-computing GPUs to have "an overhead as small as 5×" [S-0009].
- **GuardAIn** reports under 0.1% inference overhead for Llama variants on a Huawei Ascend 910A [S-0010].
- **FLI and Mithril** call their SGX prototype "not necessarily deployable as is", because of performance and hardware attacks that need mitigation [S-1203].

## Limitations
- A physical attacker can forge attestations. In TEE.fail, independent researchers with physical access, root privileges and equipment costing under $1000 extracted a per-CPU Intel attestation signing key from an up-to-date machine and forged TDX attestations. They paired the forgeries with genuine H100 attestations relayed from rented hardware, and a workload outside TEE protection passed both checks [S-1202]. On DDR4 servers, Battering RAM and WireTap forged SGX attestations with interposers costing under $50 and under $1000, and Battering RAM also broke AMD SEV-SNP attestation [S-1210] [S-1211].
- A software attacker has forged attestations too. In RMPocalypse, a malicious hypervisor faked SEV-SNP attestation on Zen 3, Zen 4 and Zen 5 processors without physical access [S-1212]. AMD reports firmware fixes [S-1213].
- Software side channels remain. PAL\*M and Attestable Audits cite earlier software attacks on CPU TEEs [S-0012] [S-0009]. NVIDIA disables performance counters in confidential mode because they could provide an avenue for side-channel attacks [S-1200]. Gloria Z notes that counters have leaked secrets from TEEs [S-0014].
- Coverage of large systems is incomplete. Hopper does not encrypt NVLink, and in mid-2025 NVIDIA's early-access release lacked multi-node support [S-1200] [S-1204]. O'Gara et al. ask what changes would be needed to use TEEs for verifying AI training at scale [S-0006].
- The root of trust rests with a few vendors (AMD, Intel and NVIDIA) [S-0014].
Technical detail: NVIDIA describes the GPU attestation chain as follows. An on-die root of trust verifies the identity key fused into the GPU and permits only NVIDIA-signed firmware at boot. The driver then opens an SPDM session with the GPU, using a Diffie-Hellman exchange to set up a session key [S-1200]. The GPU presents a device identity certificate signed with a device-unique ECC-384 key, which chains to the NVIDIA certificate authority. It then returns a signed set of measurements [S-1201]. Other details of NVIDIA's design: - Traffic between the confidential VM and the GPU is protected with AES-GCM through encrypted bounce buffers. NVIDIA states that in future, hosts with TDISP/IDE-compatible CPUs and Blackwell B100/B200 GPUs can use inline encryption instead [S-1200]. - Hopper's protected-PCIe mode passes all eight GPUs of an HGX node to one confidential VM, but NVLink traffic between them stays unencrypted. Blackwell also encrypts NVLink, for up to eight GPUs per confidential VM [S-1200]. - Performance counters are disabled in full CC-On mode. They are available only in a CC-DevTools development mode [S-1200]. - At launch, NVIDIA reported that H100 compute and HBM bandwidth were at par with non-confidential mode. CPU–GPU transfers were limited to roughly 4 GB/s by CPU encryption [S-1201]. Three systems bind application data to a report: - PALM sets the Intel TDX REPORTDATA field to the concatenation of the operation, a verifier challenge and hashes of the inputs and outputs. It models the protocol in the Tamarin prover [S-0012]. - Attestable Audits publishes attestations that bind the model hash, the audit code and data, and the result to a transparency log [S-0009]. - Tinfoil puts a dm-verity root hash of the weights on the measured kernel command line [S-0013].
Sources: [S-1200] NVIDIA Secure AI with Blackwell and Hopper GPUs (White Paper) (2025) https://docs.nvidia.com/nvidia-secure-ai-with-blackwell-and-hopper-gpus-whitepaper.pdf; [S-1201] Confidential Computing on NVIDIA H100 GPUs for Secure and Trustworthy AI (2023) https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/; [S-1202] TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (2026) https://tee.fail/; [S-1210] Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing (2026) https://batteringram.eu/; [S-1211] WireTap: Breaking Server SGX via DRAM Bus Interposition (2025) https://wiretap.fail/; [S-1212] RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP (2025) https://rmpocalypse.github.io/; [S-1213] SEV-SNP RMP Initialization Vulnerability (AMD-SB-3020) (2025) https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3020.html; [S-0009] Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments (2025) https://arxiv.org/abs/2506.23706; [S-0012] PAL*M: Property Attestation for Large Generative Models (2026) https://arxiv.org/abs/2601.16199; [S-0013] How Tinfoil Proves Exactly What Model Is Running (2026) https://tinfoil.sh/blog/2026-02-03-proving-model-identity; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance; [S-0010] GuardAIn: Protecting Emerging Generative AI Workloads on Heterogeneous NPU (2025) https://www.computer.org/csdl/proceedings-article/sp/2025/223600d823/26hiVLrJZi8; [S-0006] Hardware-Enabled Mechanisms for Verifying Responsible AI Development (2025) https://arxiv.org/abs/2505.03742; [S-0056] Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing (2024) https://www.cnas.org/publications/reports/secure-governable-chips; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-1203] Exploration of secure hardware solutions for safe AI deployment (2023) https://futureoflife.org/ai-policy/hardware-backed-compute-governance/; [S-1204] Technical Options for Flexible Hardware-Enabled Guarantees (2025) https://arxiv.org/abs/2506.03409; [S-1206] A primer on secure enclaves (2026) https://docs.tinfoil.sh/verification/secure-enclave-primer; [S-1207] Backend infrastructure (2026) https://docs.tinfoil.sh/verification/attestation-architecture; [S-1208] How verification works in Tinfoil (2026) https://docs.tinfoil.sh/verification/verification-in-tinfoil; [S-1209] modelwrap: Reproducible dm-verity read-only image of Huggingface models (2026) https://github.com/tinfoilsh/modelwrap

## Timed challenge-response and memory-occupation challenges (M-0016, mechanism)
Readiness (editorial assessment, rubric 1.0): R1, low confidence. R1: the AI use is described and the primitives are peer-reviewed, but the only GPU experiment tests data residency on one GPU, not a memory bound across servers. - R1 met: the MIRI overview describes memory challenges for verifying the presence of information and the absence of free memory, with timing figures and assumptions [S-0018]. The AI 2040 plan names memory-challenge verification as a possible direction [S-0067]. The underlying primitives (timed attestation, proofs of space and proofs of secure erasure) are peer-reviewed [S-1307] [S-1607] [S-1304]. - R2 not met: Monfared et al. report H100 experiments in which a VRAM-residency challenge separates data in GPU memory from data in host memory by more than 350 ms [S-0033]. That is a single-GPU residency test without quantified error rates, not a challenge that bounds free memory across servers [S-0033]; no code is linked, which the rubric does not require. The MIRI overview states that, to its author's knowledge, a network-level timing probe of memory contents between servers "has not yet been demonstrated" [S-0018]. SAGE shows timed software attestation on A100 GPUs for trusted execution, not for bounding spare capacity [S-1306]. The mechanism's only implementation, Low-trust AI compute verification system overview, is a proposed architecture at R1. Confidence is low because AI-specific public sources are thin, and the narrow use of checking that data is resident in one GPU's memory may merit R2 on the H100 result alone.
A verifier sends unpredictable questions that a device can answer in time only if it holds specified data, or dedicates specified resources, locally.
In a timed challenge, a verifier sends an unpredictable question that a device can answer in time only if it holds certain data locally or dedicates certain resources to the answer. Filling a device's memory with verifier-chosen data and then checking random pieces can bound how much spare memory it has. The approach builds on software-based attestation of embedded devices and on proofs of space. AI-specific public work is thin: one design overview, one study showing that response times reveal whether data sits in an H100's memory, and memory-wiping designs that use such challenges. As of September 2026, no network-level test across data-centre servers has been reported. The main obstacle is excluding outside help, such as fast remote memory. Timing-based attestation of embedded devices has been broken in practice, and its attackers judged it "very difficult, if not impossible, to design correctly".
## How it works

A timed challenge asks a device something it can answer correctly, within a deadline, only if it holds certain data locally or dedicates certain resources to the answer [S-1307] [S-0018] [S-0033]. Three families of primitives exist:

- **Timed attestation.** In SWATT, the verifier sends a random seed, and the device computes a checksum over its memory in a pseudorandom order [S-1307]. If memory has been altered, the extra work shows up as a detectable delay [S-1307].
- **Proofs of space.** A prover shows that it dedicates "a significant amount of disk space as opposed to computation" [S-1607]. Constructions use graphs that are hard to pebble, and Merkle hash trees [S-1607].
- **Proofs of secure erasure.** These fill memory and then run timed rounds, accepting only answers that arrive within a round-trip bound [S-0032] [S-1302]; see Memory wiping and proofs of secure erasure.

For AI facilities, the MIRI system overview describes two uses of memory challenges: "A) verifying presence of information B) verifying the absence of free memory/storage" [S-0018]. Response time is the main evidence, because answering from another device is measurably slower [S-0018]. The overview cites average NVMe read latencies of a few microseconds against about 100 ns for DRAM [S-0018]. For the absence case, incompressible data is loaded until capacity is full, and random samples are challenged [S-0018].

Monfared et al. propose four GPU probes [S-0033]:

- memory-hard puzzles inspired by proof of work, which reveal parallel effort;
- verifiable-delay-function workloads, which measure sequential execution;
- matrix-multiplication timing, which reflects tensor-core performance;
- a VRAM-residency test.

In the residency test, a large challenge dataset is loaded into GPU memory [S-0033]. At random times, fresh challenges require keyed, memory-hard computation over it, and response times show whether it is still resident [S-0033].

## What it establishes
A capacity-filling challenge that is answered on time bounds how much free memory a device had at that moment [S-0018]. Monfared et al. argue that timing variations can expose GPU engagement, complementing other accountability mechanisms [S-0033]; see Declared hardware is idle or shut down. The AI 2040 plan says memory-challenge verification "has the promise of potentially also not requiring a hardware retrofit, but seems likely to face some difficulties with verifying completeness" [S-0067].

A presence check does not show that nothing else is stored [S-0018]. The overview notes that data could be pre-staged into local memory before a challenge, which only an unpredictable, capacity-filling challenge rules out [S-0018].

## Threat model
- **Known device.** SWATT's verifier must know the device's clock speed, instruction set, memory architecture and expected memory contents [S-1307].
- **Cryptographic model.** Proofs of space are proved secure in the random oracle model, with one additional mild assumption [S-1607].
- **Compromised stack.** Monfared et al. consider host and GPU firmware that "may be modified, virtualized, or colluding" [S-0033].
- **No remote helpers.** In data centres, remote memory access is the key helper to exclude [S-0018]. Its round trips of about 1–2 µs compare with about 70–200 ns for local DRAM, and the overview says verification "depends on the ability to rule out RDMA, either via response latency or physical disconnection" [S-0018].

## Evidence
- **GPU memory residency.** On an H100 with a 60 GB challenge dataset, Monfared et al. report that the gap between memory-resident and host-resident responses "exceeds 350 ms, making them trivial to distinguish" [S-0033]. Their experiments ran on NVIDIA Turing and Hopper GPUs, and they do not quantify error rates [S-0033].
- **GPU attestation.** SAGE, a peer-reviewed software-based attestation mechanism for A100 GPUs, is reported by its authors to be "already practical today" for trustworthy execution without special hardware support [S-1306].
- **Memory wiping.** Amodo's wiping design includes a timed challenge phase with an assumed 1 ms round trip [S-1302].
- **Across servers.** The MIRI overview states that, to its author's knowledge, distinguishing memory contents between servers with a network-level timing probe "has not yet been demonstrated" [S-0018].

## Limitations
- **Broken embedded schemes.** Castelluccia et al. implemented attacks based on a return-oriented rootkit and on code compression, together with specific attacks on SWATT and ICE-based schemes [S-1308]. They conclude that secure time-based attestation is "very difficult, if not impossible, to design correctly" [S-1308]. Perito and Tsudik cite such weaknesses as motivation for proofs of secure erasure [S-1304].
- **Coverage.** Castelluccia et al. argue that "all memories (RAM, ROM, EEPROM) have to be attested" [S-1308].
- **Overhead.** The VRAM-residency test "intentionally incurs substantial memory overhead" [S-0033], and filling a pod's volatile memory takes tens of minutes [S-0018].
- **Unquantified error rates.** Monfared et al. do not define thresholds or statistical tests [S-0033].
Sources: [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-0033] Timing and Memory Telemetry on GPUs for AI Governance (2026) https://arxiv.org/abs/2602.09369; [S-1306] SAGE: Software-based Attestation for GPU Execution (2023) https://www.usenix.org/conference/atc23/presentation/ivanov; [S-1307] SWATT: SoftWare-based ATTestation for Embedded Devices (2004) https://netsec.ethz.ch/publications/papers/swatt.pdf; [S-1308] On the Difficulty of Software-Based Attestation of Embedded Devices (2009) https://s3.eurecom.fr/docs/ccs09_Castelluccia.pdf; [S-1607] Proofs of Space (2015) https://eprint.iacr.org/2013/796; [S-0032] Software-Based Memory Erasure with Relaxed Isolation Requirements (2024) https://ieeexplore.ieee.org/document/10664348/; [S-1302] Memory Wipes - Performance Analysis (2026) https://amododesign.com/notes/2026-07-01-memory-wiping/; [S-1304] Secure Code Update for Embedded Devices via Proofs of Secure Erasure (2010) https://link.springer.com/chapter/10.1007/978-3-642-15497-3_39

## Workload classification from telemetry and side channels (M-0021, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2: two preprints publish end-to-end results on current GPUs against stated, iterated adversaries; nobody independent has evaluated them. - R1 met: the claim, signals and threat model are publicly described [S-0037] [S-1412] [S-0007]. - R2 met: Rahman and Tajdari evaluate 9 current NVIDIA GPU models against 20 evasion strategy families over five rounds of monitor–evader iteration, with method and setup described in enough detail to repeat [S-0037]. They state that their workload source code is in the project repository, but the paper gives no link [S-0037]. Gargiulo and Kulp classify workloads on an H200 from externally measured power, test four evasion strategies and release their recordings as a dataset [S-1412]. - R3 not met: no party other than the developers is reported to rely on these classifiers for a verification decision, no production-grade system is available, and no independent adversarial evaluation has been published. Confidence is medium: both results come from single machines, and the location of Rahman and Tajdari's code is not given.
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.
Workload classification infers what a chip is doing, such as training a model, serving it or running non-AI code. It uses signals that do not read weights or data: software counters such as power and utilization, or power draw measured outside the chip. Two 2026 preprints report high accuracy on their own test sets: 98.2% from software counters across nine NVIDIA GPU models, and 97% from an external probe on one H200. In the hardest cases, evasion strategies the classifier had not seen cut detection to 43–87% and 48–88% respectively; an added rule raised the second to at least 98%. The main obstacle is trust in the signal: software counters are read by software the operator controls, so they can be forged unless hardware protects the reading. External probes avoid this but have been tested on one GPU. Results cover single machines, and no independent evaluation exists.
## How it works

Workload classification infers what a chip is doing from signals that do not reveal the content of the computation [S-0037] [S-1412]. Typical labels are training, inference and non-AI work [S-0037] [S-1412]. Ansari lists it among monitoring mechanisms [S-0007]. It uses cluster-level signals such as power and network bandwidth, and node-level signals such as accelerator utilization and memory bandwidth [S-0007].

There are two main signal sources:

- **Software telemetry.** Rahman and Tajdari use NVIDIA's NVML counters, including utilization, memory, power, temperature, clocks and PCIe traffic, sampled about once a second [S-0037]. They describe these as zero-overhead, content-agnostic signals that do not access weights, data or hyperparameters [S-0037]. A random-forest pipeline first separates ML from non-ML work, then training from inference [S-0037].
- **Physical side channels.** Gargiulo and Kulp clamp a current probe on a GPU's auxiliary power supply and classify five-second power recordings sampled at 10 MHz [S-1412]. They argue that, unlike NVML telemetry, this channel can in principle be observed without the operator's cooperation [S-1412].

Where power is measured matters [S-0048]. Amodo Design describes each stage of data-centre power delivery, from the voltage regulator to the grid, as a low-pass filter: the further up the chain one measures, the less compute-level detail survives [S-0048]. Amodo argues that low-level power monitoring could be more expensive to spoof [S-0048].

Similar methods have precedents outside AI governance [S-0040] [S-0039]. Gangwal et al. detected covert cryptocurrency mining from CPU hardware performance counters with 99.9–100% binary accuracy on two test systems [S-0040]. Chen et al.'s Reveal detects system anomalies in ML clusters from hardware signals that operators can read, without knowledge of user workloads [S-0039].

## What it establishes
The authors report that, on the hardware tested, classifiers separate training from inference and non-ML work with high accuracy [S-0037] [S-1412]. Rahman and Tajdari report 98.2% across their own corpus of NVML telemetry [S-0037]. Gargiulo and Kulp report 97% from external power traces on one H200, for model families unseen in training [S-1412]. Both figures fall for evasion strategies the classifier has not seen (see Evidence to date). The results support checks that hardware declared for inference or non-AI use is not training (This compute runs inference, not training) [S-0037] [S-1412].

What it cannot show:

- **How much training, or of what.** The papers classify workload type only, not how much training occurred or which model was trained [S-0037] [S-1412].
- **AI training versus other heavy computing, from power alone.** Ansari's April 2026 feasibility taxonomy noted that power monitoring alone cannot separate AI training from other high-performance computing without other signals, and that no published study had quantified false-positive rates for power-based training detection [S-0007].
- **Workload type from power level alone.** Power draw depends on more than workload type: Gregersen et al. found that changing only the input data can alter GPU power in matrix multiplication by nearly 40% [S-0042]. Measured draw can also differ from rated power: Latif et al. recorded a peak of about 8.4 kW on an 8-GPU H100 node during training, 18% below its rated 10.2 kW, with GPUs near full utilization [S-0041].

The signals can also reveal more than the workload class. Gao et al. recovered the architectures of models running on general-purpose processors from software-read power measurements, with 99.75% accuracy by their Levenshtein-distance measure [S-0046].

## Threat model
Rahman and Tajdari consider two evaders [S-0037]:

- **A cloud tenant** who controls only user-space software.
- **A hardware operator** who controls the full stack and wants to hide unauthorized training from a regulator.

Their results depend on a tamper-resistant NVML read path and an authenticated telemetry channel, which they treat as minimum hardware-enabled guarantees (On-chip telemetry from timing, memory and performance counters) [S-0037]. In their fifth round they give the evader white-box access to the classifier, which they describe as a disaster scenario for governance [S-0037]. Gargiulo and Kulp treat the operator as adversarial and able to reshape the computation, but not able to control the external probe [S-1412].

## Evidence
- **Software telemetry.** Rahman and Tajdari ran five rounds of monitor–evader iteration over 20 evasion strategy families on 9 GPU models spanning four architecture generations [S-0037]. They report 98.2% accuracy across their corpus [S-0037]. After hardening, strategies seen in training were always detected, but white-box strategies held out from training were detected only 43–87% of the time [S-0037].
- **External power.** Gargiulo and Kulp report 97% accuracy on held-out model families from a probe on one H200 NVL [S-1412]. Their hardened detector caught three of four held-out evasion strategies at least 99% of the time, and diluted LoRA 48–88% of the time, or at least 98% with an added rule [S-1412]. They release their 1,610 recordings and state that their attacks are not a comprehensive adversarial evaluation [S-1412].
- **Earlier assessment.** Before these papers, Ansari rated workload classification as deployable in cooperative settings and near-term in adversarial settings [S-0007].

## Limitations
- **Forged or replayed telemetry.** A privileged operator can forge or replay software-read counters unless hardware protects the read path [S-0037] [S-1412].
- **Unseen evasion strategies.** Detection falls to 43–87% for held-out white-box strategies on NVML telemetry [S-0037], and to 48–88% for diluted LoRA on external power before an added rule [S-1412]. In Gargiulo and Kulp's tests the evasion strategies cost 28.1–69.3% of throughput [S-1412].
- **Scale.** Results are single-node and NVIDIA-only [S-0037], or from one H200 [S-1412].
- **Power sampling.** Yang and colleagues found that on A100 and H100 GPUs the built-in power reading, which nvidia-smi obtains through NVML, samples only 25% of runtime. The GPU can draw very different power in the other 75% without the reading showing it [S-0073]. They also found the reading's error to be within about ±5% in most cases, against the ±5 W that NVIDIA claims [S-0073].
- **Distributed training.** Ansari reports that classification accuracy degrades when training is distributed across providers [S-0007].
- **Blurring categories.** The training-inference distinction may lose governance value [S-0007].
- **Spoofed power monitoring.** Amodo expects that power monitoring can likely be spoofed, but still sees value in it as a complement to other verification systems [S-0048].
Technical detail: - NVML signals and corpus. Rahman and Tajdari sample nine NVML signals at about 1 Hz: GPU and memory utilization, memory used, power, temperature, SM and memory clocks, and PCIe transmit and receive bandwidth [S-0037]. Their corpus has 1,404 runs of 162 workloads, about 117 GPU-hours, on 9 NVIDIA GPU models across the Ampere, Ada, Hopper and Blackwell generations, with 1 to 8 GPUs per configuration; 421 of the runs are evasion attempts [S-0037]. - NVML classifier. A two-stage random forest, first ML versus non-ML and then training versus inference, classifies 30 s windows [S-0037]. Before adversarial hardening, five-fold cross-validation grouped by run (26,496 windows from 1,396 runs) gives 98.21% ± 0.84% accuracy, 97.39% precision, 98.90% recall and a 3.06% false-positive rate [S-0037]. - NVML evasion. The 20 evasion strategy families fall into six classes: utilization manipulation, memory reduction, workload mimicry, training disguised as inference, multi-GPU evasion and white-box attacks [S-0037]. In the fifth round the evader had white-box access to the previous round's classifier. After hardening, strategies seen in training were detected 100% of the time and held-out white-box strategies 43–87% of the time [S-0037]. - External power probe. Gargiulo and Kulp clamp a Rogowski current probe around the positive conductors of an NVIDIA H200 NVL's PCIe auxiliary power supply and digitize at a nominal 10 MHz in 5 s windows [S-1412]. Their released dataset has 930 genuine and 680 adversarial recordings over 17 open model families and 25 non-AI workloads [S-1412]. On genuine recordings of model families unseen in training, they report 97% accuracy and a macro-averaged F1 of 0.955 across training, inference and non-AI classes [S-1412]. - Power-probe evasion. A detector hardened against evasion, with the tested strategy held out, caught training at least 99% of the time for three of four strategies. It caught diluted low-rank adaptation (LoRA) 48–88% of the time, rising to at least 98% with an added rule [S-1412]. The four strategies cost 28.1% to 69.3% of throughput [S-1412]. The authors state that these attacks are not a comprehensive evaluation against adversarial behaviour [S-1412].
Sources: [S-0037] Detecting Hidden ML Training With Zero-Overhead Telemetry (2026) https://arxiv.org/abs/2606.19262; [S-1412] Workload Identification with Physical Side Channels for AI Governance (2026) https://arxiv.org/abs/2609.00309; [S-0007] Hardware-Level Governance of AI Compute: A Feasibility Taxonomy for Regulatory Compliance and Treaty Verification (2026) https://arxiv.org/abs/2604.04712; [S-0048] Understanding Data Center Power Delivery (2026) https://amododesign.com/notes/2026-04-02-data-center-power-delivery/; [S-0041] Single-Node Power Demand During AI Training: Measurements on an 8-GPU NVIDIA H100 System (2025) https://doi.org/10.1109/ACCESS.2025.3554728; [S-0042] Input-Dependent Power Usage in GPUs (2024) https://arxiv.org/abs/2409.18324; [S-0040] Detecting Covert Cryptomining Using HPC (2020) https://link.springer.com/chapter/10.1007/978-3-030-65411-5_17; [S-0039] Detecting Anomalies in Machine Learning Infrastructure via Hardware Telemetry (2025) https://arxiv.org/abs/2510.26008; [S-0046] DeepTheft: Stealing DNN Model Architectures through Power Side Channel (2024) https://doi.org/10.1109/SP54263.2024.00250; [S-0073] Part-time Power Measurements: nvidia-smi's Lack of Attention (2023) https://arxiv.org/abs/2312.02741

## Zero-knowledge proofs of inference (M-0004, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2 through zkLLM, which has public, artifact-evaluated code and peer-reviewed results at 13 billion parameters; no implementation is yet production-grade for language models. - R1 met: ZKML, zkLLM and NanoZK describe the claim (an output equals the committed model applied to an input) and their assumptions [S-0021] [S-0023] [S-0068]. - R2 met through zkLLM. Its code is public and received CCS 2024 artifact-evaluation badges [S-1108]. Its published end-to-end results use a 13-billion-parameter model on a data-centre GPU, against a stated adversary: a cheating polynomial-time prover [S-0023]. - R3 not met. Criterion (a) fails for this use. zkLLM's README says the code is not ready for industrial applications [S-1108]. Attestable's results come without public code, paper or reproducible artifacts [S-1101]. The ezkl library is public, and other projects use its verifier contracts in production [S-0070]. The language model South et al. prove with ezkl is a 250,000-parameter nanoGPT, and the largest model in their results is a VAE decoder of about 1.07 million parameters [S-0024]. Both are far below the scale this use concerns. Criterion (b) is met only for ezkl, whose 2025 audit left no high-severity finding unresolved [S-0070]. As of September 2026 no independent audit or red-team of zkLLM has been published. One independent analysis, tested on a small transformer, shows that valid proofs of LLM inference do not bind the computation spent, so a much smaller model can pass as the declared one [S-1112].
A prover produces a cryptographic proof that an output came from running a committed model on a given input, without revealing the weights.
Zero-knowledge proofs of inference let an AI developer show that an output was computed by a model it committed to in advance, on a given input, without disclosing the weights. A verifier checks a small proof in seconds instead of rerunning the model. The peer-reviewed system zkLLM proved one 2,048-token forward pass of a 13-billion-parameter model in about 13 minutes on one A100 GPU, and its code is public. A company, Attestable, reports proving a 31-billion-parameter model at 53 tokens per second on one H100, but has published no paper or code. The main obstacle is cost. The main weaknesses are coverage and fidelity: a proof covers only the computation proven, and that computation is a fixed-point approximation of the model. An independent audit of one proving library, ezkl, found high-severity soundness bugs, since fixed.
## How it works

A zero-knowledge proof of inference lets a prover convince a verifier that an output came from a specific model on a specific input, without revealing the model's weights [S-1100]. A survey describes ZKPs as letting one party certify that a training, testing or inference result "was produced by the claimed computation without revealing sensitive data or proprietary model parameters" [S-1100].

The protocol has two steps:
1. The prover publishes a cryptographic commitment to the weights once. For LLaMa-2-13B, zkLLM's commitment took 986 seconds [S-0023].
2. For each query, the prover proves that the output equals the committed model applied to the input [S-0023] [S-0021]. The verifier checks the proof without the weights and without rerunning the model [S-0023].

Only the weights are hidden. In zkLLM's setting the verifier submits the prompt and receives the output with its proof [S-0023]. South et al. likewise keep weights private and inputs and outputs public [S-0024].

Systems turn the network's operations into arithmetic over a finite field, with tensors as fixed-point numbers [S-0021] [S-0023]. Softmax, GELU and normalisation need special handling:
- zkLLM uses a parallel lookup argument (tlookup) and an attention-specific protocol (zkAttn) [S-0023].
- NanoZK uses 16-bit lookup tables [S-0068].

Proof systems differ:
- ZKML compiles models to halo2 circuits with either KZG commitments, which need a trusted setup, or transparent IPA commitments [S-0021].
- zkLLM uses sumcheck-based protocols with Hyrax commitments [S-0023].
- NanoZK proves each transformer layer separately and links the layers with a chain of SHA-256 commitments [S-0068].
- Attestable reports a prover whose security rests "only on the security of cryptographic hash functions" [S-1101].

Proofs over many inputs can be packaged into attestations that a model with fixed private weights reaches a stated benchmark score [S-0024].

## What it establishes
**What it can establish.**
- A valid proof shows that the output follows from the committed weights, the public architecture and the input [S-0023] [S-0021]. This bears directly on The declared model is the one being served.
- The weights stay confidential against a verifier that follows the protocol. zkLLM's zero-knowledge theorem shows that such a verifier's view reveals nothing about the weights beyond the output [S-0023].
- Attestable proposes proofs that an accounted workload "used an approved, unchanged model rather than a newly trained replacement", which bears on This compute runs inference, not training [S-1102].

**What it cannot establish.**
- **Which model the commitment is.** The proof does not tie the committed weights to an outside identity such as "the declared model". Proven benchmark results over the committed weights are one way to link them [S-0024]. Committed weights can also be hollow. Weights with the declared architecture and parameter count can route the work through a much smaller model and still yield valid proofs [S-1112].
- **Work that was not proven.** Attestable notes that "a proof of some computation is not a proof of all computation", and that a proof cannot find an undeclared datacenter [S-1102].
- **Every output, when only some are proven.** Assurance from sampling is probabilistic. Attestable proposes selecting outputs at random for proof after they have been committed [S-1103]. NanoZK bounds the chance of detecting tampering when auditors check a subset of layers [S-0068].
- **The floating-point model.** What is proven is a fixed-point approximation of the model [S-0023]. Attestable reports 8-bit integer matrix multiplications [S-1101].
- **A hidden architecture.** ZKML requires the architecture to be revealed [S-0021], and zkLLM assumes it is publicly known [S-0023].

## Threat model
Soundness rests on computational assumptions against a cheating prover:
- zkLLM proves its lookup argument sound: a cheating probabilistic polynomial-time prover succeeds only with negligible probability. The rest of its protocol applies sumcheck and proofs of opening for commitments whose binding rests on discrete-log hardness [S-0023].
- NanoZK assumes a polynomial-time adversary that controls the inference infrastructure and may substitute models or fabricate outputs. It relies on discrete-log hardness over the Pallas curve and SHA-256 collision resistance [S-0068].
- Attestable reports 100-bit security, and post-quantum security because it avoids public-key cryptography [S-1101].

Confidentiality rests on further assumptions:
- zkLLM assumes a semi-honest verifier, which "accurately reports the outcome of the proof verification" but tries to learn the weights. Its zero-knowledge theorem also assumes zero-knowledge variants of the sumcheck protocols [S-0023].
- NanoZK leaves side channels, denial of service and hiding the input from the provider out of scope [S-0068].
- Attestable treats physical-access and metadata channels as separate threats [S-1103].

## Evidence
- **ZKML.** It proved a distilled 81.3-million-parameter GPT-2 in 3,651.67 seconds on a 128-vCPU, 1 TB machine. This was the largest model its authors could prove with under 1 TB of RAM [S-0021].
- **South et al.** They used ezkl to prove evaluations of small models. A 250,000-parameter nanoGPT took 2,781 seconds to prove and needed a 219 GB proving key [S-0024].
- **zkLLM.** It proved OPT models up to 13B and LLaMa-2 models of 7B and 13B, each proof covering one 2,048-token forward pass on one A100 GPU. LLaMa-2-13B took 803 seconds to prove and 3.95 seconds to verify, with a 188 kB proof [S-0023]. Its code is public [S-1108].
- **NanoZK.** It reports proofs of 3.2 to 3.7 KB per attention or MLP sub-circuit, about 83 KB in total for 12 layers. From per-component timings, it projects that a 12-layer GPT-2 would take about 14 minutes to prove sequentially on CPU [S-0068].
- **Attestable.** It reports proving a 31-billion-parameter Gemma model at 53 tokens per second for one 16K-token sequence on one H100 GPU, with 4.35 to 7.92 MiB proofs and 157 to 648 ms CPU verification. No code or paper accompanies these results [S-1101].
- **Independent audit of ezkl.** Trail of Bits reviewed the ezkl library in January 2025, at its developer's request. It reported three high-severity circuit soundness issues and four ways to bypass data attestation in ezkl's smart contracts. Its fix review found every high-severity finding resolved [S-0070].
- **Hollow-LLM attack.** Researchers at the University of Southern California ran a ghost-weight attack through zkGPT's proof procedure on a 6-layer, 512-dimensional transformer declared as up to 12 layers and 1,024 dimensions. Outputs were unchanged and serving cost stayed at the small model's level [S-1112].

A verification system design for AI agreements lists ZKPs as a "tentative plan B" that could "remove the need for secure computing hardware setups" [S-0018].

## Limitations
**Cost.**
- zkLLM needs about 12 to 13 minutes per 2,048-token forward pass at 13B scale on one A100 [S-0023].
- The verification system design calls the overhead "heavy" [S-0018].
- The survey names "limited circuit expressiveness, high proving cost, and deployment complexity" as the main implementation bottlenecks [S-1100].

**Expressiveness.** ZKML does not support branching or variable-length loops, so language models need fixed-length inputs [S-0021]. Floating-point emulation remains open [S-0018]. Attestable reports a 16K-token context limit [S-1101].

**Implementation soundness.** In ezkl, Trail of Bits found circuits with missing constraints that "would allow a malicious prover to convince a verifier of incorrect calculations"; these were fixed [S-0070]. The zkLLM README says its code "has NOT undergone security auditing and is NOT ready for industrial applications". It also says prover and verifier run side by side, and that a deployment would need Fiat–Shamir to be non-interactive [S-1108].

**Quantisation.** Trail of Bits also built a ResNet-18 backdoor that is dormant in the full-precision model and active after ezkl's quantisation. Whether it persists through proving was left for further investigation [S-0070].

**Coverage.** A proof covers only the outputs proven [S-1102]. For accounting of other work, see Proofs of useful work and resource exhaustion. A proof also does not show how much computation produced an output. In the Hollow-LLM attack, weights with the declared architecture let a much smaller model do the work, and the proofs remain valid [S-1112].
Technical detail: Systems encode a network as an arithmetic circuit, or as sumcheck and lookup relations, over a finite field, with tensors scaled to fixed point [S-0021] [S-0023]. - ZKML (EuroSys 2024) compiles models to halo2 circuits with KZG commitments (trusted setup) or IPA commitments (transparent), and optimises circuit layout. A distilled GPT-2 (81.3M parameters) took 3,651.67 s to prove with KZG, 18.70 s to verify and a 28,128-byte proof on a 128-vCPU, 1 TB machine [S-0021]. - ezkl also targets halo2 with KZG. South et al. proved a 250,000-parameter nanoGPT in 2,781 s, verified it in 2.69 s and needed a 219 GB proving key [S-0024]. A Trail of Bits audit of ezkl (January 2025, commit bdcba5c) reported 34 findings, 8 of high severity; three high-severity findings were circuit soundness issues, and all high-severity findings were resolved at the March 2025 fix review [S-0070]. - zkLLM (CCS 2024) uses sumcheck-based arguments, a parallel lookup argument (tlookup) for non-arithmetic tensor operations, an attention protocol (zkAttn) and Hyrax commitments over BLS12-381, with values scaled by 2^16. On one A100 40 GB GPU with 2,048-token inputs, LLaMa-2-13B needed 986 s for the one-time weight commitment, 803 s to prove, 188 kB of proof, 3.95 s to verify and 23.1 GB of memory. Perplexity on C4 moved from 6.520 to 6.528 [S-0023]. - NanoZK (ICICS 2026) proves each transformer layer separately with Halo2/IPA over the Pallas curve, uses 16-bit lookup tables for softmax, GELU and normalisation, and chains layer boundaries with SHA-256 commitments. It reports 3.2 to 3.7 KB per sub-circuit (attention or MLP) proof, about 83 KB in total for 12 layers. From per-component timings it projects about 14 minutes to prove a 12-layer GPT-2 sequentially on CPU [S-0068]. - Attestable reports a prover whose security rests only on hash functions, at 100-bit security, with 8-bit integer matrix multiplications. On one H100 it reports 4.35 to 7.92 MiB proofs, 157 to 648 ms CPU verification, and 53 tokens per second for one 16K-token sequence of a 31B Gemma model [S-1101].
Sources: [S-0023] zkLLM: Zero Knowledge Proofs for Large Language Models (2024) https://doi.org/10.1145/3658644.3670334; [S-1108] zkllm-ccs2024: code for zkLLM: Zero Knowledge Proofs for Large Language Models (2024) https://github.com/jvhs0706/zkllm-ccs2024; [S-0021] ZKML: An Optimizing System for ML Inference in Zero-Knowledge Proofs (2024) https://doi.org/10.1145/3627703.3650088; [S-0068] NanoZK: Privacy-Preserving Verifiable Inference for Large Language Models via Layerwise Zero-Knowledge Proofs (2026) https://arxiv.org/abs/2603.18046; [S-0024] Verifiable evaluations of machine learning models using zkSNARKs (2024) https://arxiv.org/abs/2402.02675; [S-0070] Zkonduit EZKL Security Assessment (2025) https://github.com/trailofbits/publications/blob/master/reviews/2025-03-zkonduit-ezkl-securityreview.pdf; [S-1100] A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning (2026) https://arxiv.org/abs/2502.18535; [S-1101] Proving LLMs at Scale (2026) https://attestable.com/blog/proving-llms-scale; [S-1102] Pacing AI Requires Proof (2026) https://attestable.com/blog/pacing-ai-requires-proof; [S-1103] From Verifiability to Model-Weight Security (2026) https://attestable.com/blog/model-weights-security; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-1112] Hollow-LLM Attack: Computationally Trivial Weights in Zero-Knowledge Verification of LLM Inference (2026) https://arxiv.org/abs/2607.28884

## Zero-knowledge proofs of training constraints (M-0005, mechanism)
Readiness (editorial assessment, rubric 1.0): R2, low confidence. R2, narrowly. Peer-reviewed end-to-end results exist at toy scale against a stated adversary. The frontier-scale design is unbuilt. - R1 met: Kaizen [S-1110] and ZkAudit [S-0022] define proofs of correct training on committed data. Peigné et al. describe a frontier design with stated claims, trust anchors and open problems [S-0025]. - R2 met through reproducible published end-to-end results; no Implementation carries it. Both papers are peer-reviewed, specify the protocol, setup and parameters, and state a cheating prover as the adversary. Kaizen measures proving per training iteration of a 10-million-parameter VGG-11, with recursive aggregation implemented [S-1110]. ZkAudit proves single SGD steps of MobileNet v2 and recommender models on AWS g4dn.8xlarge instances, and estimates the cost of proving full training runs [S-0022]. Kaizen links no code [S-1110], and ZkAudit links only an anonymised review repository [S-0022]; the rubric does not require code on this route. Both results are several orders of magnitude below frontier training. - R3 not met. As of September 2026 no deployment, reliance by a third party or independent evaluation has been published. The frontier design is unimplemented, and its authors present its costs as estimates, with target values "not yet measured" [S-0025].
Cryptographic proofs that a training run followed a committed dataset, procedure and rules, checkable without revealing the model or the data.
Zero-knowledge proofs of training would let an AI developer prove that a model was trained as declared, on a committed dataset and within agreed rules such as a compute limit, without showing the weights or the data. Peer-reviewed systems have done this for small models. Kaizen proves training iterations of a 10-million-parameter image model. ZkAudit proves single training steps of small image and recommender models, and estimates the cost of full runs. A 2026 preprint argues that frontier-scale verification is feasible by proving only randomly challenged training steps, anchored by network observations. It has not been built, and its overhead figures are estimates. The biggest obstacle is cost: proving one small training step takes minutes. The biggest known weakness of the frontier design is that sparse challenges give probabilistic detection, and its network anchor cannot see traffic inside a server.
## How it works

A zero-knowledge proof of training (zkPoT) lets a party prove "that they have correctly trained a committed model based on a committed dataset", revealing nothing further about the model or the data [S-1110]. A survey calls this verifiable training: certifying that updated parameters result from the declared procedure [S-1100].

**Small-scale protocols.** Published systems follow three steps:
1. The prover commits to the dataset [S-1110] [S-0022].
2. It fixes the data order using verified randomness [S-0022].
3. It proves each gradient-descent step: the forward pass, the backward pass and the weight update [S-0022].

Kaizen adds three techniques [S-1110]:
- sumcheck-based proofs specialised for gradient descent;
- recursive composition, so that proof size and verifier time do not grow with the number of iterations;
- aggregatable polynomial commitments.

ZkAudit adds proofs of arbitrary audit functions over the committed data and weights [S-0022].

**A frontier-scale design.** Peigné et al. propose a design for frontier training with four parts [S-0025]:
- **Commitment.** Before training, the trainer publishes a hashed commitment that combines the architecture specification, a Merkle root of the dataset and the root of the initial weights [S-0025].
- **Hash chain.** During training, the GPUs compute Merkle roots of per-layer tensors at every step and publish them in a hash chain [S-0025].
- **Network anchor.** An auditor-controlled network tap, or an attested SmartNIC, records hashes of traffic between nodes as an independent anchor [S-0025] (see Network taps and certifiers).
- **Challenges.** After the chain is frozen, the auditor challenges sampled steps. The trainer re-executes those steps, and a zero-knowledge virtual machine, with native precompiles mostly for floating-point operations, checks them against the committed roots [S-0025].

The design also includes genesis proofs and "ex-ante" attestations that enforce policy invariants, such as compute thresholds [S-0025].

## What it establishes
**What it can establish.**
- A zkPoT shows that the committed weights resulted from the declared training procedure on the committed dataset [S-1110] [S-0022]. This bears on A training run stayed within declared limits.
- Peigné et al. aim to verify further properties: that training followed a pre-committed specification, stayed below compute thresholds and ran on the declared hardware [S-0025].

**What it cannot establish.**
- **That the data is acceptable.** A proof binds data to a commitment but does not vet it. ZkAudit does not protect against data poisoning [S-0022].
- **Every step, in the frontier design.** Sparse auditing is "detection-grade, not universal" [S-0025].
- **Full confidentiality.** ZkAudit reveals the model architecture [S-0022].

## Threat model
The small-scale systems assume a cheating prover bounded by cryptographic assumptions, and a public training algorithm and architecture [S-1110] [S-0022]. The frontier design adds trust anchors [S-0025]:
- deterministic GPU execution;
- a physical network tap, or secure boot and device identity for the SmartNIC tier;
- the soundness of the zkVM;
- a public proof-checker binary.

It does not cover traffic inside a server, and its SmartNIC tier is weaker against supply-chain adversaries [S-0025].

## Evidence
- **Kaizen (CCS 2024).** It proves training of a 10-million-parameter VGG-11 on CIFAR-10 at batch size 16. The prover takes 15 minutes per iteration; the proof is 1.63 MB and verifies in 130 milliseconds, independent of the number of iterations [S-1110]. Its authors report "24× faster prover time" than generic recursive proof systems [S-1110].
- **ZkAudit (ICML 2024).** It proved single SGD steps for MobileNet v2 image classifiers and a recommender model on AWS g4dn.8xlarge instances. Proving one step on a single image took 47.5 to 328.3 seconds for MobileNet v2 (1.0, 224), depending on the fixed-point scale factor. The authors estimated, rather than generated, proofs of full training runs, at costs of hundreds to thousands of dollars [S-0022].
- **Other systems.** The survey lists further verifiable-training systems in its Table IV [S-1100].
- **The frontier design.** Peigné et al. estimate 2 to 10% training-side overhead for a Llama 3.1 405B-scale run, and deployment "within approximately 36 months" [S-0025]. The paper reports no prototype or measurements of its own, and marks its target values as "not yet measured" [S-0025].

The zkLLM authors wrote in 2024 that zero-knowledge proofs of LLM training "may pose insurmountable challenges" [S-0023].

## Limitations
**Cost.** A 10-million-parameter model needs minutes of proving per step [S-1110]. ZkAudit's authors leave scaling to larger models, such as language models, to future work [S-0022].

**Open problems in the frontier design.** Peigné et al. list 13, including [S-0025]:
- zero-knowledge proofs of backpropagation;
- deterministic attention backward passes with under 5% overhead;
- an open-hardware network tap at line rate;
- a way to tell silent data corruption apart from adversarial deviation;
- coverage of mixture-of-experts, reinforcement-learning post-training and multi-site training.

They also report that current deterministic tensor-parallel all-reduce configurations lose 64 to 89% of bandwidth [S-0025].

**Attacks.** As of September 2026 no attack on these proof systems has been published.
Sources: [S-1110] Zero-Knowledge Proofs of Training for Deep Neural Networks (2024) https://eprint.iacr.org/2024/162; [S-0022] Trustless Audits without Revealing Data or Models (2024) https://proceedings.mlr.press/v235/waiwitlikhit24a.html; [S-0025] Zero knowledge verification for frontier AI training is possible (2026) https://arxiv.org/abs/2606.05433; [S-1100] A Survey of Zero-Knowledge Proof Based Verifiable Machine Learning (2026) https://arxiv.org/abs/2502.18535; [S-0023] zkLLM: Zero Knowledge Proofs for Large Language Models (2024) https://doi.org/10.1145/3658644.3670334

## AI 2040 inference-only verification stack (I-0011, implementation)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1: the six-layer design, its claim and its assumptions are published, but the integrated stack has not been built. - R1 met: the plan publishes the design of the stack, the claim it would verify (only inference runs on retrofitted compute) and its key assumptions, including a trusted recomputation server and strong physical security [S-0067]. - R2 not met: there is no public implementation or end-to-end result for the integrated stack. The plan's companion page lists a reproducible inference stack as not started and gives no plan yet for scaling side-channel defences [S-1511]. A team working on the components says that nothing is past a proof-of-principle prototype [S-1512]. Some components are further along: passive optical taps work at 400G, and recomputation schemes such as TOPLOC and DiFR are being tested on relevant hardware [S-1511]; see Sampled inference recomputation. Confidence is medium: the design is clearly published, but component status comes from pages that are updated over time [S-1511] [S-1008].
A proposed retrofit that isolates data-centre inference units, taps their front-end traffic and recomputes random samples to check that only declared inference runs.
The AI Futures Project's AI 2040 verification plan proposes a technical stack for checking that retrofitted data centres run only inference, not training or experiments. Data centres would be split into isolated inference units by removing much of their back-end networking. Passive network taps would copy all front-end traffic to a recomputation server, which re-runs random samples of workloads organized into reproducible packets. Strong physical security would protect the equipment, and side-channel limits plus periodic memory wiping are meant to stop hidden work from leaving results. As of July 2026, passive optical taps worked at 400G and recomputation schemes were being tested, but the integrated stack had not been built; one team working on it says nothing is past a proof-of-principle prototype. The main obstacles are reproducible inference and networking, securing the recomputation server, and scaling side-channel defences. The plan does not verify that spare compute is unused.
## What it is

The AI 2040 verification plan, written by Romeo Dean and published by the AI Futures Project, includes a technical stack for verifying that retrofitted data centres run only inference workloads, not training or experiments [S-0067] [S-1511]. The plan calls it an inference-only retrofit and lists six layers [S-0067]. It is a proposal: the plan's companion page tracks which components exist and which are still open problems [S-1511].

## How it works

The six layers, as the plan lists them [S-0067]:

- **Isolated inference units.** Data centres are split into groups of isolated inference units by removing much of their back-end (east–west) networking [S-0067]. The plan argues that inference needs much less scale-out interconnect than training, so the overhead is relatively small [S-0067]. See Bandwidth limits and compartmentalization.
- **Passive taps.** Simple, passive taps on the front-end (north–south) network copy all input and output traffic to a recomputation server [S-0067]. The plan favours optical splitters, "essentially a piece of glass", because they are probably the easiest to trust [S-0067]. See Network taps and certifiers.
- **Reproducible packets.** All AI workloads, including agentic tool use, are organized into discrete, reproducible packets that the recomputation server can inspect [S-0067]. Inference is not reproducible by default, and achieving it may cost some overhead [S-0067]. See Reproducible computation packets.
- **Partial recomputation.** The server recomputes random samples of packets to check their correctness [S-0067]. The plan argues that this can verify all outputs with very high probability using a small fraction of the original compute, provided the server can be trusted [S-0067]. See Sampled inference recomputation.
- **Physical security.** Strong physical security protects the verification equipment against tampering [S-0067]. See Tamper evidence for verifier devices.
- **Completeness.** Side-channel communication is bounded, and memory is wiped periodically, probably by forced memorization [S-0067]. The aim is that the only results that persist are verified inference outputs [S-0067]. See Side-channel suppression for isolated facilities and Memory wiping and proofs of secure erasure.

## Evidence
The plan's companion page, updated in July 2026, and a practitioner status page report the state of each component [S-1511] [S-1008]:

- **Taps.** Passive optical taps work at 400G; the 800G and 1600G line rates now arriving in data centres look feasible but are undemonstrated [S-1511]. Capturing all front-end traffic needs no new research, but needs a lot of infrastructure plus work on network topologies and sampling [S-1511].
- **Recomputation.** TOPLOC and DiFR are well described and are being tested on relevant hardware and models [S-1511]. Recomputation red-teaming has not started [S-1008].
- **Reproducibility.** Demonstrations work around non-determinism, but work on a fully reproducible inference stack has not started [S-1511].
- **Completeness.** Early hardware testing of memory wiping is under way [S-1511]. For side-channel mitigation, only early theoretical pieces exist [S-1511].
- **Overall.** The Amodo team reports that the core components are being de-risked, but that nothing is past a proof-of-principle prototype [S-1512].

## Limitations
- **Trusted recomputation server.** The assurance argument assumes that the server's computations and outputs can be trusted [S-0067]. Amodo rates recomputation-server security as not on track [S-1008].
- **Spare compute.** Idle or spare compute is not directly verified [S-0067].
- **Tap installation.** Checking that taps are correctly installed and stay in place is not yet solved [S-1511].
- **Network reproducibility.** Making individual packets reproducible across the network may need considerable software, firmware and possibly hardware work [S-1511].
- **Recomputation attacks.** When the adversary controls the prompts, Gumbel-based inference verification, the family that includes Token-DiFR [S-0015], leaks roughly twice as many bits per token as under benign prompts [S-1507]. See Bounding unexplained information in outputs.
- **Side-channel defence.** There is no plan yet for scaling side-channel defences quickly on a frontier cluster [S-1511].
Technical detail: - Secure network gateways. The plan names more capable gateways as a possible replacement for the passive taps. Splitters on the input and output paths log data flow into packets, which are randomly sampled and sent to a secure recomputing server. At boot, the gateways would also check that only whitelisted model weights are uploaded to the inference unit [S-0067]. - Physical security measures. The plan lists tamper-evident enclosures, security cameras, perimeter controls and air-gapping [S-0067]. - Other options the plan names. Zero-knowledge proofs could preserve privacy and need less hardware retrofit, but are "currently somewhat speculative" for lack of efficient enough algorithms. Memory-challenge verification might also avoid a hardware retrofit, but "seems likely to face some difficulties with verifying completeness". For an initial phase, removing major scale-out interconnect and installing simple sensors might suffice [S-0067].
Sources: [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-1511] Get Involved in Verification (2026) https://ai-2040.com/supplements/verification-plan/get-involved; [S-1512] Verifying international AI deals: Plan A, the state-of-play, and what you can do to help (2026) https://amodo.substack.com/p/verifying-international-ai-deals; [S-1008] AI 2040 Plan A — Verification SITREP (2026) https://amododesign.com/ai-verification/plan-a-sitrep/; [S-0015] Verifying LLM Inference to Detect Model Weight Exfiltration (2025) https://arxiv.org/abs/2511.02620; [S-1507] Adversarial Entropy Inflation Against Gumbel-Based Inference Verification (2026) https://arxiv.org/abs/2608.23375

## Attestable Audits (I-0007, implementation)
Readiness (editorial assessment, rubric 1.0): R2, low confidence. R2. One developer paper reports end-to-end results on commercial hardware, but there is no public code and no independent reproduction, so confidence is low. - R1 met: the protocol, goals and adversaries are published [S-0009]. - R2 met through reproducible published end-to-end results. The paper specifies the protocol and its algorithms, the enclave and baseline instances, the models and the benchmarks. It reports results for Llama-3.1-8B on AWS Nitro Enclaves, which are commercially available hardware, against a stated adversary [S-0009]. The reported evaluation covers the audit step. The paper links no code, which the rubric does not require for this route. - R3 not met. No party other than the developers is documented relying on it for a verification decision, and the prototype is CPU-only research code rather than a production-grade system. As of September 2026 no independent security evaluation has been published.
A research prototype that runs AI safety benchmarks inside a trusted execution environment and publishes attestations binding the model, the audit and the results.
Attestable Audits, from University of Cambridge researchers, lets a model provider and an auditor who do not trust each other run a benchmark on a confidential model. Both send their inputs, encrypted, to a trusted execution environment: the provider its weights, the auditor its test code and data. The enclave runs the audit and publishes an attestation that binds the model hash, the audit and the result. Later, users can check that the model answering them is the one that was audited. The authors' prototype on CPU-only AWS Nitro Enclaves ran a 4-bit Llama-3.1-8B on MMLU, XSum and ToxicChat. CPU inference cost 21.7 times as much per token as GPU inference, and the enclave roughly doubled the CPU cost; the authors expect an overhead as small as 5 times on confidential-computing GPUs. No code is linked. The design trusts the TEE vendor, and prompt-based model exfiltration remains an open gap.
## What it is

Attestable Audits is a protocol and prototype by four researchers in the University of Cambridge's Department of Computer Science and Technology [S-0009]. It targets a specific problem: benchmarks "typically do not offer verifiable results and lack confidentiality for model IP and benchmark datasets" [S-0009]. The design runs audits inside a TEE, so that a model provider and an auditor who do not trust each other can produce a result that users and regulators can verify [S-0009]. It is an implementation of TEE remote attestation for AI workloads and, through its inference step, of Model identity attestation.

## How it works

The protocol has three steps [S-0009]:

1. **Prepare.** The enclave attests its boot image and publishes a public key. The model provider sends its model, encrypted to that key. The enclave quantizes and hashes the model and posts an attestation to a transparency log.
2. **Audit.** The provider sends the model and the auditor sends its audit code and data, each encrypted. The enclave runs the audit in a sandbox and publishes an attestation that binds the model hash, the audit and the result.
3. **Inference.** The enclave loads the earlier attestations and checks that the served model's hash matches. It then answers each encrypted prompt with an attestation that links the model, prompt, output and audit result.

Verifiers compare the enclave's measurement registers with known images and check the vendor's signature [S-0009]. The paper considers two adversaries: network attackers, and privileged or physical attackers who may take RAM snapshots, roll back VMs or use side channels [S-0009].

## Evidence
The authors report the following results:

- **Setup.** The prototype ran on CPU-only AWS Nitro Enclaves with a 4-bit Llama-3.1-8B-Instruct and three benchmarks: MMLU, XSum and ToxicChat. The reported evaluation covers the audit step [S-0009].
- **Throughput.** The enclave produced 1.84 tokens per second, against 202 on an NVIDIA L40S GPU baseline [S-0009].
- **Cost.** The enclave cost $5.80 per 100K tokens, against $2.61 on a plain CPU instance with the same number of cores and $0.12 on the GPU baseline. The authors put the cost of CPU inference at 21.7 times that of GPU inference. They attribute the roughly twofold enclave cost to needing a larger instance, or giving up cores [S-0009].
- **Accuracy.** Zero-shot MMLU accuracy was 51.4% at 4-bit, against 54.6% for the unquantized model on the GPU [S-0009].
- **Loading.** Copying a model into the enclave took at most 2 minutes [S-0009].
- **Outlook.** The authors expect a production version on confidential-computing GPUs to have "an overhead as small as 5×" [S-0009].
- **Code.** The paper links no code repository [S-0009].

## Limitations
- **Vendor trust.** The approach assumes the TEE vendor is trusted [S-0009].
- **Attacks on confidential VMs.** The authors cite memory aliasing (BadRAM), ciphertext side channels (CIPHER-LEAKS) and malicious interrupts (Heckler), and propose revoking affected images when such attacks are found [S-0009]. Physical attacks on the underlying TEEs, such as memory-bus interposition, are discussed under TEE remote attestation for AI workloads.
- **Exfiltration.** The authors name prompt-based model exfiltration during user interaction as a residual gap [S-0009].
- **Model size.** Memory limits forced 4-bit quantization, which lowered MMLU accuracy [S-0009].
- **Multi-GPU.** The authors wrote that H100 confidential computing had no multi-GPU support [S-0009]. NVIDIA's August 2025 white paper describes an eight-GPU protected-PCIe mode on Hopper [S-1200].
Technical detail: - Security goals. G1 model verifiability, G2 audit verifiability, G3 confidentiality of model IP and audit data, G4 transparency of artifacts, G5 statelessness, and G6 output verifiability [S-0009]. - Adversaries. A1 is a network adversary that can intercept, tamper with or spoof messages, with denial of service excluded. A2 is a physical or privileged adversary able to take RAM snapshots, roll back VMs and run side-channel attacks [S-0009]. - PREPARE. The enclave generates a KEM key pair and attests its boot image. The provider sends the encrypted model, which the enclave quantizes and hashes. The enclave publishes an attestation linking model and quantized model to a transparency log [S-0009]. - ATTESTABLEAUDIT. The provider and the auditor send the encrypted model and the encrypted audit code and data. The enclave runs the audit in a sandbox and publishes an attestation binding model, audit and result [S-0009]. - INFERENCE. The enclave loads the earlier attestations, checks that the provider's model hash matches, and returns each encrypted response with an attestation linking model, prompt, output and audit result [S-0009]. - Verification. Verifiers check platform configuration registers (PCRs) against known images and check signatures with the TEE vendor's key or attestation service. Including the base image in the measurement allows revocation when vulnerabilities are found [S-0009]. - Prototype. The implementation is written in Rust with bindings to llama.cpp. A 4-core enclave on an m5.2xlarge instance is compared with CPU baselines on m5.xlarge and m5.2xlarge instances and an NVIDIA L40S GPU baseline. Enclave throughput was 1.84 tokens/s at $5.80 per 100K tokens, against 202 tokens/s and $0.12 on the GPU baseline. Zero-shot MMLU accuracy was 51.4% at 4-bit (57.4% excluding unparsable responses), against 54.6% for the unquantized model on the GPU. Copying models into the enclave took at most 2 minutes [S-0009].
Sources: [S-0009] Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments (2025) https://arxiv.org/abs/2506.23706; [S-1200] NVIDIA Secure AI with Blackwell and Hopper GPUs (White Paper) (2025) https://docs.nvidia.com/nvidia-secure-ai-with-blackwell-and-hopper-gpus-whitepaper.pdf

## Attestable zero-knowledge inference prover (I-0005, implementation)
Readiness (editorial assessment, rubric 1.0): R1, low confidence. R1: Attestable states the claim, its security basis and its limits, but has published no code, protocol description or artifact. - R1 met: Attestable publicly states the claim proven (an output y = F(W, x, r) for committed weights W, input x and seed r), its security basis (hash functions only, 100-bit security) and its limits [S-1101]. It also states the verification uses it proposes [S-1102] [S-1103]. - R2 not met. The rubric excludes results that are claimed but not public or not reproducible, and Attestable's figures are published without code, a protocol description or an artifact [S-1101].
Attestable's zero-knowledge prover, which the company reports proves large language model outputs came from committed weights at tens of tokens per second.
Attestable, a company, reports a zero-knowledge prover for transformer inference. It would let an AI developer prove that an output came from a committed model, input and random seed without revealing the weights. On one NVIDIA H100 GPU, Attestable reports proving a 31-billion-parameter model at 53 tokens per second for one 16,000-token sequence, and 77 tokens per second across four 4,000-token sequences. It reports proofs of a few megabytes that a CPU verifies in under a second. It also proposes using such proofs to support verifiable limits on AI development. All evidence comes from the company's blog, and no paper, protocol specification or code is public, so the results cannot be checked. The company lists its own limits: a 16,000-token context, 8-bit integer matrix multiplications, and proofs that cover only the computation they are about.
## What it is

In an August 2026 blog post, the company Attestable (Attestable) reports a prover for zero-knowledge proofs of inference on "production-scale transformer inference" [S-1101]. The post links no paper, code or technical documentation [S-1101].

Attestable reports that a proof "can establish that a committed model produced a specific output from a specific input, without revealing the model's weights or other private information" [S-1101].

## How it works

**The statement proven.** Attestable writes the proven statement as y = F(W, x, r), where:
- F is the model;
- W is the committed weights;
- x is the input;
- r is a random seed;
- y is the output [S-1101].

The proof can also bind the model configuration, the decoding parameters and "other policy-relevant values" [S-1101]. A standalone CPU verifier checks it without the weights and without rerunning the model [S-1101].

**Security basis.** Attestable reports that its results rest "only on the security of cryptographic hash functions" [S-1101]. It claims 100-bit security and post-quantum security [S-1101].

**Arithmetic.** Matrix multiplications are dynamically quantised to 8-bit integers, and non-linear operations are proven in floating point [S-1101]. The post does not name the proof system [S-1101].

**Proposed uses.** Attestable proposes two ways to deploy the prover:
- **A verification firewall** at the external interfaces of an environment that holds model weights. It would select outputs for proof at random. The selection "must remain unpredictable to the datacenter" and happen only after each output is committed [S-1103]. Attestable describes its solution as "already practical today" [S-1103].
- **Support for pacing agreements.** An auditor "could verify that an accounted workload used an approved, unchanged model rather than a newly trained replacement". Where an input classifier is required, a proof could show that the agreed classifier accepted the input [S-1102].

## Evidence
All results come from Attestable's own blog. Attestable reports these figures on a single NVIDIA H100 GPU:
- **Proofs.** Proof sizes range from 4.35 to 7.92 MiB, and CPU verification takes 157 to 648 milliseconds [S-1101].
- **Throughput.** For a 31-billion-parameter Gemma model, it reports proving 53 tokens per second for one 16K-token sequence, and 77 tokens per second across four 4K-token sequences [S-1101].
- **Accuracy.** It reports that its quantisation preserved performance on the GPQA Diamond reasoning benchmark better than a standard INT8 baseline [S-1101].
- **Comparison.** It sets these figures against an ezkl result from the end of 2023: 16 minutes to prove a 1-million-parameter model on a CPU [S-1101].

As of September 2026 no independent reproduction of these results has been published.

## Limitations
Attestable lists its current limits:
- a context window of up to 16K tokens;
- matrix multiplications quantised to 8-bit integers [S-1101].

It reports that its IFEval result "shows where the current quantization still needs improvement" [S-1101].

On coverage, Attestable writes that "a proof of some computation is not a proof of all computation" [S-1102]. It proposes pairing inference proofs with proof-of-work accounting, which would need "a credible estimate of the compute available" to the actor [S-1102].

For the firewall proposal, Attestable lists threats that the proofs do not address:
- physical attacks, such as probing memory buses;
- leakage through timing, packet sizes, power and proof-generation latency [S-1103].

As of September 2026 the protocol is unpublished, and no attack on it or security analysis of it has been published.
Sources: [S-1101] Proving LLMs at Scale (2026) https://attestable.com/blog/proving-llms-scale; [S-1102] Pacing AI Requires Proof (2026) https://attestable.com/blog/pacing-ai-requires-proof; [S-1103] From Verifiability to Model-Weight Security (2026) https://attestable.com/blog/model-weights-security

## DiFR (Divergence From Reference) (I-0002, implementation)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2. The code is public and the results reproduce on data-centre GPUs, but only its developers rely on it and no one has independently evaluated its consistency check. - R1 met: the paper states the verification claim, the specification the provider must follow and the trust assumptions [S-0016]. The assumptions are a trusted reference, calibration on trusted hardware and synchronized seeds. A companion paper embeds the method in a formal security game [S-0015]. - R2 met: public MIT-licensed code with a vLLM integration exists [S-1005]. Results are reproducible on A100 and H200 GPUs with models of 8 to 30 billion parameters [S-0016]. A separate team re-implemented it with models of up to 120 billion parameters [S-1006]. - R3 not met. On criterion (a), Amodo's prototype is a research demonstration. Amodo is not relying on DiFR for a verification decision [S-1006], and the code is research-grade. On criterion (b), no independent audit, red-team or peer-reviewed security analysis of DiFR's consistency check has been published as of September 2026. Amodo lists recomputation red-teaming as not started [S-1008]. The one independent attack targets a weight-exfiltration detector built on the same Gumbel-margin statistic [S-1507]. That attack bears on the supporting exfiltration use, assessed under Bounding unexplained information in outputs. It does not bear on the primary use.
DiFR checks that an inference provider ran its declared model by comparing output tokens or activations with a trusted re-run using the same random seed.
DiFR (Divergence From Reference) is a pair of methods for checking that an inference provider ran the model and settings it declared. Both tolerate the small numerical differences that make re-runs disagree. In Token-DiFR, provider and verifier share the random seed for token sampling. The verifier re-runs the sequence and scores how far each claimed token departs from the reference model's choice. Activation-DiFR compares compressed fingerprints of internal activations instead. On models of 8 to 30 billion parameters on A100 and H200 GPUs, both detected 4-bit quantization almost perfectly (AUC above 0.999). Token-DiFR did so within 300 output tokens and Activation-DiFR within 2. The code is public, with a vLLM integration, and a separate team has re-implemented it. The verifier needs the model weights and must know the provider's sampling procedure. Its statistical tolerance leaves a covert channel, which an independent study widened in a related exfiltration detector.
## What it is

DiFR (Divergence From Reference) is a pair of methods for checking that an inference provider performed inference correctly. The checks work despite the benign numerical noise that makes re-runs of the same model differ [S-0016]. Authors at the ML Alignment and Theory Scholars (MATS) programme, FAR AI, Anthropic and Harvard University introduced it in a 2025 preprint [S-0016].

- **Token-DiFR** compares the tokens a provider generated with the predictions of a trusted reference run that uses the same random seed [S-0016].
- **Activation-DiFR** compares compressed fingerprints of internal activations [S-0016].

A companion paper uses the same family of estimators to detect model weights hidden in inference outputs [S-0015]. The code is public under an MIT licence [S-1005].

## How it works

The provider commits to a specification: model and weights, numerical precision, sampling settings and random seed [S-0016]. Token-DiFR relies on Gumbel-Max sampling, which picks each token by adding seeded random noise to the model's scores and taking the largest. With a shared seed, the verifier knows the random noise the provider used [S-0016]. It can therefore compute which token the reference model would have chosen at each position, and how far the claimed token falls short of it [S-0016].

The verifier pools these margins over many tokens into a score. It compares the score with a threshold calibrated on trusted hardware [S-0016]. The verifier feeds the prompt and output through the model once, which gives logits and activations for every position at once [S-0016]. Because the seed pins down sampling, over 98% of tokens match exactly between provider and verifier [S-0016].

Activation-DiFR uses a shared random orthogonal projection to compress activations into short fingerprints. The verifier compares distances between its fingerprints and the provider's [S-0016]. This checks the forward pass but not the sampling step [S-0016].

## Evidence
- The authors tested Llama 3.1 8B-Instruct, Qwen3-8B and Qwen3-30B-A3B on 2,000 UltraChat prompts [S-0016]. The four inference configurations were H200 with four-way tensor parallelism, A100 with and without it, and H200 without it running Hugging Face [S-0016].
- The faults tested were FP8 key-value cache quantization, 4-bit model quantization, a temperature of 1.1 instead of 1.0, an incorrect seed, and a simulated sampling bug that picks uniformly among the top-k tokens 1% of the time [S-0016].
- The authors report that Token-DiFR detects 4-bit quantization with an AUC above 0.999 within 300 output tokens [S-0016]. Activation-DiFR does so within 2 tokens, while cutting communication by 25–75% relative to existing methods [S-0016].
- The authors report that Activation-DiFR Pareto-dominates TOPLOC in communication cost against detection accuracy [S-0016]. They also cite a report that a distributional test called RUT failed to reliably separate 8-bit quantized models. Token-DiFR detects such differences within a few thousand tokens [S-0016].
- The companion paper's detector limited exfiltratable information to under 0.5% at a false-positive rate below 0.01% on a mixture-of-experts Qwen 30B model, under benign prompt traffic [S-0015]. An independent study found that choosing the prompts roughly doubles the leakage per token [S-1507].
- Amodo Design, a separate team, re-implemented DiFR in an asynchronous recomputation prototype [S-1006] [S-1007]. It tested the prototype on models of 1.5 to 120 billion parameters on H100 and H200 GPUs [S-1006].

## Limitations
- The methods need the model weights [S-0016]. Providers can check their own traffic and users can check open-weights models, but the methods cannot verify closed-weights providers [S-0016].
- Deployment requires knowing the provider's sampling procedure [S-0016]. In Amodo's prototype, vLLM v0.25.1 used a different random-number implementation from the one DiFR expected. This produced large logit differences until Amodo forced the older model runner [S-1006].
- For Qwen3-30B-A3B, mixing A100 and H200 reference runs made the smallest tested change harder to separate from honest runs [S-0016].
- Only single-model sampling was studied. Speculative decoding was not evaluated [S-0016].
- A statistical tolerance can bound covert bandwidth but cannot close it [S-0020].
- Adversarial testing is limited. The authors show that simple adversarial temperature tuning defeats a cross-entropy baseline, while Token-DiFR still detects the change [S-0016]. An independent study reports that attacker-chosen prompts roughly double the leakage allowed by a weight-exfiltration detector built on the same Gumbel-margin statistic. This cut the detector's slowdown to 60–118 times [S-1507]. Amodo rates red-teaming of recomputation schemes as not started [S-1008].
Technical detail: - The specification φ fixes the architecture and weights, numerical precision, sampling hyperparameters and the seed of the pseudorandom number generator [S-0016]. - Token-DiFR works with Gumbel-Max sampling. From the shared seed, both parties derive the same Gumbel noise vector g. The verifier computes post-Gumbel scores zi = li + T·gi from its reference logits l and temperature T, and takes the token it would have chosen. It scores each claimed token by the logit-margin difference between the two tokens, clipped at a maximum. Scores are pooled per batch. A batch is flagged if the statistic exceeds a threshold set on a calibration set generated under φ on trusted hardware [S-0016]. Verification is one prefill pass over prompt plus output [S-0016]. The companion exfiltration paper gives a variant for inverse-probability-transform samplers [S-0015]. - Activation-DiFR has both parties generate the same random orthogonal projection P from a shared seed. P is k by D, with k much smaller than D. The provider sends f = P·a for activation vector a, possibly only for every J-th token. The verifier checks the L2 distance to its own projection [S-0016]. The authors report an AUC of at least 0.9999 with under 0.5 bytes per token [S-0016]. - DiFR works with unmodified vLLM, which exposes per-request seeds as a standard sampling parameter [S-0016]. - At temperature zero, Token-DiFR needs no seed synchronization. The verifier checks that the provider chose the most likely token at each position. The authors warn that such greedy spot checks are open to selective cheating. A provider could serve the declared model at temperature zero and a degraded one otherwise [S-0016].
Sources: [S-0016] DiFR: Inference Verification Despite Nondeterminism (2025) https://arxiv.org/abs/2511.20621; [S-0015] Verifying LLM Inference to Detect Model Weight Exfiltration (2025) https://arxiv.org/abs/2511.02620; [S-1005] adamkarvonen/difr (GitHub repository) (2025) https://github.com/adamkarvonen/difr; [S-1006] Scaling Recomputation Inference Verification (2026) https://amododesign.com/notes/2026-09-02-scaling-recomputation-inference-verification/; [S-1007] Amodo-Design/Inference-Recomputation-Prototype (GitHub repository) (2026) https://github.com/Amodo-Design/Inference-Recomputation-Prototype; [S-0020] Bit-Exact AI Inference Verification Without Performance Tradeoffs (2026) https://arxiv.org/abs/2606.00279; [S-1008] AI 2040 Plan A — Verification SITREP (2026) https://amododesign.com/ai-verification/plan-a-sitrep/; [S-1507] Adversarial Entropy Inflation Against Gumbel-Based Inference Verification (2026) https://arxiv.org/abs/2608.23375

## Low-trust AI compute verification system overview (I-0012, implementation)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1: a detailed end-to-end design with a stated claim and threat model, but no integrated implementation or results. - R1 met: the overview describes the system end to end, the rules it would support (such as inference versus training, model whitelists and blacklisted uses), a worst-case threat model in which both prover and verifier are hostile nation-states, and its practical requirements [S-0018]. - R2 not met. The document is a working draft that sets out the design and open research questions, not results from an integrated system [S-0018]. Its companion preprint specifies the tap subsystem and states that empirical validation is still required [S-1300]. Several building blocks remain open, including passive optical splitting at 53–112 GBaud [S-0018]. Confidence is medium: the design is detailed, but the author states that its threat model is under-developed [S-0018].
A retrofittable reference design in which network taps commit to all facility traffic, and air-gapped, independently sourced checkers later re-run randomly challenged records.
Naci Cankaya's system overview, published by MIRI's Technical Governance Team, proposes a privacy-preserving verification system that can be added to existing AI data centres, for an agreement between states that distrust each other. Network taps hash all traffic crossing the monitored boundary, and only these hashes leave the site. Later, the verifier challenges random records. The operator supplies the matching data, and at least three independently sourced computing clusters, each air-gapped inside the operator's data centre, re-run the workload and screen it, for example for training versus inference or banned uses. One-way optical links, cross-checks of every output and re-transmission by the operator limit what either side can leak. The document is a working draft, and key parts are open research questions. The main obstacles are bit-exact replay, physical security and side-channel defence. The author says the threat model is under-developed.
## What it is

Naci Cankaya's overview, from the Machine Intelligence Research Institute's Technical Governance Team, is a working draft [S-0018]. It describes the author's current best idea for a privacy-preserving, retrofittable AI compute verification system, meant to build confidence in an arms-control-style AI agreement [S-0018]. It offers example rules the system should support: monitorable chains of thought, cryptographic commitment of checkpoints, whitelisting of models before deployment, and a blacklist of illicit uses [S-0018].

The author argues that checking aggregate properties, such as total training FLOPs, is not enough, and sets collision-resistant evidence capture of individual workloads as a requirement [S-0018]. He assumes the worst case on both sides: the prover may covertly break the agreement's rules, and the verifier may try to exfiltrate the prover's secrets [S-0018].

## How it works

The design separates capturing evidence from evaluating it [S-0018].

### Evidence capture

- **Network taps.** Taps on the monitored links hash traffic in groups of packets at line rate [S-0018]. See Network taps and certifiers.
- **Shared hash stream.** The hashes leave over a split, sanitized fibre, so prover and verifier see identical copies. The prover recomputes the hashes from its own copy of the traffic, confirming that the tap sent nothing but legitimate commitments [S-0018].
- **Prover-held data.** Beyond hashes, no information is shared with the verifier; the prover keeps the plaintext and a manifest [S-0018].
- **Memory challenges and wiping.** These are an optional second form of evidence [S-0018]. See Timed challenge-response and memory-occupation challenges and Memory wiping and proofs of secure erasure.

A companion preprint specifies a secure gateway device for the taps that needs no processor trusted by both parties [S-1300].

### Evidence evaluation

1. The verifier issues a challenge over a one-way link enforced by a data diode [S-0018].
2. The prover supplies the matching data, manifest entries and replay metadata [S-0018].
3. Each party's trusted computing base checks the hashes, re-runs the computation under the declared metadata and screens it for compliance [S-0018]. See Deterministic and bit-exact inference.
4. The trusted computing bases cross-check their verdicts, and nothing is released unless they agree; by default, disclosure is minimal [S-0018].

A missing or mismatched record fails the challenge, while a failed replay or a disagreement triggers investigation [S-0018]. The evaluation hardware is at least three distinct trusted computing bases from different supply chains, trusted respectively by the prover, the verifier and a third party, each inside its own air-gap in the prover's data centre [S-0018]. Zero-knowledge proofs are a tentative "plan B" for evaluation, if they mature [S-0018]. See Zero-knowledge proofs of inference.

### Subsystems

The design avoids the need for mutually trusted silicon with these building blocks [S-0018]:

- **Analog data movement control.** Fused fibre splitters duplicate traffic, optical isolators act as data diodes, and enclosures protect the equipment [S-0018].
- **Controlled ingress.** A one-way path carries the verifier's inputs into the auditing environment [S-0018].
- **Output cross-checks.** The prover clones the output of each verifier device with a fibre splitter, to confirm it sends nothing but the correctly computed result [S-0018].
- **Sanitized egress.** The prover re-transmits verifier outputs at batched or randomized times, blocking optical and timing side channels [S-0018].
- **Secure performance offshoring.** Untrusted fast hardware re-runs workloads, while small trusted devices compare the results [S-0018].

Side-channel defence and resource accounting support the rest of the system [S-0018]. See Side-channel suppression for isolated facilities.

## Evidence
- **Status.** The overview sets out a design and open research questions [S-0018]. Its companion tap preprint states that empirical validation is still required [S-1300].
- **Prior work it builds on.** Verde obtained bitwise-identical inference results across several NVIDIA GPUs by controlling the order of floating-point operations [S-0018]. The TrustGuard sentry, which re-executes instructions, was prototyped on an FPGA [S-0018].
- **Taps.** Amodo Design is investigating passive optical splitting at 53–112 GBaud [S-0018]. The companion preprint expects a demonstration gateway to cost roughly as much to develop as a small team of engineers for a few months [S-1300].
- **Cost target.** The author expects acceptance to depend on retrofit costs below 10% of the monitored hardware, ideally below 1% [S-0018].

## Limitations
- **Attribution.** A technical mismatch does not show whether it came from evasion, a random bit flip or faulty evaluation software [S-0018].
- **Fault leakage.** A malicious device can leak one bit per deliberately wrong output, so the design needs a fault budget [S-0018].
- **Inspector agents.** Screening agents must resist prompt injection [S-0018].
- **Physical security.** Securing every monitored data centre against covert communication is challenging [S-0018].
- **Zero-knowledge option.** Proofs work over integers, while accelerated inference accumulates floating-point rounding errors [S-0018].
- **Threat model.** The author calls the threat model section under-developed [S-0018].
Technical detail: - Capture. Evidence capture runs online at line rate. Taps parse only link-to-transport-layer structure, hash payloads over groups of packets without regard to object boundaries, and emit no timestamps, because trailing bits could encode information [S-0018]. - Replay metadata. Exact replay needs the hardware SKU, the exact weights and quantization format, the parallelism topology, the software versions and custom kernels, and the batch size of each forward pass [S-0018]. - Instructor and executor. An untrusted but fast executor re-runs the workload without seeing the claimed output, and a small, formally verifiable instructor compares its result with the prover's claim. The cited precedent is an FPGA sentry of 3,543 lines of hardware-description code [S-0018]. - Sampling statistics. P(detect at least one) = 1 - (1 - p)^n. Checking 3,000 random samples detects a 0.1% flaw rate with 95.03% probability [S-0018].
Sources: [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-1300] Fingerprinting All AI Cluster I/O Without Mutually Trusted Processors (2026) https://arxiv.org/abs/2606.10724

## Lucid sovereignty (location) certificates (I-0009, implementation)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1: a public draft with a stated claim and threat model, but nothing built or measured in public. - R1 met: the draft states what the certificate is meant to prove, the protocol, the threat model and its trust assumptions [S-1404]. - R2 not met: as of September 2026 the repository holds only the specification, with no reference implementation, code or measured location results [S-1404]. The only location figures are an illustrative example in an annex [S-1404]. Lucid's homepage states that each of its clusters can prove where it is, but neither the homepage nor the developer documentation publishes how location is determined or any results [S-1406] [S-1407]. The working group gave January 2026 as the target for a final version, and the draft is still version 0.1.0 [S-1405] [S-1404].
A draft specification, hosted by Lucid Computing, for short-lived certificates that bound where a workload runs by timing signed exchanges with fixed anchors.
Sovereignty Certificates are a draft industry specification for proving where a computing workload runs. An agent inside a trusted execution environment exchanges signed messages with anchor servers at known locations and times the replies. Signals cannot travel faster than light, so each reply time caps the distance to that anchor. A verifier checks the hardware attestation and the timings, computes a feasible region and issues a certificate that expires after a few minutes. The specification is hosted by Lucid Computing and attributed to a working group. As of September 2026 it is still draft 0.1.0, dated October 2025, with no public implementation or measured results. It trusts the hardware root of trust and the TEE, and leaves sophisticated physical attacks as a residual risk. Known attacks on delay-based location, such as faster network paths and compromised anchors, also apply.
## What it is

Sovereignty Certificates are a draft specification for "cryptographic credentials that provide verifiable, unforgeable proof of the physical location of a computing workload at a specific point in time", according to the repository README [S-1404]. The document is version 0.1.0, dated 2025-10-21, marked "Draft" and "Prepared by: Sovereignty Certificates Working Group" [S-1404]. It describes itself as an industry-led specification, not an official standard from a body such as ISO or IEC [S-1404]. It is licensed CC BY 4.0 [S-1404].

The specification applies delay-based location verification to computing devices such as CPUs and GPUs [S-1404]. Its repository sits in Lucid Computing's GitHub organization [S-1404]. The working group's website describes the group as an independent initiative [S-1405]. It lists participants by category, including chip makers, cloud providers, frontier AI labs and compute-governance organizations, without naming them [S-1405]. Lucid's homepage links to the effort and describes Lucid's own offering as attested, confidential-computing GPU clusters with data-residency controls [S-1406].

## How it works

The specification calls its method ping-based location attestation [S-1404]. Signals cannot travel faster than light, so a measured round-trip time gives an upper bound on the device's distance from each anchor [S-1404]. The specification describes the following steps [S-1404]:

1. The verifier sends the attester a fresh nonce and a signed directory of trusted anchors.
2. From inside a trusted execution environment, the attester probes several anchors chosen to give good geometry.
3. Each anchor returns a signed receipt with a timestamp and the probe's nonce, and the attester records when each reply arrives.
4. The attester bundles the receipts with a hardware attestation quote that binds a per-cycle key and the verifier's nonce to the platform.
5. The verifier checks signatures, freshness and platform integrity, then runs a deterministic multilateration to compute a feasible region.
6. The verifier issues a short-lived certificate stating the location, radius and confidence, and which policies passed.

Workloads must fail closed when a certificate expires [S-1404]. The specification argues that tunnels and VPNs add latency, so they generally cannot make a device appear closer to an anchor than it is, and usually produce geometrically inconsistent measurements [S-1404]. It requires rejecting evidence whose distance bounds have an empty or impossible intersection [S-1404]. Anchors should monitor each other's round-trip times, and an anchor that deviates from the physical baseline should be temporarily removed from the directory [S-1404].

## Evidence
- **Specification.** The draft is version 0.1.0, dated 2025-10-21 [S-1404]. The working group's site listed January 2026 as the target for a final version [S-1405]. As of September 2026 the repository still holds draft 0.1.0 and no reference implementation [S-1404].
- **Worked example.** Annex B illustrates a result with a 45 m radius and 0.92 confidence from seven anchor receipts. It is an example, not a measurement [S-1404]. For comparison, Brass and Aarne report that delay-based methods locate devices to within about 10 km to 1,000 km, depending on the algorithm [S-1400].
- **Lucid's statements.** Lucid's homepage says that "every cluster can prove where it is, whose silicon ran, what executed, and how data moved" [S-1406]. Its developer documentation lists a "Data Sovereignty & Localization" auditor, described as "Ensuring data remains within approved geographic jurisdictions" [S-1407]. Neither explains how location is determined or reports results [S-1406] [S-1407].

As of September 2026 no test deployment or measured location results have been published [S-1404] [S-1406] [S-1407].

## Limitations
- **Trusted hardware.** The threat model lets the attacker control the network and hold root on the host, including where the host is an untrusted cloud provider. It trusts the hardware root of trust and the TEE, and leaves sophisticated physical attacks as a residual risk [S-1404].
- **Key extraction.** Tee and Happel argue that keys stored on the chip, on which ping-based protocols rely, may be extractable by adversaries with physical access [S-1403].
- **General delay attacks.** Adding delay, using faster network paths and compromising landmarks are known weaknesses of delay-based location verification [S-1400]. The specification relies on signed anchor directories, HSM-protected keys, diverse and independently operated anchors, and anchor peer monitoring against some of these [S-1404].
Technical detail: The specification follows the IETF RATS architecture (RFC 9334) and the Entity Attestation Token format (RFC 9711) [S-1404]. Its roles are an Attester (a workload with a sidecar agent), a Verifier, an Anchor Fleet at fixed locations, an Endorser that publishes a signed directory of anchors with their public keys and coordinates, and a Relying Party [S-1404]. The Attester generates an ephemeral key pair each cycle. A hash binding that key and the verifier's nonce goes into a register included in the hardware root of trust's signed quote [S-1404]. The Attester may probe anchors directly or query a local trusted proxy [S-1404]. The anchors probed must be chosen to minimize geometric dilution of precision (GDOP) [S-1404]. Anchor receipts carry a high-precision timestamp of the probe's arrival, the probe's nonce and the anchor's identifier, and are signed [S-1404]. The normative text has the Verifier derive round-trip times from the receipts' timestamps; in the Annex B example, the Attester sends a UDP probe to each of eight anchors and records the local arrival time of each reply [S-1404]. Anchors must be synchronized to a precise time source, preferably UTC [S-1404]. The Verifier must reject evidence whose distance bounds have no common intersection [S-1404]. The EAT profile defines private claims for the platform quote, the ephemeral public key, the location receipts, a location claim with latitude, longitude, radius in metres and confidence, and the policies passed [S-1404]. In the Annex B example the certificate expires after 10 minutes and is renewed about every five. If a certificate expires, the workload must fail closed [S-1404]. Long-lived anchor, verifier and endorser keys must sit in hardware security modules, and signatures should use ECDSA with P-256 or stronger [S-1404].
Sources: [S-1404] Sovereignty Certificates: draft specification, version 0.1.0 (2025) https://github.com/Lucid-Computing/sovereignty-certificate-specification; [S-1405] Sovereignty Certificates Working Group (2026) https://sovcert.org/; [S-1406] Lucid Computing: Verifiable AI. Proven in hardware. (2026) https://lucidcomputing.ai/; [S-1407] Lucid Developer Platform documentation (2026) https://docs.lucidcomputing.ai/; [S-1403] GPU Fingerprinting for Location Verification (2026) https://arxiv.org/abs/2605.01930; [S-1400] Location Verification for AI Chips (2024) https://www.iaps.ai/research/location-verification-for-ai-chips

## Pearl proof-of-useful-work blockchain (I-0004, implementation)
Readiness (editorial assessment, rubric 1.0): R2, low confidence. R2 for the narrow claim that GPUs performed a given amount of matrix-multiplication work; the capacity-bounding use in Proofs of useful work and resource exhaustion is not demonstrated. - R1 met: the protocol, verifier and hardness assumption are specified [S-1105], building on a published construction [S-1609]. - R2 met: code for a full node, a GPU miner and a proof-of-work circuit and verifier is public [S-1107]. Pearl reports running it on H200 GPUs alongside LLM serving [S-1106], against miners who try to win more often than honest work allows [S-1105]. - R3 not met. Criterion (a) is arguable: Pearl reports a live network [S-1106], and an independent study counted 8,012 online workers on one mining pool [S-0071]. Criterion (b) fails: the README mentions no audit [S-1107], and that study measures how the network is used rather than auditing or attacking the protocol [S-0071]. As of September 2026 no independent security evaluation has been published.
A blockchain whose mining is designed to be a by-product of GPU matrix multiplications in AI workloads, with public node and miner code.
Pearl is a blockchain developed by Pearl Research Labs whose mining is designed to be a by-product of the matrix multiplications that AI models perform on GPUs. Each block carries evidence that a certain amount of such work was done. Pearl reports that its network is live and its code is public. It reports that a mining variant of a 70-billion-parameter model served more tokens per second on four H200 GPUs than the original model, in a benchmark that does not isolate the cost of mining. An independent study found that the network's dominant mining software appears to multiply random matrices, which verification does not distinguish from AI work. Pearl was built for blockchain consensus; its use to show that declared AI hardware has no spare capacity is undemonstrated. Its security rests on new hardness assumptions, and Pearl lists known shortcuts that let miners do less work than nominal.
## What it is

Pearl is a layer-1 blockchain developed by Pearl Research Labs (Pearl Research Labs). It replaces hash-based mining with a proof of useful work built on matrix multiplication [S-1106] [S-1107]. Its specification describes a protocol "in which the unit of mining work is FP8 matrix multiplication on GPUs" [S-1105]. This extends the integer proof of useful work of Komargodski and Weinstein [S-1105] [S-1609].

Pearl presents the scheme as "2-for-1": GPUs produce proof of work "as a side-effect of AI training and inference workloads" [S-1106]. Its public monorepo contains several components [S-1107]:
- a reference full node;
- a vLLM-based GPU miner;
- a Plonky2/STARKy-based proof-of-work circuit and verifier.

## How it works

**Mining.** A miner multiplies matrices of its choosing, which Pearl describes as "the operands of an AI training or inference workload" [S-1105]. Each block involves four steps [S-1105]:
1. Low-rank noise matrices are derived from public seeds.
2. The noised product is computed with quantised FP8 arithmetic.
3. Output tiles are hashed as lottery tickets.
4. A tile that meets the target wins the block.

The miner then subtracts lower-order correction terms to recover the useful product "at FP8-level accuracy" [S-1105].

**Checks on winning tiles.** A jackpot policy approves a winning tile only when several statistical checks pass. These checks are meant to exclude degenerate inputs [S-1105].

**Verification.** The verifier "checks one tile of the matmul, never the whole product" [S-1105]. It recomputes that tile bit for bit, which relies on deterministic GPU arithmetic [S-1105]. A zero-knowledge verifier can keep the miner's operand data private while proving that the tile satisfies the protocol rules [S-1105]. The integer whitepaper describes hash-based SNARKs (Plonky2), compressed to "below 60KB" by recursion [S-1106]. An appendix extends verification to mixture-of-experts layers [S-1105].

## Evidence
- **A live network.** Pearl's integer whitepaper states that the chain became live when the node code was made public [S-1106]. The repository supports mainnet and test networks, and has published release v1.2.1 [S-1107].
- **A serving benchmark.** Pearl reports a benchmark on four H200 GPUs comparing Llama 3.3 70B with its "two-for-one" Pearl-certified variant, which re-implements a layer with a new quantisation mechanism [S-1106]:
  - the variant reached 17,206.26 tokens per second with pipeline parallelism, and 18,291.66 with four-way data parallelism;
  - the original bf16 model reached at most 15,269.81 tokens per second, and ran out of memory with four-way data parallelism;
  - MMLU scores were close: 0.8180 to 0.8198 for the variant against 0.8193 to 0.8198 [S-1106].
- **The underlying theory.** The construction behind Pearl proves a multiplicative overhead of 1 + o(1) over naive matrix multiplication [S-1609]. Pearl's FP8 specification states a "1 + o(1) factor" overhead, without a measured percentage [S-1105].
- **Independent measurement.** Basu measured Pearl's mainnet in May 2026, counting 8,012 online workers on the AlphaPool mining pool, estimated to hold about 21% of network hashrate. String analysis suggests that the dominant mining software, from a third party, contains no inference code and generates matrices from random seeds. Random matrices passed verification in the study's tests, and a mining pool accepted shares mined with them [S-0071].

## Limitations
**Known speedups.** Pearl documents known mining speedups and the checks against them [S-1105]. It treats faster honest kernels or hardware as outside the threat model [S-1105].

**Hardness assumption.** Security rests on an informal hardness assumption specific to quantised, noised matrices [S-1105].

**Usefulness is not verified.** Verification checks the multiplication, not where the matrices came from [S-0071].

**Benchmark caveats.** The benchmark compares a Pearl-certified model with the original model, and reports no run of the same certified model without mining [S-1106].

**Fit to verification.** Pearl's proofs show that work was performed, not that no other work ran. Attestable, which proposes proof-of-work accounting for AI agreements, notes that "a proof of some computation is not a proof of all computation", and that bounding spare capacity needs a credible estimate of the compute available [S-1102].
Sources: [S-1105] Pearl Floating Point Scheme Specification (2026) https://pearlresearch.ai/Pearl_Whitepaper.pdf; [S-1106] Pearl INT Whitepaper (2026) https://pearlresearch.ai/research/int-whitepaper; [S-1107] pearl: Monorepo for the Pearl network (2026) https://github.com/pearl-research-labs/pearl; [S-1609] Proofs of Useful Work from Arbitrary Matrix Multiplication (2025) https://arxiv.org/abs/2504.09971; [S-0071] The Usefulness Gap in Proof-of-Useful-Work: An Empirical Study of Pearl's cuPOW Protocol (2026) https://arxiv.org/abs/2606.04819; [S-1102] Pacing AI Requires Proof (2026) https://attestable.com/blog/pacing-ai-requires-proof

## RAND secure inference data center (SIDC) design (I-0010, implementation)
Readiness (editorial assessment, rubric 1.0): R1, low confidence. R1: a detailed, costed design with no prototype, whose stated objectives are security properties for the operator rather than claims an outside party could check. - R1 met for the security design: the report states its protection objectives, including that each inference response is verifiable given valid weights, architecture and retrieved context. It also states its threat model and assumptions, such as a trusted setup and likely supply-chain compromise of commodity hardware [S-1510]. - R2 not met: no facility or prototype has been published, and RAND recommends prototyping key security features now [S-1510]. Confidence is low because the stated verification use is only partly addressed. The report describes internal integrity checks and audit logging, but no way for a party outside the operator to verify the facility's properties, and it omits architectural blueprints and detailed implementations from the public version [S-1510].
A RAND design for a purpose-built facility that serves already-trained AI models while protecting weights and inference data against state-level attackers.
RAND's secure inference data center (SIDC) is a design for a compact, purpose-built facility that serves already-trained AI models, for example to national-security users. It aims to keep model weights, inference algorithms, prompts and responses confidential and intact against a well-resourced, state-backed attacker. The facility is split into physically isolated realms linked only by one-way data diodes in a fixed layout, with formally verified protocols at every boundary, human screening of each prompt and response, and checks of loaded weights against reference measurements. RAND estimates $37–50 million for a proof-of-concept and $277–345 million for an enterprise-scale facility, built in as few as 14 months under emergency or national-priority conditions. It is a published design, and RAND recommends prototyping its key security features now. It describes no way for an outside party to check the facility's properties, and its guarantees rest on an uncompromised setup phase.
## What it is

RAND's *Highly Secure Inference Data Centers* report, published in August 2026, sets out a strategy for secure inference data centers (SIDCs): purpose-built facilities designed to protect AI models from advanced nation-state adversaries [S-1510]. SIDCs are compact facilities that deploy models already trained elsewhere [S-1510]. The authors write for AI laboratories, cloud providers and government stakeholders who need to protect strategically important deployments [S-1510].

The target adversary is at RAND's OC5 level: an operation comparable to about 1,000 experts working years ahead of the public state of the art, over several years, with a budget of up to $1 billion and state-level infrastructure [S-1510]. The report states these protection objectives:

- confidentiality and integrity of the copies of model weights, inference algorithms and reference data inside the facility [S-1510];
- confidentiality and integrity of prompts and responses while they are inside [S-1510];
- verifiability of each inference response, given valid weights, model architecture and the context retrieved from reference data [S-1510];
- resilience, so that compromise of any single subsystem or person does not enable a violation of these objectives [S-1510].

The objectives are defences against outside attackers. The public report does not describe how a party other than the operator would check that they hold [S-1510].

## How it works

The design rests on three invariants [S-1510]:

- **Realm partitioning.** The facility is divided into security domains that do not trust one another [S-1510].
- **Fixed diode-gated topology.** All communication between realms passes through data diodes in a fixed arrangement, which enforce one-way flow at the physical layer [S-1510]. See Bandwidth limits and compartmentalization.
- **Verified boundary protocols.** Every crossing between realms is mediated by a protocol implementation verified against its security specification [S-1510].

### Realms

A realm is a physically isolated domain with exclusive control over its compute, storage, devices and personnel access [S-1510]. The main realms are:

- **Interface room (IR).** The only point of contact with users. Staff screen plaintext prompts and responses here [S-1510].
- **Payload exchange room (PER).** It accepts only two inbound payloads: prompts, passed to the IR, and reference-data updates, passed to the information technology management realm (ITM) [S-1510].
- **Information technology management (ITM).** It ingests and validates vetted reference data under two-person integrity controls [S-1510].
- **Trusted inference compute sanctum (TICS).** It holds the weights, the inference algorithm, reference data storage and all compute hardware [S-1510].
- **Trustworthy recovery vault (TRV).** It keeps read-only copies of critical state and the reference measurements, as the integrity anchor for the TICS [S-1510].
- **Protection operations center (POC).** It receives hazard signals from every realm over one-way inbound channels and leads incident response [S-1510].

### Serving a request

In the report's example, a national-security user submits a signed, encrypted prompt over a classified network [S-1510]:

1. The PER receives the prompt and passes it to the IR [S-1510].
2. IR staff screen the prompt for compliance and adversarial inputs, then pass it to the TICS [S-1510].
3. The TICS checks that the resident weights and reference data match the reference measurements held in the TRV, and produces the response [S-1510]. See Model identity attestation.
4. IR staff screen the response, which leaves through the PER [S-1510].

### Monitoring

Any deviation from expected control, data, matter, energy or personnel flows raises a hazard and triggers immediate containment [S-1510]. Power delivery, heat and electromagnetic emissions are measured continuously and kept within bounds [S-1510]. See Side-channel suppression for isolated facilities. All realms keep audit logs of interactions within and between realms [S-1510].

### Trusted setup

A trusted setup phase establishes the root of trust [S-1510]:

- All hardware is destructively sampled and verified before installation. Components that pass are sealed, logged and installed under two-person integrity controls [S-1510].
- Cryptographic keys are generated inside the facility and bound to verified hardware [S-1510].
- Weights and reference data are checked against reference measurements supplied by the model provider [S-1510].

The authors assume that supply-chain compromise of commodity compute hardware is likely [S-1510]. Their "concept to circuit" method traces each security requirement down to formally verified protocols and circuit-level designs [S-1510].

## Evidence
- **Design and cost study.** RAND estimates $37–50 million for a proof-of-concept facility and $277–345 million for an enterprise-scale version [S-1510]. It reports that an SIDC can be built today with proven, off-the-shelf compute hardware, and that no fundamental research breakthroughs are required [S-1510].
- **Schedule.** Construction and deployment could take as few as 14 months under emergency or national-priority conditions, and two to two and a half years otherwise, plus time for accreditation [S-1510].
- **No prototype yet.** RAND recommends prototyping key security features and integration now, and notes that FPGA-based channel control with formally verified protocols and optical diodes can be tested immediately [S-1510]. Its other recommendations are to begin procurement, engage a system integrator and select a site early [S-1510]. Intelligence Security Laboratories, a nonprofit led by one of the report's co-authors, states that it aims to develop and demonstrate the security that critical AI deployments need, applies the same STPA-Sec method, and points to the report for details [S-1706] [S-1707].

## Limitations
- **Trusted setup.** The facility cannot detect compromise that happened before ingestion if the trusted setup itself was compromised [S-1510].
- **No external check.** The public report omits architectural blueprints, detailed technical implementations and deployment procedures, and says these must be evaluated privately with stakeholders [S-1510]. It describes internal checks, audit logging and accreditation, but no verification path for outside parties [S-1510].
- **Scope.** The facility does not defend against undetected biases or latent model behaviours [S-1510].
- **Latency.** Human review makes a full request–response cycle take three to five minutes; automating some human-mediated steps could bring the overhead under a minute [S-1510].
- **Time horizon.** The security claims are framed over a five-year operational period, and the authors expect resistance to long OC5 campaigns to weaken the longer the facility operates [S-1510].
Technical detail: - Assurance chain. The cross-realm solution that mediates every boundary crossing is justified step by step [S-1510]. A hazard analysis (STPA-Sec) justifies the component, and the requirements are allocated in a system model. A finite-state protocol specification fixes authorized behaviour, sequencing, timing and fail-secure transitions. Cryptographic protocol analysis with Tamarin and CryptoVerif covers end-point authentication, secrecy, replay resistance and key freshness under stated assumptions, and state-machine model checking shows that unsafe control states are unreachable. The specified behaviour can then be translated into synthesizable hardware logic, such as FPGA-based channel control, and circuit-level assertions can check selected temporal properties at the register-transfer level [S-1510]. - Hardware assumptions. Cost estimates assume 150 GPUs at about 250 kW for the proof-of-concept and 375 GPUs at about 3 MW at enterprise scale; the design is agnostic to the accelerator type [S-1510]. - Staffing. About 100 cleared staff for a proof-of-concept and 300 for a deployment-scale facility [S-1510]. - Schedule. The 14-month estimate assumes emergency or national-priority conditions and a government-owned facility built inside an existing hangar or warehouse. Otherwise RAND expects two to two and a half years to deploy, plus about a year for accreditation [S-1510].
Sources: [S-1510] Highly Secure Inference Data Centers: A Vertically Integrated Strategy for Security Engineering (2026) https://www.rand.org/pubs/research_reports/RRA4827-1.html; [S-1706] Intelligence Security Laboratories: Building secure infrastructure for transformative AI (2026) https://intelligencesecuritylaboratories.org/; [S-1707] Our Team: Intelligence Security Laboratories (2026) https://intelligencesecuritylaboratories.org/team/

## SASH confidential network logger (I-0008, implementation)
Readiness (editorial assessment, rubric 1.0): R1, medium confidence. R1: public code exists, but it runs a toy model through a software proxy with no stated adversary. - R1 met: SASH publicly describes the design (a traffic-splitting logger plus sampled recomputation on a mutually inspected cluster), the claim (inference rather than training) and its stated limitations [S-1320]. Public code exists [S-1319]. - R2 not met: the implementation does not run under conditions representative of the verification use in any key respect. The model is Gemma 3 270M on a CPU inference image, and the logger is a software proxy [S-1319]. The hardware demonstration used DGX Spark GPUs and Raspberry Pis [S-1320]. The only adversary is a demo switch that replaces outputs with random characters [S-1319]. As of September 2026 no evaluation by others has been published. Confidence is medium: the code can be read directly, but the hardware demonstration is known only from SASH's blog post.
An open-source prototype that routes a facility's inference traffic through a logger and re-runs requests on a separate cluster to check it serves inference.
The Singapore AI Safety Hub (SASH) describes confidential network loggers (CNLs) as systems that split and copy traffic leaving a data centre's cable. In SASH's planned next prototype, an FPGA certifies the traffic it sees, and a random sample of inputs and outputs goes to a separate recomputation cluster, which re-runs them on its own model copy and flags mismatches; the verifier would see only encrypted hashes. The aim is to show a facility serves inference, not training. The first prototype's code is public; it re-runs every request rather than a sample and computes no hashes. A hardware demonstration used DGX Spark GPUs and Raspberry Pis. As of September 2026 it has not been tested at realistic scale or against a stated adversary. SASH says the recomputation cluster's security cannot yet be monitored, that a Raspberry Pi logger ties the design to particular supply chains, and that side channels remain.
## What it is

The Singapore AI Safety Hub (SASH) describes an international collaboration to build inference-verification mechanisms that distinguish model inference from training in data centres [S-1320]. Its early partners include the Oxford Martin AI Governance Initiative and the Future of Life Institute [S-1320]. The researchers span Singapore, the US, the UK, Hungary, Canada and Germany [S-1320].

The core component is a Confidential Network Logger (CNL): "specialised traffic analysis systems which split and copy network traffic coming out of a cable" [S-1320]. SASH argues that, unlike on-chip mechanisms, CNLs "can be installed on most datacenters" [S-1320]. The first prototype is published as open-source code under the MIT licence, and its README calls it "a prototype demo for verifying LLM inference" [S-1319]. It implements network logging combined with recomputation. SASH's planned next prototype samples requests, while the published code re-runs all of them [S-1320] [S-1319].

## How it works

SASH describes the flow planned for its next prototype as follows [S-1320]:

1. An FPGA placed between the host's cluster and its output gateway issues "cryptographic certificates attesting to the encrypted traffic it has seen" as traffic passes through [S-1320].
2. A random sample is sent to a recomputation cluster "which has been mutually inspected by both parties" and houses another copy of the model [S-1320].
3. The cluster recomputes the received inputs, and an alarm is triggered if the outputs do not match [S-1320].

SASH says the verifier would see only "encrypted hashes" of inputs and outputs, so it can tell whether they match without reading them [S-1320]. SASH motivates the approach by the different traffic patterns of the two workloads [S-1320]. It describes inference as many small bursts of activity on relatively few GPUs, and training of large models as sustained, cyclical activity on many GPUs [S-1320].

The published code splits the system into a gateway, a network logger, a main cluster, a recomputation cluster and a dashboard [S-1319]:

- The gateway encrypts each request and passes it to the logger [S-1319].
- The logger forwards it to the main cluster, then sends the request and response to the recomputation cluster, and releases the response only if the check passes [S-1319].
- The recomputation cluster re-runs the request and compares the response text for an exact match [S-1319].

In this version, every request is forwarded for verification and no hashes of the traffic are computed; the random sampling and hashes described in the blog post belong to the planned next prototype [S-1319] [S-1320]. Reproducible inference, which exact matching needs, is covered in Deterministic and bit-exact inference.

## Evidence
- **Hardware demonstration.** In SASH's demonstration, "a pair of DGX Spark GPUs sit in for the audited datacenter and recomputation cluster", and Raspberry Pis stand in for the logger and the data-centre frontend [S-1320].
- **Public code.** The code's container setup serves the Gemma 3 270M instruction-tuned model on a CPU inference image, and a demo switch simulates covert training by replacing output with random characters [S-1319].
- **Next prototype.** SASH says a further prototype with an FPGA is planned [S-1320].

## Limitations
SASH lists the following [S-1320]:

- "There is no means to monitor the security of the recomputation cluster" [S-1320].
- Using a Raspberry Pi 5 as the logger locks the design into Broadcom and Arm supply chains [S-1320].
- Future versions would add zero-knowledge proofs to the recomputation method, eliminate a wider range of side-channel vulnerabilities, and scale the design to production traffic volumes [S-1320].

The general limitations of network taps, such as covert capacity in model outputs and line-rate hashing, are covered in Network taps and certifiers.
Technical detail: - Services. The repository starts five services together: a Svelte dashboard (port 5173) and FastAPI services for the gateway (8010), network logger (8020), main cluster (8030) and recomputation cluster (8040) [S-1319]. - Gateway. It wraps each inference request in an envelope encrypted with AES-GCM-SIV, using a 256-bit key derived by SHA-256 from a configured host key and a nonce derived from the request ID and direction, and posts it to the network logger [S-1319]. - Network logger. It forwards the encrypted request to the main cluster, then posts the encrypted request and response to the recomputation cluster's /verify endpoint. It returns the response only if the result is "verified"; otherwise it returns an HTTP 400 "Recomputation failed" [S-1319]. - Recomputation cluster. It decrypts both, re-runs inference and compares response text for exact equality. Inference calls an OpenAI-compatible endpoint with seed 0 [S-1319]. - Model and demo modes. The Docker configuration serves google/gemma-3-270m-it on a CPU vLLM image, and a mock mode returns placeholder text. A demo switch replaces output characters with random hex characters to "simulate covert training" [S-1319]. - Difference from the blog post. In this version the logger is an inline software proxy that forwards every request for verification and computes no hashes of the traffic, whereas the blog post describes random sampling and hashes for the next, FPGA-based prototype [S-1319] [S-1320].
Sources: [S-1320] Internationalising AI Verification (2026) https://www.aisafety.sg/blog/making-ai-verification-international; [S-1319] inference-verification: Inference Verification Prototype (2026) https://github.com/sg-ai-safety-hub/inference-verification

## Tinfoil model identity (Modelwrap) (I-0006, implementation)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2. Public code runs on production hardware, but almost all the evidence comes from Tinfoil and no independent evaluation exists. - R1 met: the design is published [S-0013]. - R2 met: a public working implementation under an MIT license [S-1209] is deployed on realistic hardware, AMD SEV-SNP or Intel TDX with NVIDIA H100, H200 or B200 (provider-reported) [S-1206]. Build results are reported for models of up to 554 GB [S-0013]. - R3 not met. Criterion (a) is met only on the provider's own account: Tinfoil reports running the feature in a production service [S-1207] [S-1208]. Criterion (b) fails. As of September 2026 no independent audit, red-team or peer-reviewed analysis of Modelwrap or Tinfoil's model-identity chain has been published. Independent research on the underlying TEEs used physical access to forge Intel TDX attestations and, by pairing them with relayed H100 attestations, passed a workload outside TEE protection [S-1202]. Other independent research forged AMD SEV-SNP attestations [S-1210] [S-1212]. Tinfoil's documentation acknowledges physical attacks [S-1206].
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.
Tinfoil reports running AI inference inside hardware enclaves: AMD or Intel confidential virtual machines with NVIDIA GPUs in confidential-computing mode. Its open-source Modelwrap tool lets clients check which weights are served. Modelwrap packs the weights into a read-only disk image with a 32-byte Merkle-tree commitment. That hash is written into the enclave's measured boot configuration, and the kernel checks every block read against it. Clients check the hardware-signed attestation against measurements published through Sigstore, and anyone can rebuild the hash for a public model. As of September 2026 no independent security evaluation has been published. The chain inherits the limits of the underlying TEEs. Researchers with physical access have forged Intel TDX and AMD SEV-SNP attestations, and a software-only attack forged SEV-SNP attestations until AMD patched it. For private models, clients can confirm only that the same weights are served each time.
## What it is

Tinfoil reports that it operates an AI inference service inside secure enclaves. It runs on AMD EPYC processors with SEV-SNP or Intel Xeon processors with TDX, together with NVIDIA H100, H200 or B200 GPUs in confidential-computing mode [S-1206]. Its stated trust model is that clients trust the hardware manufacturer, but not the cloud provider's software stack, the hypervisor or the host OS [S-1206].

Modelwrap is Tinfoil's open-source tool, under an MIT license, that "builds reproducible dm-verity EROFS images of Hugging Face models" [S-1209]. It lets clients check which weights the service is running [S-0013]. The chain implements model identity attestation on top of TEE remote attestation.

## How it works

Tinfoil states the problem as follows: "attestation measures launch state, not runtime state", and weights are read from disk after the enclave boots [S-0013]. The system works in three phases [S-0013]:

1. **Commit.** Modelwrap builds a normalized, read-only image of a pinned model revision and computes a Merkle-tree root hash.
2. **Bind.** The root hash is passed to dm-verity on the kernel command line, which the enclave measurement covers, so the attestation vouches for the hash.
3. **Enforce.** Whenever the inference server reads the weights, dm-verity checks each block against the attested root and fails on any mismatch.

Tinfoil contrasts this with signing weights, for example with Sigstore Model Transparency. It argues that a signature protects the weights only at the moment it is checked, while a malicious hypervisor could alter the disk afterwards [S-0013].

The rest of the boot chain is measured too: firmware, kernel, initrd and a configuration file. The enclave checks each GPU's attestation at boot and does not start if the check fails [S-1207]. Tinfoil's software development kit (SDK) then runs the client-side checks:

- it verifies the attestation back to the CPU vendor's root certificate;
- it compares the measurements with a Sigstore-published record of the expected values;
- it binds the TLS connection to the key in the attestation [S-1207].

For a public model, anyone can rerun Modelwrap on the same Hugging Face commit and compare root hashes. For a private model, the customer builds the image and can encrypt it with dm-crypt, and the attestation shows only the root hash [S-0013]. Tinfoil lists billing and account management as closed-source components outside the security-critical path [S-1207].

## Evidence
- **Reported costs.** Tinfoil reports that the hash tree adds about 0.8% to storage and that builds take 5 s for a 549 MB model and 13 min 25 s for a 554 GB model. Cold-cache loading takes about 80% longer with verification, but inference runs at full speed once the weights are in GPU memory [S-0013].
- **Public code.** Modelwrap is public under an MIT license, and v0.3.0 was the latest release in September 2026 [S-1209].
- **Production use.** Tinfoil reports serving each model from multiple enclaves in its production deployment [S-1208]. Its attestation architecture checks model volumes against Modelwrap commitments at boot [S-1207].

## Limitations
Tinfoil documents several limitations of enclaves [S-1206]:

- an attacker with physical access "can potentially compromise the enclave", with demonstrated attestation forgery for Intel TDX and key extraction for AMD SEV-SNP;
- timing, power and electromagnetic side channels;
- host observation of access patterns and I/O;
- denial of service, supply-chain compromise and rollback.

Other limits:

- **GPU binding.** Independent researchers report that NVIDIA does not bind the H100 to the identities of specific VMs. By pairing relayed H100 attestations with forged TDX attestations, they made a system running outside TEE protection pass both checks [S-1202]. Tinfoil's GPU check runs inside the enclave at boot [S-1207].
- **Private models.** Clients learn only that the same weights are served each time [S-0013].
- **Audit-time verification.** Tinfoil "does not provide a supported tool for querying these records", and it notes that rebuilding binaries to check measurements independently is expensive [S-1208].
Technical detail: - Build. Modelwrap downloads a pinned Hugging Face revision, normalizes the directory structure so the result is reproducible, and writes an EROFS image. It then computes a dm-verity root hash, a 32-byte commitment, with veritysetup [S-0013]. Its outputs are the image and a metadata file holding the root hash, offset and verity UUID. An encryption mode supports private models [S-1209]. - Binding. The root hash goes on the kernel command line, which the enclave measurement includes. At runtime dm-verity checks each block read by the inference engine against the root and fails on any mismatch [S-0013]. - Boot chain. The CPU measures the OVMF firmware first, then the kernel and initrd. A tinfoil-config.yml is checked against a hash on the kernel command line. The enclave checks each NVIDIA GPU's attestation with NVIDIA's local-gpu-verifier to confirm confidential-computing mode, and aborts the boot if the check fails. Model volumes are mounted read-only and checked against their Modelwrap commitments [S-1207]. - Client check. The SDK verifies the attestation certificate chain to the CPU vendor's root and verifies a Sigstore bundle of expected measurements. It then confirms that the TLS public key matches the key in the attestation document [S-1207]. - Reported costs. The hash tree adds about 0.8% to image size, and builds take 5 s for a 549 MB model and 13 min 25 s for a 554 GB model. Cold-cache loading takes about 80% longer [S-0013].
Sources: [S-0013] How Tinfoil Proves Exactly What Model Is Running (2026) https://tinfoil.sh/blog/2026-02-03-proving-model-identity; [S-1206] A primer on secure enclaves (2026) https://docs.tinfoil.sh/verification/secure-enclave-primer; [S-1207] Backend infrastructure (2026) https://docs.tinfoil.sh/verification/attestation-architecture; [S-1208] How verification works in Tinfoil (2026) https://docs.tinfoil.sh/verification/verification-in-tinfoil; [S-1209] modelwrap: Reproducible dm-verity read-only image of Huggingface models (2026) https://github.com/tinfoilsh/modelwrap; [S-1202] TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (2026) https://tee.fail/; [S-1210] Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing (2026) https://batteringram.eu/; [S-1212] RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP (2025) https://rmpocalypse.github.io/; [S-1213] SEV-SNP RMP Initialization Vulnerability (AMD-SB-3020) (2025) https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3020.html

## TOPLOC (I-0001, implementation)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2. The code is public and peer-reviewed tests ran on real GPUs, but only Prime Intellect relies on it and no one has evaluated its security independently. - R1 met: the peer-reviewed paper sets out the design, the claim and the threat [S-1000]. The claim is that the provider used the stated model, prompt and precision. The threat is undisclosed changes to any of them. - R2 met: a public MIT-licensed implementation exists [S-1001]. The paper reports results on A100 and RTX 4090 GPUs across several models, attention implementations and one- and two-GPU tensor parallelism [S-1000]. Prime Intellect also reports using it in a 32-billion-parameter decentralized training run [S-1003]. - R3 not met. Criterion (a) asks for reliance by another party or production-grade availability. Prime Intellect's own production use might count [S-1003] [S-1004]. No other party is documented relying on TOPLOC for a verification decision. Criterion (b) asks for an independent evaluation, and it fails. No independent audit, red-team or peer-reviewed security analysis has been published. DiFR's comparison measures detection accuracy against communication cost [S-0016]. It is not a security evaluation.
TOPLOC is a hashing scheme from Prime Intellect that lets a verifier check whether an inference provider ran the model, prompt and precision it claims.
TOPLOC is a hashing scheme for checking that an inference provider ran the model, prompt and numerical precision it claims. During generation, the provider records a compact fingerprint of the model's largest last-layer activations. A verifier re-runs the sequence in one pass and checks that the fingerprints match within set tolerances. The tolerances absorb harmless differences between GPUs. The peer-reviewed paper reports catching every tested change to model, prompt or precision, with no false positives or negatives. Proofs take 258 bytes per 32 generated tokens. TOPLOC is open source. Prime Intellect, its developer, uses it to accept or reject work from untrusted computers in its decentralized training and data-generation runs. As of September 2026 no independent security evaluation has been published. The authors list attacks it cannot yet catch, such as speculative decoding with a cheaper model. Subtle changes are also harder to detect than large ones.
## What it is

TOPLOC is a method for checking that an inference provider used the model configuration it claims [S-1000]. It hashes intermediate activations with a compact locality-sensitive hashing scheme, a kind of hash that gives similar outputs for similar inputs [S-1000]. Researchers at Prime Intellect and Together AI published it at ICML 2025 [S-1000].

The paper targets providers that run open-weights models on their own hardware and serve them through APIs [S-1000]. It considers four undisclosed changes such a provider might make [S-1000]:

- lower precision;
- KV-cache compression;
- altered weights, whether distilled, merged or pruned;
- an altered system prompt.

The code is MIT-licensed and installable as a Python package [S-1001]. Prime Intellect reports integrations with vLLM and a fork of SGLang [S-1002].

## How it works

The provider records the 128 largest-magnitude values of the last hidden layer, and their indices, as it generates [S-1000] [S-0017]. It encodes them compactly as a polynomial and stores the result as a proof [S-1000] [S-0017]. The verifier re-runs the full sequence in a single forward pass. It recomputes the same top values and compares them with the proof [S-1000] [S-0017].

The verifier accepts if the number of exponent mismatches and the mean and median mantissa differences are all below set thresholds [S-1000]. The thresholds absorb reorderings of the computation caused by different GPU types, tensor-parallel layouts and attention kernels [S-1000].

Prime Intellect's INTELLECT-2 run combined TOPLOC with other checks. Each inference worker generated a TOPLOC proof for every sequence [S-1003]. Validators also checked termination, the logit distribution and deterministic data sampling [S-1003]. Prime Intellect reports that a later version, TOPLOC v2, adds reproducible Gumbel noise so that verifiers can also check token sampling [S-1004].

## Evidence
- The TOPLOC paper reports detecting unauthorized changes to models, prompts or precision with 100% accuracy, and no false positives or negatives in its evaluations [S-1000]. The tests used Llama 3.1-8B-Instruct, INTELLECT-1-Instruct and Gemma-2-9B on UltraChat prompts. A model-differentiation test also included Llama 3.1-70B-Instruct [S-1000]. Proofs take 258 bytes per 32 new tokens [S-1000].
- Validation held across A100 and RTX 4090 GPUs, one- and two-GPU tensor parallelism, and three attention implementations [S-1000].
- Prime Intellect reports using TOPLOC to verify rollouts from untrusted inference workers when training a 32-billion-parameter model [S-1003]. Nodes whose files fail validation are "slashed and evicted" [S-1003]. Prime Intellect also reports using TOPLOC v2 to verify thousands of nodes in SYNTHETIC-2, a distributed data-generation run [S-1004].
- The authors of DiFR, a related scheme, report that Activation-DiFR Pareto-dominates TOPLOC (does at least as well on both communication cost and detection accuracy) across their tested models [S-0016].
- Amodo Design's status page lists TOPLOC among initial recomputation schemes now being tested on relevant hardware and models [S-1008].

## Limitations
The TOPLOC paper lists five limitations [S-1000]:

- The margin separating fp8 from bf16 generation is small, and the authors did not test KV-cache compression.
- The method cannot detect speculative decoding in which a cheaper model does the decoding.
- Inference consumers could mine for "unstable" prompts that tend to fail validation.
- An attacker could spoof last-layer activations by pruning intermediate layers or using a smaller model.
- Subtle modifications are harder to detect than large ones.

The original method checks activations, not token sampling [S-1000]. Prime Intellect reports that TOPLOC v2 adds sampling checks [S-1004].

TOPLOC accepts approximate matches, so it shares the general limit of statistical schemes. It can bound an adversary's covert freedom but cannot eliminate it [S-0020].

No independent red-team or audit has been published. All deployment evidence comes from the developer [S-1003] [S-1004].
Technical detail: - The prover commits to its activations every 32 generated tokens. It takes the top-k values of the last hidden layer, with k = 128 in the main configuration. It encodes their indices and values as a polynomial over an integer field, with a modulus chosen to be injective on the index set [S-1000]. The result is k two-byte coefficients. For Llama 3.1-8B-Instruct that is 258 bytes per 32 tokens, against 262 KB for storing the embeddings directly [S-1000]. - The verifier decodes the proof and recomputes the top-k values with a prefill pass. It counts exponent mismatches and computes the mean and median mantissa differences. Validation succeeds if all three are below their thresholds. For bf16 the thresholds are 38, 10 and 8 [S-1000]. - The hardware tests used 1× A100, 1× RTX 4090 and 2× RTX 4090 GPUs, with FlashAttention 2, PyTorch SDPA and FlexAttention. The authors read the activations through a vLLM hook [S-1000]. - Prime Intellect reports that validation is up to 100 times faster than the original inference [S-1002] [S-1003]. It reports that proof generation cut tokens-per-second throughput by about 1% in INTELLECT-2 [S-1003]. - Prime Intellect reports that TOPLOC v2 adds reproducible Gumbel noise for categorical sampling, so that verifiers can check token sampling. Version 2 also extends the scheme to pipeline-parallel inference [S-1004]. - The package is published on PyPI as toploc. The latest tag is v0.1.6 [S-1001].
Sources: [S-1000] TOPLOC: A Locality Sensitive Hashing Scheme for Trustless Verifiable Inference (2025) https://proceedings.mlr.press/v267/ong25a.html; [S-1001] PrimeIntellect-ai/toploc (GitHub repository) (2025) https://github.com/PrimeIntellect-ai/toploc; [S-1002] TOPLOC: A Locality Sensitive Hashing Scheme for Trustless Verifiable Inference (blog post) (2025) https://www.primeintellect.ai/blog/toploc; [S-1003] INTELLECT-2: A Reasoning Model Trained Through Globally Decentralized Reinforcement Learning (2025) https://arxiv.org/abs/2505.07291; [S-1004] SYNTHETIC-2 (2025) https://www.primeintellect.ai/blog/synthetic-2; [S-0016] DiFR: Inference Verification Despite Nondeterminism (2025) https://arxiv.org/abs/2511.20621; [S-0017] Example Schemes for Verifying High-Stakes AI Agreements (2026) https://amododesign.com/notes/2026-06-23-verification-algorithms/; [S-0020] Bit-Exact AI Inference Verification Without Performance Tradeoffs (2026) https://arxiv.org/abs/2606.00279; [S-1008] AI 2040 Plan A — Verification SITREP (2026) https://amododesign.com/ai-verification/plan-a-sitrep/

## zkLLM (I-0003, implementation)
Readiness (editorial assessment, rubric 1.0): R2, medium confidence. R2. Public, artifact-evaluated code proves 13-billion-parameter models in peer-reviewed tests, but its authors say it is unaudited and not ready for production. - R1 met: the paper states the claim, the threat model and the security theorems [S-0023]. - R2 met: the code is public, tagged and archived on Zenodo. It received the CCS 2024 badges "Artifacts Available" and "Artifacts Evaluated--Functional" [S-1108]. The published end-to-end results use 13-billion-parameter models on a data-centre GPU [S-0023]. The stated adversary is a cheating polynomial-time prover [S-0023]. - R3 not met. The README says the code "has NOT undergone security auditing and is NOT ready for industrial applications", and that it is no longer maintained [S-1108]. As of September 2026 no third party is known to rely on it, and no independent security evaluation or reproduction of its results has been published.
zkLLM is a GPU-accelerated zero-knowledge proof system that proves a large language model's output came from committed weights without revealing those weights.
zkLLM is an academic zero-knowledge proof system for large language models, published at ACM CCS 2024. It lets a model's owner prove that its committed model computed an output, without revealing the weights. The verifier supplies the prompt and sees the output. On one NVIDIA A100 GPU, zkLLM proved one 2,048-token forward pass of LLaMa-2-13B in about 13 minutes. The 188 kB proof verifies in about four seconds. The code is public and passed the conference's artifact evaluation. The main obstacles to real use are cost and engineering maturity. Its authors state the code is unaudited, not ready for industrial use and no longer maintained. For verification, the main weakness is that it proves a fixed-point approximation of a model whose architecture must be public. Its zero-knowledge guarantee also assumes a verifier that follows the protocol.
## What it is

zkLLM is a system for zero-knowledge proofs of inference on large language models. Researchers at the University of Waterloo published it at ACM CCS 2024 [S-0023] [S-1108]. Its authors call it "the inaugural specialized zero-knowledge proof tailored for LLMs" [S-0023].

The setting has two parties [S-0023]:
- **The prover**, such as an AI company, owns a model with a publicly known structure and treats the weights as intellectual property.
- **The verifier**, such as a regulator, submits a prompt and asks for proof that the output returned is correct for that prompt and the confidential model.

The CUDA implementation is public under an MIT license [S-1108]. A tagged release, archived on Zenodo, received artifact-evaluation badges [S-1108].

## How it works

The weights are committed once, using Hyrax commitments over the BLS12-381 curve [S-0023]. For each prompt, the prover shows that the model's tensor operations were computed correctly, using sumcheck-based arguments [S-0023].

Two new components handle the hard parts of a transformer:
- **tlookup** is a parallel lookup argument for non-arithmetic tensor operations. The authors state it adds no asymptotic overhead in memory or running time [S-0023].
- **zkAttn** is a proof for softmax attention. It splits the exponential into segments, each checked by lookups [S-0023].

All values are scaled by 2^16 and rounded into a finite field [S-0023].

The public code works through a LLaMa-2 model one layer at a time:
1. Generate public parameters.
2. Commit the weights.
3. Run the proofs for normalisation, attention and feed-forward components [S-1108].

It supports LLaMa-2 models of 7 and 13 billion parameters [S-1108].

## Evidence
- **Setup.** The paper reports results on one NVIDIA A100 GPU with 40 GB of memory, 12 CPU cores and 124.5 GB of system memory [S-0023]. The models were OPT (125M to 13B) and LLaMa-2 (7B and 13B), run on 2,048-token samples from C4 [S-0023].
- **LLaMa-2-13B.** Proving took 803 seconds and produced a 188 kB proof that verified in 3.95 seconds, using 23.1 GB of memory; the one-time weight commitment took 986 seconds [S-0023].
- **Accuracy.** Perplexity changed little: for LLaMa-2-13B it moved from 6.520 to 6.528 [S-0023].
- **Comparison.** The authors compare zkLLM with an earlier system, zkML, on the same hardware [S-0023]. zkML ran out of memory beyond the size of GPT-2 (1.5 billion parameters), so its times for larger models are the authors' estimates [S-0023].
- **Artifact evaluation.** The artifact received the CCS 2024 badges "Artifacts Available" and "Artifacts Evaluated--Functional" [S-1108].
- **Use by others.** A verification system design for AI agreements uses zkLLM's figure of 803 seconds per 2,048-token forward pass on an A100 to judge ZKP overheads [S-0018].

## Limitations
**Code maturity.** The README states the code "has NOT undergone security auditing and is NOT ready for industrial applications" [S-1108]. It also names these gaps:
- prover and verifier run side by side;
- intermediate files are not meant as verifier inputs;
- an industrial deployment would need to separate the two parties and apply Fiat–Shamir [S-1108].

**Maintenance.** The repository was archived in July 2025 [S-1108]. The author states the project is no longer actively maintained [S-1108].

**Assumptions.** The paper assumes a publicly known model structure [S-0023]. Its zero-knowledge guarantee is stated for a semi-honest verifier, which "accurately reports the outcome of the proof verification" but tries to learn the hidden parameters [S-0023].

**Scope.** Proofs cover inference only [S-0023]. The authors write that extending zero-knowledge proofs to training LLMs "may pose insurmountable challenges" [S-0023].

**Attacks.** As of September 2026 no attack on the soundness of zkLLM's proofs has been published. Its security rests on the paper's soundness and zero-knowledge theorems [S-0023]. An independent analysis, whose setting follows deployments such as zkLLM, shows that valid proofs do not bind the computation spent, so a much smaller model can pass as the declared one [S-1112]. Its authors demonstrated this with another system, zkGPT, on a small transformer [S-1112]. See Zero-knowledge proofs of inference.
Technical detail: The design has four parts [S-0023]: - tlookup is a parallel lookup argument for non-arithmetic tensor operations. The authors state it adds no asymptotic overhead in memory or running time (§4). - zkAttn proves softmax attention by splitting the exponentiation into K segments, each checked with tlookup (§5). - The commitments use Hyrax, a Pedersen variant, over BLS12-381 under discrete-log hardness (§3). - Tensors are scaled by 2^16 and rounded into the field. The resulting total L1 error on the output is about 10^-2 (§7–8). The paper's security analysis is in §7.2 [S-0023]: - Theorems 7.2 and 7.3 give tlookup a completeness error of O(N/|F|). They show that a cheating probabilistic polynomial-time prover succeeds only with negligible probability. The rest of the protocol applies the sumcheck protocol and proofs of opening for committed tensors. - Theorem 7.4 covers zero knowledge. It states that a simulator with only oracle access to the output produces a view indistinguishable from the real one. The theorem assumes zero-knowledge variants of sumcheck and Pedersen commitments. The threat model assumes a semi-honest verifier (§3.6). Table 1 reports these costs on an A100 40 GB GPU at sequence length 2,048 [S-0023]: - OPT-13B took 1,270 s to commit and 713 s to prove. The proof was 160 kB, verified in 3.71 s and used 22.9 GB of memory. - LLaMa-2-13B took 986 s to commit and 803 s to prove. The proof was 188 kB, verified in 3.95 s and used 23.1 GB of memory. The public code covers LLaMa-2 7B and 13B, runs prover and verifier side by side, and is interactive [S-1108].
Sources: [S-0023] zkLLM: Zero Knowledge Proofs for Large Language Models (2024) https://doi.org/10.1145/3658644.3670334; [S-1108] zkllm-ccs2024: code for zkLLM: Zero Knowledge Proofs for Large Language Models (2024) https://github.com/jvhs0706/zkllm-ccs2024; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-1112] Hollow-LLM Attack: Computationally Trivial Weights in Zero-Knowledge Verification of LLM Inference (2026) https://arxiv.org/abs/2607.28884

## Compartmentalization (K-0017, concept)
Dividing a facility's accelerators into isolated groups with restricted communication between them, so that no group can join a larger prohibited workload.
Compartmentalization divides a facility's accelerators into groups and restricts communication between the groups, so that no group can take part in a larger workload than it is allowed [S-0005] [S-0057].

Scher and Thiergart describe pods with high-bandwidth interconnect inside and very little bandwidth between them: between pods, inference needs to pass only tokens, whereas training exchanges gradients or activations [S-0005]. Efficient inference fits within dozens to low hundreds of closely connected accelerators, while large-scale training links thousands [S-0005]. RAND's "fixed set" design likewise restricts networking so that small, fixed sets of GPUs cannot be combined into large clusters [S-0057], and Sastry and colleagues list physical limits on chip-to-chip networking as a way to enforce compute caps [S-0053]; these ideas underlie bandwidth limits and compartmentalization.

Compartments can also separate trust domains: one low-trust design air-gaps its evaluation environments and uses optical splitters and data diodes, simple components that can be inspected for tampering, to enforce one-way data movement [S-0018]. The boundaries can be checked by observing traffic between accelerators with network taps [S-0002], while physical channels that could bypass monitored links are the target of side-channel suppression [S-0038].
Sources: [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0038] Suppressing Side Channels in an Untrusted Data Center via Retrofitted Defenses (2026) https://techgov.intelligence.org/blog/suppressing-side-channels-in-an-untrusted-data-center-via-retrofitted-defenses

## Cryptographic commitment (K-0024, concept)
A way to fix a value now without revealing it, so that it can later be opened and shown not to have changed.
A cryptographic commitment lets a party fix a value now while keeping it hidden, and later reveal it with assurance that it has not changed [S-1606].

A commitment must keep the value hidden until it is opened [S-1606], and it must be binding: hard to open in more than one way [S-1607]. A Merkle hash tree commits to many items with one root hash, and any single item can later be opened with a proof whose size grows only logarithmically with the number of items [S-1607]. Its binding property reduces to the collision resistance of the hash function, meaning that finding two inputs with the same output is computationally infeasible [S-1607] [S-1600]. In AI verification, commitments fix evidence before anyone checks it:
- **Traffic.** The Oxford Martin report describes networking hardware and enclosures that make commitments about all traffic [S-0004], and tap designs produce signed hashes instead of transmitting plaintext [S-0018], as in network taps and certifiers.
- **Weights.** In zero-knowledge proofs of inference the prover commits to its weights once and proves each output against that commitment [S-0023].
- **Training.** A proposed zero-knowledge scheme combines a pre-committed training specification with Merkle commitments to intermediate computation [S-0025], as in zero-knowledge proofs of training constraints.
- **Audits.** In one scheme the prover commits to sampled weights at each training step before it learns whether that step will be audited, so that it cannot fabricate consistent records afterwards [S-0017].
Sources: [S-1606] ZKProof Community Reference (2022) https://docs.zkproof.org/reference.pdf; [S-1607] Proofs of Space (2015) https://eprint.iacr.org/2013/796; [S-1600] NIST Computer Security Resource Center (CSRC) Glossary (2026) https://csrc.nist.gov/glossary; [S-0004] Verification for International AI Governance (2025) https://www.oxfordmartin.ox.ac.uk/publications/verification-for-international-ai-governance; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0023] zkLLM: Zero Knowledge Proofs for Large Language Models (2024) https://doi.org/10.1145/3658644.3670334; [S-0025] Zero knowledge verification for frontier AI training is possible (2026) https://arxiv.org/abs/2606.05433; [S-0017] Example Schemes for Verifying High-Stakes AI Agreements (2026) https://amododesign.com/notes/2026-06-23-verification-algorithms/

## Evidence binding (K-0019, concept)
Tying verification evidence to the specific device, workload, data and time it describes, so it cannot be substituted, replayed or misattributed.
Evidence binding ties a piece of verification evidence to the device, workload, data and time it describes, so that it cannot be replayed, substituted or attributed to something else [S-1603] [S-0018].

The IETF remote-attestation architecture states the requirement for devices: evidence must be securely associated with the environment it describes, so that a verifier cannot be tricked into accepting claims that originate elsewhere [S-1603]. Binding has several dimensions:
- **Device.** Evidence is signed with key material held by the attesting device, as in TEE remote attestation [S-1603]; Scher and Thiergart note that if a chip's private key were extracted, other chips could impersonate it and spoof its location [S-0005].
- **Time.** A nonce from the appraising party, signed into the evidence, shows that it is fresh rather than replayed [S-1603], and network taps hash and timestamp the traffic they capture [S-0031].
- **Workload.** Shavit's design has chip firmware hash and sign weight snapshots taken at random times [S-0029], and one low-trust system aims to identify each forward pass uniquely and attribute it to the hardware and time that processed it [S-0018].
- **Model and data.** PAL\*M tracks dataset integrity with incremental multiset hashing inside confidential virtual machines, so that attested properties refer to the model and data actually used [S-0012].

Binding also constrains when evidence is fixed: for sampled checks, the prover must commit to its records before it learns which ones will be audited [S-0017].
Sources: [S-1603] Remote ATtestation procedureS (RATS) Architecture (RFC 9334) (2023) https://www.rfc-editor.org/rfc/rfc9334.html; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0031] The Fundamentals and Feasibility of Secure Network Taps for Verifying AI Datacenter Use (2026) https://nacicankaya.substack.com/p/research-note-the-fundamentals-and; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0012] PAL*M: Property Attestation for Large Generative Models (2026) https://arxiv.org/abs/2601.16199; [S-0017] Example Schemes for Verifying High-Stakes AI Agreements (2026) https://amododesign.com/notes/2026-06-23-verification-algorithms/

## FLOP accounting (K-0023, concept)
Estimating or verifying how many floating-point operations a training run or other workload used, often to compare against a threshold in a rule.
FLOP accounting estimates or verifies the total number of floating-point operations (FLOP) that a training run or other workload performs, usually to compare it with a threshold set by a rule [S-0029] [S-0053].

Shavit lists total training compute among the rules a verifier might enforce, noting that it has proven to be an indicator of model capabilities [S-0029]. US Executive Order 14110 required reporting for models trained with more than 10^26 operations [S-0053] until its revocation in January 2025 [S-0069], and a proposed international agreement sets a prohibited threshold of 10^24 FLOP and a monitored threshold of 10^22 FLOP [S-0063]. Proposed ways to count or cap FLOP include:
- **Hardware time.** Shavit converts a FLOP threshold into accelerator-days by assuming that every accelerator runs at its full rate with perfect parallelization, a conservative assumption that gives the fewest accelerator-days a run of that size could occupy [S-0029].
- **Energy.** Energy use can be converted into an approximate FLOP count [S-0062].
- **Telemetry.** RAND lists estimating a workload's model FLOPs utilization (MFU) and physical signature, such as power, as a research problem [S-0002], the aim of on-chip telemetry.
- **On-chip budgets.** Offline licensing ties chip use to a renewable licence carrying a compute budget [S-0057], as in hardware performance throttling and licensing.

Training compute is only a high-level proxy for capability, and algorithmic progress means thresholds may need to change [S-0053]; one system overview argues that coarse totals such as FLOP counts are not enough and seeks evidence about individual workloads [S-0018].
Sources: [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-0063] An International Agreement to Prevent the Premature Creation of Artificial Superintelligence (2025) https://arxiv.org/abs/2511.10783; [S-0062] Verification methods for international AI agreements (2024) https://arxiv.org/abs/2408.16074; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0069] Executive Order 14148: Initial Rescissions of Harmful Executive Orders and Actions (2025) https://www.federalregister.gov/documents/2025/01/28/2025-01901/initial-rescissions-of-harmful-executive-orders-and-actions

## Hardware-enabled mechanism (HEM) (K-0007, concept)
A governance or verification function built into AI chips or closely attached hardware, such as usage reporting, location attestation or enforced limits.
A hardware-enabled mechanism (HEM) is a governance or verification function built into AI chips or hardware attached to them, such as reporting how much compute was used and where, or enforcing limits on use [S-0057] [S-0006].

A 2024 RAND report introduced the concept to help achieve US AI governance goals such as export controls, and analysed the threats, attack vectors and protective measures that apply to such mechanisms [S-0057]. CNAS notes that chips sold by several leading firms already have many of the security features HEMs would need [S-0056]. Proposed designs include:
- **Offline licensing.** Use of certain chip features is tied to a renewable licence carrying a compute budget, as in hardware performance throttling and licensing [S-0057].
- **Fixed sets.** Networking is restricted so that small, fixed groups of GPUs cannot be combined into large clusters, a form of compartmentalization [S-0057].
- **Guarantee processors.** An auditable processor monitors accelerator usage inside a secure enclosure that provides physical tamper protection, as in flexHEG [S-0035].
- **Verifiable reporting.** HEMs could report properties of training, such as the quantity of compute used and the cluster's configuration or location [S-0006], the aim of on-chip telemetry and chip location verification.

A central open question is whether HEMs can stay secure when an adversary has the chips in its physical possession [S-0057].
Sources: [S-0057] Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 (2024) https://www.rand.org/pubs/working_papers/WRA3056-1.html; [S-0006] Hardware-Enabled Mechanisms for Verifying Responsible AI Development (2025) https://arxiv.org/abs/2505.03742; [S-0056] Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing (2024) https://www.cnas.org/publications/reports/secure-governable-chips; [S-0035] Flexible Hardware-Enabled Guarantees for AI Compute (2025) https://arxiv.org/abs/2506.15093

## Inference and training workloads (K-0025, concept)
Training updates a model's weights from data; inference runs fixed weights to produce outputs, and their different resource use underpins several verification methods.
Training is the workload that updates a model's weights step by step from batches of data, and inference is the workload that runs a model with fixed weights on inputs to produce outputs such as tokens [S-0029] [S-0018].

RAND's verification framework treats declared training and declared inference as distinct uses of compute, each to be verified [S-0002]. Sastry and colleagues note that most AI compute is used for inference, although a single training run needs far more compute than a single inference, and individual copies of a model can run on relatively little compute [S-0053]. Verification designs use the differences in resource use:
- **Communication.** Large-scale training links thousands of accelerators and exchanges gradients or activations between groups of them, while inference between pods passes only tokens [S-0005]; bandwidth limits rely on this gap.
- **Power and utilization.** Training and inference often differ in accelerator utilization and power draw [S-0005], which workload classification from telemetry and side channels uses.
- **Telemetry.** One classifier using GPU telemetry reports 98.2% binary accuracy at identifying training across its corpus of nine GPU models, falling to 43–87% on the most challenging disguised workloads held out from its training [S-0037], as in on-chip telemetry.

Shavit notes that there is no straightforward way to tell whether an accelerator is running training or an unrelated workload [S-0029].
Sources: [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0037] Detecting Hidden ML Training With Zero-Overhead Telemetry (2026) https://arxiv.org/abs/2606.19262

## Interconnect bandwidth (K-0021, concept)
The data rate of links between accelerators or groups of them; large-scale training needs far more of it than inference, so limiting it constrains workloads.
Interconnect bandwidth is the rate at which accelerators, servers or clusters can exchange data over the links between them; it is one of the measurable specifications of AI accelerators, alongside operations per second and memory capacity [S-0053].

Large-scale training links thousands of accelerators with high-bandwidth interconnect, while efficient inference can run on dozens to low hundreds of closely connected accelerators [S-0005]. Between such pods, inference needs to pass only tokens, whereas training exchanges gradients or activations; Scher and Thiergart identify this gap as the target of bandwidth limits, as in bandwidth limits and compartmentalization [S-0005]. Inside a data centre, front-end links carry token-level inputs and outputs, while the back-end fabric between accelerators carries tensors and collective operations at much higher bandwidth, is latency-sensitive, and is harder to tap [S-0018]. A US executive order defined reportable computing clusters partly by network connections faster than 100 Gbit/s [S-0053]. The distinction between workloads could weaken if decentralized training over lower-quality compute and links becomes more viable [S-0053].
Sources: [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Network tap (K-0014, concept)
A device that copies the traffic on a network link for inspection without disrupting it; proposed for checking what AI data centres compute.
A network tap is a device that copies the traffic on a network link for inspection without disrupting normal operation [S-0031].

Passive taps observe without interfering, for example by optically splitting the light in a fibre; active taps interact with the traffic, for instance by re-timing it or modifying headers to reduce covert channels [S-0031]. RAND's verification framework includes mutually vetted devices that intercept data exchanged between accelerators and check it for discrepancies with declared uses [S-0002]. In proposed designs such as network taps and certifiers, verifier-controlled taps hash and timestamp the traffic as cryptographic commitments rather than exporting plaintext, so that the prover's declarations can later be checked against them [S-0031] [S-0018]. Cankaya describes taps on the front-end links between a data centre and the outside world as the most viable, because those links carry little bandwidth [S-0031]. The back-end fabric between accelerators has far higher bandwidth and strict latency requirements, and may call for random sampling rather than full capture [S-0031].
Sources: [S-0031] The Fundamentals and Feasibility of Secure Network Taps for Verifying AI Datacenter Use (2026) https://nacicankaya.substack.com/p/research-note-the-fundamentals-and; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Numerical nondeterminism (K-0008, concept)
Differences between runs, or between machines, in the results of the same AI computation, because floating-point rounding depends on the order of operations.
Numerical nondeterminism is variation in the results of the same computation on the same inputs, across repeated runs or across hardware and software setups, that comes from floating-point arithmetic rather than from intended randomness such as sampling [S-1010] [S-0016].

Floating-point addition is not associative, so a rounded sum depends on the order in which its terms are accumulated [S-1009] [S-1010]. GPUs leave that order, their rounding strategy and their handling of subnormal numbers unspecified, and the same matrix multiplication can give different results on different GPU architectures [S-1010]. On a single machine, a Thinking Machines post finds the LLM forward pass run-to-run deterministic for a fixed batch, and traces the variation users see to kernels whose results change with batch size, which depends on server load [S-1009]. Exact replay can therefore need the original hardware model, quantization, parallelism layout, kernels and batch size [S-0018]. For a verifier, this makes legitimate variation hard to tell from real problems [S-0016], and verification designs respond in two ways:
- **Tolerate it.** Sampled inference recomputation compares outputs with a trusted reference that uses the same sampling seed [S-0016], and proof-of-learning accepts a recomputed checkpoint within a small distance of the reported one [S-0029].
- **Remove it.** Deterministic and bit-exact inference uses batch-invariant kernels [S-1009] or software emulation that predicts, bit for bit, the outputs of dense transformer blocks on four NVIDIA GPU models [S-0020].
Sources: [S-1010] Hawkeye: Reproducing GPU-Level Non-Determinism (2026) https://proceedings.mlsys.org/paper_files/paper/2026/hash/e217c271a57c365a246b0ad39e668ba8-Abstract-Conference.html; [S-0016] DiFR: Inference Verification Despite Nondeterminism (2025) https://arxiv.org/abs/2511.20621; [S-1009] Defeating Nondeterminism in LLM Inference (2025) https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0020] Bit-Exact AI Inference Verification Without Performance Tradeoffs (2026) https://arxiv.org/abs/2606.00279

## Positive and negative claims (K-0003, concept)
A positive claim asserts that something is present or happened; a negative claim, that an activity or resource is absent; a mixed claim, both.
A positive claim asserts that something is present or happened, and a negative claim asserts that an activity or resource is absent [S-0004]; a mixed claim bundles both.

Examples are the declared model being the one served (positive), there being no undeclared compute (negative) and compute running inference and not training (mixed). The Oxford Martin report observes that demonstrating the existence of an object or process is often straightforward compared with demonstrating its non-existence [S-0004]. RAND's framework mirrors the split: one subgoal verifies that declared uses of compute are accurate, and another verifies that there are no undeclared uses and no undeclared clusters [S-0002]. Proposed designs support negative claims indirectly:
- **Leaving no spare capacity.** Filling or wiping memory removes residual capacity for hidden workloads, as in memory wiping and proofs of secure erasure [S-0018].
- **Limiting communication.** Capping the bandwidth between pods at what inference tokens need, below what training gradients need, is meant to keep pods from joining a larger training run, as in bandwidth limits [S-0005].
- **Sampling.** Randomly inspecting accelerators makes it likely that at least one accelerator used in a violating run is found [S-0029].

All three act on declared hardware; Scher and Thiergart judge that detecting data centres that were never declared may be difficult [S-0005].
Sources: [S-0004] Verification for International AI Governance (2025) https://www.oxfordmartin.ox.ac.uk/publications/verification-for-international-ai-governance; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341

## Proof of (useful) work (K-0011, concept)
Evidence that a party spent a given amount of computation; in useful variants, the same work also solves a problem someone wants solved.
A proof of work is evidence that a prover spent a non-trivial amount of computation, which a verifier can check quickly; a proof of useful work makes that computation solve a problem someone wants solved [S-1607] [S-0005] [S-1608].

Dwork and Naor proposed proofs of work to protect shared resources, for example against spam and denial of service, and Bitcoin later used them to prevent double spending [S-1607]. Conventional proofs of work waste the computation, so Ball and colleagues built ones whose work solves problems such as Orthogonal Vectors and 3SUM, and showed that the work cannot be amortized across instances [S-1608]. Komargodski and Weinstein give a proof of useful work for arbitrary matrix multiplication with 1 + o(1) multiplicative overhead, so that GPUs could do AI work and blockchain mining at once [S-1609]; Pearl's specification adapts the construction to FP8 matrix multiplication [S-1105]. Attestable proposes using proof-of-work accounting to bound the compute left for unmonitored activity, as in proofs of useful work and resource exhaustion [S-1102]. A proof shows that work was done, not that no other work was done: Attestable notes that its scheme needs a credible estimate of the compute available and cannot discover a data centre that was never declared [S-1102].
Sources: [S-1607] Proofs of Space (2015) https://eprint.iacr.org/2013/796; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-1608] Proofs of Useful Work (2017) https://eprint.iacr.org/2017/203; [S-1609] Proofs of Useful Work from Arbitrary Matrix Multiplication (2025) https://arxiv.org/abs/2504.09971; [S-1105] Pearl Floating Point Scheme Specification (2026) https://pearlresearch.ai/Pearl_Whitepaper.pdf; [S-1102] Pacing AI Requires Proof (2026) https://attestable.com/blog/pacing-ai-requires-proof

## Proof of space (K-0012, concept)
A protocol in which a prover shows that it is dedicating a given amount of storage or memory, rather than computation, to a task.
A proof of space is a protocol in which a prover convinces a verifier that it is dedicating a given amount of storage, rather than computation as in a proof of work [S-1607].

In an initialization phase the prover stores data of the required size; later the verifier sends random challenges that the prover can answer quickly only if it still holds the data, because the data are expensive to regenerate [S-1607]. Dziembowski and colleagues built secure schemes in the random-oracle model from graphs with high "pebbling complexity" and Merkle hash trees [S-1607]. A related primitive, the proof of secure erasure, uses memory-filling challenges to show that a device's memory has been overwritten [S-0032]. Earlier protocols required the prover to be isolated during the protocol; Bursuc and colleagues relax this to slow communication with an outside accomplice [S-0032]. One low-trust system design applies these ideas with optional memory challenges that use response latency to check whether data is present, and with memory wiping to remove residual capacity for hidden workloads, as in timed memory-occupation challenges and memory wiping and proofs of secure erasure [S-0018].
Sources: [S-1607] Proofs of Space (2015) https://eprint.iacr.org/2013/796; [S-0032] Software-Based Memory Erasure with Relaxed Isolation Requirements (2024) https://ieeexplore.ieee.org/document/10664348/; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Prover (K-0001, concept)
The party that makes a claim about its own AI hardware, models or workloads and supplies the evidence a verifier checks.
A prover is the party that asserts a claim, such as compliance with an agreement, and tries to convince a verifier that it is true [S-1606] [S-0004].

In AI verification the prover may be a developer, another private institution or a state; under an international agreement it may be a government that constrains companies within its territory [S-0029] [S-0002]. The prover usually owns and physically controls the hardware being checked, and Shavit notes that unlimited physical access could undermine a chip's attestation and signed-firmware protections [S-0029]. He models the prover as a covert adversary that breaks the rules only if it expects to avoid detection [S-0029]. In remote attestation the corresponding role is the attester, a device whose evidence is appraised to judge how far it can be trusted [S-1603].

What the prover supplies depends on the mechanism:
- In proof-of-learning, it reports checkpoints and data batches, so that the verifier can re-run segments of training [S-0029].
- In zero-knowledge proofs of inference, it generates a proof that an output came from running its model, without revealing the weights [S-0023].
- In TEE remote attestation, its hardware produces signed evidence about the software it runs [S-1603].
Sources: [S-1606] ZKProof Community Reference (2022) https://docs.zkproof.org/reference.pdf; [S-0004] Verification for International AI Governance (2025) https://www.oxfordmartin.ox.ac.uk/publications/verification-for-international-ai-governance; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-1603] Remote ATtestation procedureS (RATS) Architecture (RFC 9334) (2023) https://www.rfc-editor.org/rfc/rfc9334.html; [S-0023] zkLLM: Zero Knowledge Proofs for Large Language Models (2024) https://doi.org/10.1145/3658644.3670334

## Recomputation (K-0009, concept)
Checking a claimed computation by re-running all of it, or a random sample, on hardware the verifier trusts and comparing the results.
Recomputation checks a claimed computation by re-running it, or a random sample of it, from the same inputs on hardware the verifier trusts, and comparing the results with those reported [S-0029] [S-0016].

Re-running a large training run in full would be very costly, so in Shavit's framework the verifier re-runs selected segments, starting from a reported checkpoint and applying the reported data batches, and accepts if the result is close to the next reported checkpoint; this is the basis of proof-of-learning and training-transcript verification [S-0029]. For inference, a trusted reference implementation recomputes what the model should have predicted at each generated token [S-0016], as in sampled inference recomputation; the same check can limit how much of a model's weights can be hidden in its responses (Bounding unexplained information in outputs) [S-0015]. Amodo Design distinguishes correctness, meaning that the workloads run match those declared, from completeness, meaning that every workload is reported, and notes that its recomputation schemes address only correctness [S-0017]. Recomputation also needs:
- **Access to inputs and weights.** This raises confidentiality problems, which Shavit addresses with a jointly trusted, air-gapped cluster [S-0029]; one low-trust design uses air-gapped auditing environments with committed weights [S-0018].
- **Commitment before sampling.** The prover must fix its records, for example by committing to a hash of sampled weights, before it learns which step will be audited [S-0017].
- **A way to handle numerical nondeterminism.** Benign noise otherwise makes legitimate variation hard to tell from real problems [S-0016].
Sources: [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0016] DiFR: Inference Verification Despite Nondeterminism (2025) https://arxiv.org/abs/2511.20621; [S-0015] Verifying LLM Inference to Detect Model Weight Exfiltration (2025) https://arxiv.org/abs/2511.02620; [S-0017] Example Schemes for Verifying High-Stakes AI Agreements (2026) https://amododesign.com/notes/2026-06-23-verification-algorithms/; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Remote attestation (K-0004, concept)
A process in which a device sends signed evidence about its state, such as software measurements, so a remote party can judge its trustworthiness.
Remote attestation is a process in which a device produces evidence about its own state, signed with keys it protects, so that a remote party can decide whether to consider it trustworthy [S-1603] [S-1600].

The IETF RATS architecture names three roles:
- **Attester.** It produces evidence: claims that may include configuration data, measurements and telemetry, typically signed with its key material [S-1603].
- **Verifier.** It appraises the evidence against reference values and an appraisal policy, and produces attestation results [S-1603].
- **Relying party.** It uses the results to decide whether to treat the attester as trustworthy [S-1603].

In the Trusted Computing Group's model, a root of trust for reporting gives attested platform characteristics their authenticity and non-repudiation [S-1602]. A nonce sent by the appraising party and signed into the evidence shows that the evidence is fresh rather than replayed [S-1603]. Attestation is not isolation: a trusted execution environment protects a workload, while attestation lets a remote party check what a genuine TEE loaded, and confidential computing requires both [S-1604]. In AI verification, attestation underlies TEE remote attestation for AI workloads and chip location verification; for location, Scher and Thiergart note that the chip's private key must not be extractable, or other chips could impersonate it [S-0005].
Sources: [S-1603] Remote ATtestation procedureS (RATS) Architecture (RFC 9334) (2023) https://www.rfc-editor.org/rfc/rfc9334.html; [S-1600] NIST Computer Security Resource Center (CSRC) Glossary (2026) https://csrc.nist.gov/glossary; [S-1602] TCG Glossary (2017) https://trustedcomputinggroup.org/resource/tcg-glossary/; [S-1604] Common Terminology for Confidential Computing (2022) https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/Common-Terminology-for-Confidential-Computing.pdf; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867

## Root of trust (K-0005, concept)
A component that anchors security functions such as measurement, storage and reporting, and must be trusted because its misbehaviour cannot be detected.
A root of trust is a hardware, firmware or software element that forms the basis of security functions such as measurement, storage, reporting, recovery, verification and update, and that must always behave as expected because its misbehaviour cannot be detected [S-1601] [S-1600].

It is typically the first element in a chain of trust and anchors more complex functions built on it [S-1601]. Because it is trusted by assumption, it must be secure by design [S-1600]. The Trusted Computing Group distinguishes a root of trust for measurement, which makes the first integrity measurement and adds it to a tamper-resistant log, from a root of trust for reporting, which vouches for platform characteristics during remote attestation [S-1602]. Shavit's framework needs hardware roots of trust on ML chips, and calls for open-source designs so that independent verifiers can check them for backdoors [S-0029]. A 2026 MIRI Technical Governance Team post describes reliance on the hardware vendor as root of trust as a significant concern for TEE-based attestation, since whoever holds the hardware's key can produce valid attestation reports [S-0014].
Sources: [S-1601] Platform Firmware Resiliency Guidelines (NIST SP 800-193) (2018) https://csrc.nist.gov/pubs/sp/800/193/final; [S-1600] NIST Computer Security Resource Center (CSRC) Glossary (2026) https://csrc.nist.gov/glossary; [S-1602] TCG Glossary (2017) https://trustedcomputinggroup.org/resource/tcg-glossary/; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance

## Sampling and assurance (K-0020, concept)
Checking a random sample of accelerators, workload segments or outputs rather than all of them, so that violations are caught with a calculable probability.
Sampling-based assurance checks a random sample of accelerators, workload segments or outputs instead of all of them, and chooses the sample size so that a violation is caught with a desired probability [S-0029].

Shavit gives a formula for how many accelerators a verifier must inspect in each monitoring period to find at least one accelerator used in a rule-violating training run with a chosen probability [S-0029]. The required number falls as the run occupies a larger share of the prover's accelerators, so larger runs need fewer inspections [S-0029]. Sampling works only if the prover cannot predict what will be checked [S-0029] or change its records once it knows; in one scheme, the prover commits a hash of sampled weights at each training step before it learns whether that step will be audited [S-0017]. The same logic applies to recomputation of random training segments in proof-of-learning [S-0029] and of random workload samples in reproducible computation packets [S-0067]. Against a covert adversary, sampling works through deterrence: one system overview notes that such an adversary is caught if it fails to stay hidden even once, and treats randomly sampled inspections as a primary defence [S-0018].
Sources: [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0017] Example Schemes for Verifying High-Stakes AI Agreements (2026) https://amododesign.com/notes/2026-06-23-verification-algorithms/; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Side channel (K-0013, concept)
An unintended path by which information leaks from a system through effects of its operation, such as timing, power draw or electromagnetic emissions.
A side channel is an unintended path through which information leaks from a system via observable effects of its operation, such as timing, power consumption, and electromagnetic or acoustic emissions [S-1600].

A covert channel is related but deliberate: two cooperating parties use an unintended channel to transfer information in a way that violates a system's security policy [S-1600]. Side channels can leak secrets that verification designs aim to protect: BarraCUDA used electromagnetic analysis to recover the parameters of neural networks running on an edge GPU [S-0043], and a 2026 MIRI Technical Governance Team post describes microarchitectural side channels as a limitation of trusted execution environments [S-0014]. Covert channels threaten the checks themselves: another post from the same team describes electromagnetic, acoustic, power-line and fibre-optic channels that could carry data around a data centre's monitored network links, and proposes shielded enclosures, jamming combined with sensing, inspection and filtering, the approach of side-channel suppression [S-0038]. One low-trust system design sets its suppression target at covert bandwidths of kilobits per second rather than zero [S-0018]. Physical signals can also serve the verifier: training and inference often differ in accelerator utilization and power draw, which workload classification uses [S-0005].
Sources: [S-1600] NIST Computer Security Resource Center (CSRC) Glossary (2026) https://csrc.nist.gov/glossary; [S-0043] BarraCUDA: Edge GPUs do Leak DNN Weights (2025) https://www.usenix.org/conference/usenixsecurity25/presentation/horvath; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance; [S-0038] Suppressing Side Channels in an Untrusted Data Center via Retrofitted Defenses (2026) https://techgov.intelligence.org/blog/suppressing-side-channels-in-an-untrusted-data-center-via-retrofitted-defenses; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867

## Tamper evidence and tamper resistance (K-0015, concept)
Tamper evidence makes interference detectable; tamper resistance makes it difficult or costly; tamper response reacts to it, often by erasing secrets.
Tamper evidence is an external indication that someone has tried to compromise a device's physical security; tamper resistance makes such attempts difficult, costly or both; and tamper response is an automatic action, at minimum erasing plaintext keys, taken when tampering is detected [S-1605] [S-1600].

The US standard for cryptographic modules, FIPS 140-2, since superseded by FIPS 140-3, layers these properties [S-1605]:
- **Level 2** requires evidence of tampering, such as tamper-evident coatings or seals, or pick-resistant locks on covers and doors [S-1605].
- **Level 3** adds detection and response circuitry that zeroizes plaintext secret and private keys when covers or doors are opened [S-1605].
- **Level 4** requires a complete envelope of protection intended to detect and respond to all unauthorized attempts at physical access [S-1605].

These properties matter because the prover usually controls the hardware: Shavit notes that unlimited physical access could undermine a chip's attestation, and relies on inspections to find hardware attacks that damage chips in ways that are hard to hide [S-0029]. The flexHEG proposal houses its guarantee processor in a secure enclosure that provides physical tamper protection (Hardware-enabled guarantees (flexHEG) and guarantee processors) [S-0035]. For verifier equipment in the prover's facility, such as network taps and recomputation servers, one verification plan names tamper-evident enclosures among promising and existing physical security methods, the subject of tamper evidence for verifier devices [S-0067]. Seals can be defeated with simple methods: a 1996 Los Alamos study demonstrated low-tech defeats for each of the 94 passive and electronic seals it examined, with a mean defeat time of 4.3 minutes for one practised person [S-1317].
Sources: [S-1605] Security Requirements for Cryptographic Modules (FIPS PUB 140-2) (2001) https://csrc.nist.gov/pubs/fips/140-2/upd2/final; [S-1600] NIST Computer Security Resource Center (CSRC) Glossary (2026) https://csrc.nist.gov/glossary; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0035] Flexible Hardware-Enabled Guarantees for AI Compute (2025) https://arxiv.org/abs/2506.15093; [S-0067] Verification Plan (2026) https://ai-2040.com/supplements/verification-plan; [S-1317] Physical Security and Tamper-Indicating Devices (1996) https://www.osti.gov/servlets/purl/459707

## Threat model (K-0018, concept)
An explicit statement of who might attack a system, what they can do, and which threats the design covers or leaves out of scope.
A threat model describes the capabilities an attacker is assumed to be able to use against a system, such as the information, computing power and control of the system available to it [S-0072].

Its purpose is to identify the threats a design must withstand and to rule others explicitly out of scope, since nearly every security system is vulnerable to a sufficiently dedicated and resourceful attacker [S-0072]. NIST treats threat modelling as a form of risk assessment that models both the attack and the defence side of a system [S-1600]. Threat models used in AI verification differ in how far each party is trusted:
- **Covert adversary.** Shavit models the prover as willing to break the rules only if it expects not to be detected [S-0029].
- **Circumvention.** The Oxford Martin report analyses states that seek to demonstrate compliance to each other while also looking for ways to circumvent verification [S-0004].
- **Mutual distrust.** One low-trust system overview assumes nation-state adversaries on both sides, including a verifier that may try to exfiltrate the prover's secrets, and relies on redundant checks across devices that each party trusts unilaterally, instead of a single chain of trust [S-0018].

Physical access is a recurring issue: Shavit notes that a prover with unlimited physical access to a chip could undermine its attestation and signed-firmware protections, and relies on physical inspections to detect such attacks [S-0029].
Sources: [S-0072] Guidelines for Writing RFC Text on Security Considerations (RFC 3552, BCP 72) (2003) https://www.rfc-editor.org/rfc/rfc3552.html; [S-1600] NIST Computer Security Resource Center (CSRC) Glossary (2026) https://csrc.nist.gov/glossary; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0004] Verification for International AI Governance (2025) https://www.oxfordmartin.ox.ac.uk/publications/verification-for-international-ai-governance; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Trusted execution environment (TEE) (K-0006, concept)
An execution area protected by the processor that keeps the data inside confidential and unaltered, and the code unaltered, even from the host's own software.
A trusted execution environment (TEE) is an execution area that the processor protects, so that software outside it, including the host operating system and hypervisor, cannot read the data inside or alter its code and data [S-1600] [S-1604].

The Confidential Computing Consortium lists data confidentiality, data integrity and code integrity as the core attributes of a TEE; code confidentiality and attestability are optional [S-1604]. Isolation and remote attestation are separate properties: the TEE protects a workload, and attestation, the validation of a hardware-signed report of what was loaded, lets a remote party check it [S-1604]. The consortium defines confidential computing as computation in a hardware-based, attested TEE, so it requires both [S-1604]. A TEE can cover a whole confidential virtual machine and extend to accelerators; PAL\*M, for example, pairs Intel TDX confidential VMs with NVIDIA H100 GPUs to attest properties of generative models [S-0012] [S-1604]. In AI verification, TEEs underpin TEE remote attestation for AI workloads and confidential multi-party verification, such as running safety benchmarks while keeping both the model and the test data confidential [S-0009]. A 2026 MIRI Technical Governance Team post notes that whoever holds the hardware's attestation key can produce valid reports, and that microarchitectural side channels and physical attacks such as bus interposition remain concerns [S-0014].
Sources: [S-1600] NIST Computer Security Resource Center (CSRC) Glossary (2026) https://csrc.nist.gov/glossary; [S-1604] Common Terminology for Confidential Computing (2022) https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/Common-Terminology-for-Confidential-Computing.pdf; [S-0012] PAL*M: Property Attestation for Large Generative Models (2026) https://arxiv.org/abs/2601.16199; [S-0009] Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments (2025) https://arxiv.org/abs/2506.23706; [S-0014] On TEEs for Privacy-Preserving Monitoring in AI Governance (2026) https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance

## Undeclared compute (K-0016, concept)
AI-relevant hardware, or uses of declared hardware, that a prover has not reported, and that verification must therefore detect or rule out.
Undeclared compute is AI-relevant hardware, or use of declared hardware, that a prover has not reported to the verifier [S-0002].

RAND's verification framework separates two cases: undeclared uses of declared clusters, and undeclared clusters, whether inside known data centres or standalone [S-0002]. The problem is sharpest for hardware that predates tracking: Shavit notes that hundreds of thousands of ML chips had already been sold, many lacking the security features his framework needs [S-0029], and Scher and Thiergart write that millions of AI-relevant chips exist with no central tracking [S-0005]. They judge that covert data centres may be difficult to detect, because AI compute can be hidden among other compute [S-0005]. Sastry and colleagues caution that more efficient algorithms and more viable decentralized training could reduce how much compute, or how concentrated, a prohibited activity needs [S-0053]. Proposed responses include:
- **Tracking hardware.** Monitoring the chip supply chain and keeping a directory of chip owners [S-0029], as in chip registries and manufacturing records.
- **Finding facilities.** National technical means such as remote sensing, energy monitoring, customs data and financial intelligence, alongside whistleblowers [S-0062], as in remote detection of data centres.
- **Bounding declared capacity.** Wiping memory to remove residual capacity for hidden workloads on declared hardware [S-0018], as in memory wiping and proofs of secure erasure.
Sources: [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0005] Mechanisms to Verify International Agreements About AI Development (2025) https://arxiv.org/abs/2506.15867; [S-0053] Computing Power and the Governance of Artificial Intelligence (2024) https://arxiv.org/abs/2402.08797; [S-0062] Verification methods for international AI agreements (2024) https://arxiv.org/abs/2408.16074; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Verifier (K-0002, concept)
The party that examines evidence supplied by, or collected about, a prover and decides whether the prover's claim holds.
A verifier is the party that examines evidence from or about a prover and decides whether the prover's claim holds [S-0004] [S-1603].

Under an international agreement the verifier may be another state, an international institution, a government body or a third party [S-0004] [S-0002]. In proof systems, soundness protects the verifier: if a statement is false, a verifier that follows the protocol will not be convinced [S-1606]. The IETF remote-attestation architecture splits the role in two: a verifier appraises evidence and produces attestation results, and a separate relying party acts on them [S-1603]. In Shavit's framework the verifier randomly samples and physically inspects accelerators, and re-runs selected training segments as in proof-of-learning [S-0029]. In low-trust settings the verifier is itself a potential adversary: one system design assumes it may try to exfiltrate the prover's secrets, so the prover distrusts the devices the verifier relies on [S-0018].
Sources: [S-0004] Verification for International AI Governance (2025) https://www.oxfordmartin.ox.ac.uk/publications/verification-for-international-ai-governance; [S-1603] Remote ATtestation procedureS (RATS) Architecture (RFC 9334) (2023) https://www.rfc-editor.org/rfc/rfc9334.html; [S-0002] Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment (2025) https://www.rand.org/pubs/working_papers/WRA4077-1.html; [S-1606] ZKProof Community Reference (2022) https://docs.zkproof.org/reference.pdf; [S-0029] What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023) https://arxiv.org/abs/2303.11341; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Weight exfiltration (K-0022, concept)
Unauthorized copying of a model's trained parameters out of the environment meant to contain them, by theft or through covert channels.
Weight exfiltration is the unauthorized copying of a model's trained parameters, its weights, out of the environment meant to contain them [S-1610] [S-0015].

RAND researchers identified 38 meaningfully distinct attack vectors for stealing frontier model weights, and defined five security levels for defending against actors ranging from opportunistic criminals to highly resourced nation-state operations [S-1610]. Exfiltration can be covert: an attacker who controls an inference server could hide weights inside ordinary model responses using steganography [S-0015]. Rinberg and colleagues verify inference outputs against a reference to limit what responses can carry; on the MoE-Qwen-30B model, under benign prompts, their detector reduced exfiltratable information to under 0.5% at a false-positive rate below 0.01% [S-0015], the approach of bounding unexplained information in outputs. Physical side channels offer another route past network monitoring [S-0038], the target of side-channel suppression. In verification the concern runs both ways: the verifier's equipment could leak the prover's secrets, so one low-trust design commits model checkpoints to an independent governing body rather than revealing them, and sends only hashes to the verifier outside the facility [S-0018].
Sources: [S-1610] Securing AI Model Weights: Preventing Theft and Misuse of Frontier Models (2024) https://www.rand.org/pubs/research_reports/RRA2849-1.html; [S-0015] Verifying LLM Inference to Detect Model Weight Exfiltration (2025) https://arxiv.org/abs/2511.02620; [S-0038] Suppressing Side Channels in an Untrusted Data Center via Retrofitted Defenses (2026) https://techgov.intelligence.org/blog/suppressing-side-channels-in-an-untrusted-data-center-via-retrofitted-defenses; [S-0018] A System Overview for Near-Term, Low-Trust AI Compute Verification (2026) https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf

## Zero-knowledge proof (K-0010, concept)
A cryptographic protocol by which a prover convinces a verifier that a statement is true while revealing nothing beyond the fact that it is true.
A zero-knowledge proof (ZKP) is a cryptographic protocol by which a prover convinces a verifier that a statement is true without revealing any more information than that fact [S-1600].

It has three properties:
- **Completeness.** If the statement is true and both parties follow the protocol, the verifier accepts [S-1606].
- **Soundness.** If the statement is false, a verifier that follows the protocol is not convinced [S-1606].
- **Zero knowledge.** If the statement is true and the prover follows the protocol, the verifier learns no confidential information beyond the fact that the statement is true [S-1606].

The statement combines a public instance, known to both parties, with a private witness known only to the prover [S-1606]. Strictly, a proof must be sound even against a computationally unbounded prover; an argument, such as a SNARK (succinct non-interactive argument of knowledge), need only be sound against bounded ones [S-1606]. In zero-knowledge proofs of inference the witness is the model's weights: the prover publishes a commitment to them once, then proves for each query that the output equals the committed model applied to the input [S-0023]. zkLLM proved one 2,048-token forward pass of LLaMa-2-13B in 803 seconds on one A100 GPU, producing a 188 kB proof of a fixed-point approximation of the model [S-0023]. For zero-knowledge proofs of training constraints, a 2026 proposal notes that governance analyses judge such proofs currently impractical at frontier scale, and argues that this limit is not fundamental [S-0025].
Sources: [S-1600] NIST Computer Security Resource Center (CSRC) Glossary (2026) https://csrc.nist.gov/glossary; [S-1606] ZKProof Community Reference (2022) https://docs.zkproof.org/reference.pdf; [S-0023] zkLLM: Zero Knowledge Proofs for Large Language Models (2024) https://doi.org/10.1145/3658644.3670334; [S-0025] Zero knowledge verification for frontier AI training is possible (2026) https://arxiv.org/abs/2606.05433