Claims

No mechanism can yet bound a party's chip stock. Every approach is proposed (R1), and chip tracking would reach new production far better than chips already in circulation.

Chip registries and manufacturing records (R1) would follow each chip from the fab to its owner, so that inspectors can check a sample against the declared records ¹. Remote detection of data centres (R1) estimates the power capacity of large facilities from equipment visible outside ⁷. Performance throttling and licensing (R1) would cap the work that declared chips can do ⁸.

Apart from public estimates of the power capacity of known large facilities ⁷, only designs and policy analyses are public. No chip registry has been built for verification. The concentrated chip supply chain is one reason the sources treat new production as trackable ^{2 1}.

Millions of AI-relevant chips already exist with no central tracking ⁴. Domestic chip manufacture and older chips are listed as evasion routes ⁵. Draft agreements therefore pair technical measures with intelligence, inspections and whistleblowers ³.

Chip location is one of the more tractable claims, because it concerns known devices and can be checked positively. Every publicly described location scheme is still proposed (R1), however.

Chip location verification (R1) times a chip's signed replies to trusted servers, so that signal delay bounds its distance from them ^{1 2}. Lucid's sovereignty certificates (R1) are a draft specification of this approach ¹⁰. Chip registries (R1) supply the declared locations to test. Guarantee processors (R1) could automate checks of approximate chip location, and their designers want them to be retrofittable to existing chip and server designs ¹¹.

An IAPS issue brief shows a single result from a rudimentary prototype on NVIDIA H100 chips: a landmark in Singapore bounding a chip in Singapore to within 300 miles ⁷. No systematic measurements, error rates or code have been published. NVIDIA has said that it is developing delay-based location verification using its own servers ⁸. It has published no design or results, and the fleet-management software it has announced is opt-in ⁹.

The chip's private key must not be extractable, or another device can answer for it ². Sources differ on coverage: Wasil and colleagues see location tracking as limited to newly produced chips ³, while Brass and Aarne expect that the H100's trusted execution environment could implement it ⁶. A verified location says nothing about what a chip computes, so proposals pair it with checks on use ⁴.

Idleness is one of the more approachable negative claims, because computing needs power and leaves physical traces. Evidence would come from facility power data and from on-chip mechanisms that can tell whether a chip is busy; of these, only on-chip telemetry is demonstrated (R2), and that for classifying workloads rather than for idleness.

Power draw, knowledge of on-site generation and possibly thermal imaging could show that a facility's chips are unpowered ¹. On-chip telemetry (R2) and timed challenges (R1) could show whether a declared chip is busy. Licensing and throttling (R1) would make chips refuse or slow work once a licensed budget is spent ⁵. Proofs of useful work (R1) instead keep declared hardware provably busy with agreed work ⁸.

Energy monitoring is unproven in practice and open to masking ². GPU timing and memory measurements correlate with compute activity even when host and device are untrusted ⁷.

A dark facility shows only that the hardware inside it is idle, so the claim depends on knowing where the declared chips are (Chips are where they are declared to be). Where chips must stay powered for permitted work, the claim becomes a bound on use (This compute runs inference, not training, A training run stayed within declared limits).

Declared inference can be checked with demonstrated (R2) components, but the absence of training cannot yet be verified. That half rests on full-stack designs (AI 2040 inference-only verification stack, Low-trust AI compute verification system overview, SASH confidential network logger) that are proposed (R1) and not built beyond small prototypes.

Network taps (R1) capture front-end traffic, and sampled recomputation (R2) checks it against the declared model; reproducible computation packets (R1) would extend this to whole workloads. Bandwidth limits, memory wiping (both R1) and bounding unexplained information (R2) constrain what else could run or leave. Workload classification and on-chip telemetry (both R2) are lighter-touch alternatives.

Recomputation tolerates numerical noise on open-weight models of 8 to 30 billion parameters ¹¹. A telemetry classifier detects training with 98.2% accuracy on its own corpus, but 43–87% on the most challenging disguised workloads held out from its training ⁸. A team building the components reports nothing past a proof-of-principle prototype ¹³.

Training traffic runs on back-end fabric that is harder to tap, and whether all outgoing traffic can be explained by incoming traffic is an open question ⁵. Telemetry is trustworthy only with protections, such as a tamper-resistant read path, that current GPUs lack ^{8 14}.

The served model can be checked directly on its outputs, and several mechanisms for it are demonstrated (R2). None is deployment-ready (R3): independent security evaluations are either missing or, for trusted execution environments, found a critical flaw.

Sampled recomputation (R2) re-runs logged outputs on a trusted copy of the model, helped by deterministic inference (R2); TOPLOC and DiFR implement it. Model identity attestation (R2) uses TEE remote attestation (R2) to show which weights an enclave loaded, as in Tinfoil model identity (Modelwrap). Zero-knowledge proofs of inference (R2), such as zkLLM, keep weights private without trusting hardware. Confidential multi-party verification (R2) binds audit results to the served model ¹⁰.

On the authors' open-weight test models, Token-DiFR detected 4-bit quantization with AUC above 0.999 within 300 output tokens ². zkLLM proves one inference of a 13-billion-parameter model in under 15 minutes ⁷.

Evidence must be tied to the production serving path, not a test instance, and recomputation needs the verifier, or an environment both sides trust, to hold the weights ⁶. Attestation rests on hardware keys: a published memory-bus attack with physical access extracted an Intel attestation key and forged attestations ¹¹. Zero-knowledge proving remains expensive ⁶.

Safeguard application has been shown only in small research prototypes. Proof-of-guardrail demonstrates safeguard attestation (R2) ⁸. Auditor-in-a-Box demonstrates plan-scoped monitoring, and its authors state that the demo's user data and plan execution are not actually secure ¹⁰. These prototypes can show that a declared safeguard ran, not that it works.

Safeguard attestation runs the safeguard inside a trusted execution environment, whose hardware signs a measurement of its code with a commitment to each input and response ⁸. It builds on TEE remote attestation (R2) and on knowing which model is served (The declared model is the one being served). Confidential multi-party verification (R2) can limit monitoring to a plan both parties sign ⁹.

The proof-of-guardrail prototype runs on CPU enclaves in AWS and calls its guardrail model through an external API; in the authors' tests it detected modified guardrail code, attestations and responses ⁸.

Every component that influences inference must be covered by the launch measurement ⁴. The prototype attests only the responses for which it offers attestation, so coverage of all traffic is not shown ⁸. Where hardware trust is unavailable, the sources fall back on inspections, audits and personnel-based layers ^{2 3 1}.

Training limits can so far be checked only far below frontier scale. The two proof-based mechanisms, both demonstrated (R2), have results on models of at most 1 billion parameters, and hardware enforcement is proposed (R1).

Proof-of-learning and transcript verification (R2) re-runs sampled training segments between logged weight snapshots ¹. Zero-knowledge proofs of training (R2) prove that training followed a committed specification without revealing data or weights ¹³. Guarantee processors such as flexHEG and licensing (both R1) could enforce compute limits in hardware ^{10 11}.

Choi and colleagues report proof-of-training-data experiments on language models of up to 1 billion parameters ¹². Kaizen proves training iterations of a 10-million-parameter image model, at about 15 minutes of proving per iteration ¹³.

Published attacks spoof the original proof-of-learning protocol, and the attack's authors argue that a provably robust version needs a better understanding of deep-learning optimisation ⁸. Governance analyses have judged zero-knowledge proofs impractical at frontier scale; one 2026 proposal argues this is a limit of current approaches, not a fundamental one ⁷. A compute limit bounds a run only if all the chips used are known, so this claim depends on Compute stock is at most a declared amount and There is no undeclared relevant compute.

No bandwidth cap that a verifier can check has been built, and the mechanisms aimed at this claim are proposed (R1). Bounds appeal because they constrain a facility without access to its code ¹.

Bandwidth limits and compartmentalization (R1) cap or remove the links between groups of accelerators, leaving enough for inference but not for training ¹. Hardware versions include RAND's fixed-set design ⁴ and guarantee processors (R1), and the AI 2040 stack (R1) removes back-end networking ¹⁰. Side-channel suppression (R1) addresses paths outside the network ⁷. Tamper evidence (R2) would protect the enforcing devices, and bounding unexplained information (R2) limits what the permitted bandwidth can carry.

Lucid Computing's pod-cap design is "not yet implemented or red-teamed" ¹¹. Amodo has run rate limiting on 400G links, but for weight security with a cooperating operator ¹².

Copper scale-up links and encrypted interconnects are hard to observe ⁶. The designs aim to cut side channels to low rates, not to eliminate them ^{5 7}. Sastry and colleagues note that decentralised training, if it becomes more viable, might undermine the detectability of training runs ². Training methods that need less communication could likewise erode a bound that separates training from inference today.

Only the network channel has a demonstrated (R2) bound, and only for inference outputs. Physical side channels rely on proposed (R1) designs, and insiders and physical media on facility security.

Bounding unexplained information (R2) measures how much of a facility's output the declared computation cannot explain. Sampled recomputation (R2) supplies the reference, deterministic inference (R2) would remove the tolerance that hidden data can exploit ¹⁰, and network taps (R1) record the traffic. Caps on external bandwidth (Communication between compute groups is bounded) bound the total that can leave ⁹. Side-channel suppression (R1) targets physical leakage ⁶, and RAND's secure inference data centre (R1) is designed to protect weights against state-backed attackers ¹¹.

Checking inference outputs cut the information an attacker could hide to under 0.5% on a 30-billion-parameter model, at a false-positive rate below 0.01% ². In an independent study, an attacker who controlled the prompts roughly doubled the leak per token ³.

People and physical media are left to facility security ¹ and personnel measures such as whistleblowing ⁷. RAND's design does not describe how an outside party would verify it ¹¹. The designs aim for a stated bound on leakage, not an absolute guarantee ⁵.

This broadest of negative claims cannot rest on one method, since no single verification method is foolproof ⁵. The two mechanisms built primarily for it, remote detection of data centres and proofs of useful work, are proposed (R1), as are the chip registries and location checks that support it. RAND splits the claim into undeclared use of declared clusters, which reduces to claims such as Declared hardware is idle or shut down and This compute runs inference, not training, and undeclared clusters ¹.

One strategy makes the declared stock complete from the start, through chip registries and location verification. Scher and Thiergart favour this strategy ⁴. The other searches for what was missed, through remote detection of data centres and other national technical means ⁵. Proofs of useful work would leave declared hardware little spare capacity, but cannot find a facility that was never declared ¹⁰.

Satellite imagery, permits and utility filings already track the construction of known large facilities, but automated data-centre detection remains primarily conceptual ⁹.

Chips sold before tracking began may not be locatable ³, and facilities can be hidden underground or camouflaged ⁵. It is unclear how small undeclared compute can be and still matter ^{1 7}. Draft agreements therefore pair technical measures with intelligence, challenge inspections and whistleblowers ⁶.