# AI verification proposal A proposal built with the Proposal Explorer of the AI Verification Tech Map (https://trustbutveri.fyi/), from its records of 2026-10-09. Interactive version: https://trustbutveri.fyi/explorer/?mechanisms=M-0017,M-0007,M-0020&chips=existing How to read it: a claim is something one party wants to verify about another's AI hardware or software. A mechanism is a general technique for verifying claims; it is "aimed at" a claim when that is its direct purpose, and "supporting" when it contributes without being aimed at it. A claim is addressed when a mechanism in the proposal is aimed at it and is not excluded by the filters; addressed does not mean verified, so check that mechanism's development status, security evidence and findings. Definitions: https://trustbutveri.fyi/about/methodology/ (roles, properties and findings) and https://trustbutveri.fyi/about/readiness/ (development status). ## Filters Filters apply to mechanisms only and describe the setting the proposal is for. - **Chips: Existing chips only.** "Existing chips only" removes mechanisms that need changes to future chip designs. New chip features take years to reach a deployed fleet and cover only chips made after they ship. Mechanisms that use shipping features, such as trusted execution environments or performance counters, stay. 23 of 25 mechanisms on the map pass these filters. ## Overview One row per mechanism, read from its record. Open failures: critical / significant / minor. The last three columns are the editors' reading of what the verifier sees. Findings are grouped as known failures, scope limitations and open questions. Only known failures count as failures. Counts are an inventory of published findings, not a risk score. | Mechanism | Development | Security evidence | Prover | Attack testing | Hardware | Open failures | Weights | Inputs and outputs | Training data | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Tamper evidence for verifier devices | Research demonstration | Published security analysis | Adversarial | Analysis | Retrofit device | 0 / 2 / 0 | not involved | not involved | not involved | | Proofs of useful work for capacity accounting | Proposed | Published security analysis | Adversarial | Analysis | None | 0 / 1 / 0 | depends | depends | not involved | | Remote detection of data centres | Proposed | Published security analysis | Adversarial | Analysis | None | 0 / 0 / 0 | not involved | not involved | not involved | ## Claims No claims chosen. ## Mechanisms ### Tamper evidence for verifier devices Enclosures, seals and sensors that make physical interference with verification hardware visible, or that destroy the hardware's secrets when tampering occurs. ([Tamper evidence for verifier devices](https://trustbutveri.fyi/mechanisms/tamper-evidence-for-verifier-devices/)) - Assessment: mechanism family. - Development: Research demonstration (legacy code R2), assessed for detecting probing of proposed verifier hardware, using server and electronics prototypes as evidence. - Security evidence: Published security analysis. Independent evaluation: unassessed. Formal proof: unassessed. Deployment assurance: unassessed. - Claims in this proposal: none of them. - Threat model: adversarial prover. Hardware: retrofit device. Prover cooperation: partial. Attack testing: analysis. Category: Off-chip devices & sensors. - What the verifier sees: model weights not involved; inputs and outputs not involved; training data not involved. Protects verifier devices; it does not handle model data. ### Proofs of useful work for capacity accounting Cryptographic evidence that a given amount of matrix-multiplication work was completed, proposed as one input to bounding how much spare capacity declared hardware has. ([Proofs of useful work for capacity accounting](https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/)) - Assessment: mechanism family. - Development: Proposed (legacy code R1), assessed for bounding the spare capacity of declared hardware that could run training. - Security evidence: Published security analysis. Independent evaluation: unassessed. Formal proof: unassessed. Deployment assurance: unassessed. - Claims in this proposal: none of them. - Threat model: adversarial prover. Hardware: none. Prover cooperation: required. Attack testing: analysis. Category: Cryptographic & computational. - What the verifier sees: model weights depends; inputs and outputs depends; training data not involved. Checking a sampled tile of a matrix multiplication reveals that tile, which may hold model or input data; the authors suggest a zero-knowledge proof when the matrices must stay private. ### Remote detection of data centres Remote detection locates large data centres and estimates their power capacity without site access, using satellite imagery, heat signatures and public records such as permits. ([Remote detection of data centres](https://trustbutveri.fyi/mechanisms/remote-detection-of-data-centres/)) - Assessment: mechanism family. - Development: Proposed (legacy code R1), assessed for finding undeclared data centres above an agreed compute threshold. - Security evidence: Published security analysis. Independent evaluation: unassessed. Formal proof: unassessed. Deployment assurance: unassessed. - Claims in this proposal: none of them. - Threat model: adversarial prover. Hardware: none. Prover cooperation: not required. Attack testing: analysis. Category: Remote & side-channel sensing. - What the verifier sees: model weights not involved; inputs and outputs not involved; training data not involved. Works from outside the facility; it does not handle model data. ## Properties **Built for an adversarial prover** - Tamper evidence for verifier devices - Proofs of useful work for capacity accounting - Remote detection of data centres **No new hardware needed** - Proofs of useful work for capacity accounting - Remote detection of data centres ## Attack testing Attack testing records published testing for this use. It does not by itself show independent review, a formal proof or that a deployed system is secure. **Testing history** - Tamper evidence for verifier devices: Analysis - Proofs of useful work for capacity accounting: Analysis - Remote detection of data centres: Analysis ## Limits **Open significant failures** - Seals are often defeated with simple methods (known failure, demonstrated attack, in Tamper evidence for verifier devices; https://trustbutveri.fyi/mechanisms/tamper-evidence-for-verifier-devices/evidence/flaws/1/) [8][9]. Mechanism-class evidence. Published defeats of general security seals. They warn about proposed verifier-device seals, but do not demonstrate defeat of an AI verification enclosure or sensor. In 1996 a Los Alamos vulnerability assessment defeated all 94 security seals it examined, with 132 defeats in total, using rapid, inexpensive, low-tech methods. It found that seal cost did not predict security. In 2001 Johnston reported that high-tech seals are often easier to defeat than low-tech ones. - Attack classes outside published models (known failure, open question, in Tamper evidence for verifier devices; https://trustbutveri.fyi/mechanisms/tamper-evidence-for-verifier-devices/evidence/flaws/3/) [1][2][10]. Mechanism-class evidence. The radio compensation result is emulated using measured channel data under a known-reference attacker model. It is not a physical bypass demonstration against an AI verifier enclosure. The authors of the batteryless cover say they cannot assess chemical-solvent attacks, which exceed their expertise, and deem cover removal impractical. Anti-Tamper Radio's reference can drift as the environment or measurement system ages; the authors suggest gradually renewing the reference. A 2025 follow-up by some of the same authors shows, by emulation on measured channel data, that an attacker who knows the reference channel and the needle's effect on it could inject a signal that cancels the change caused by a needle insertion. It proposes a reconfigurable intelligent surface that randomizes the channel as a countermeasure. - Known shortcuts let a miner claim somewhat more work than it did (known failure, theoretical argument, in Proofs of useful work for capacity accounting; https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/evidence/flaws/3/) [14]. Pearl's specification lists known mining speedups: crafted inputs, precision shortcuts, seed grinding, work reuse, and faster kernels or hardware. A policy check caps the summands a miner may skip at one-sixteenth of those in a tile. For capacity bounding, any gap between work proven and work possible leaves spare capacity. **Scope limitations** - Security depends on inspection protocols (scope limitation, theoretical argument, in Tamper evidence for verifier devices; https://trustbutveri.fyi/mechanisms/tamper-evidence-for-verifier-devices/evidence/flaws/2/) [6][9]. Mechanism-class evidence. An inspection and protocol requirement drawn from safeguards and enclosure studies, not a reported break of a deployed AI verifier. Johnston argues that a seal is no better than the protocols for using it, and that inspectors are usually given little useful information on how to detect tampering. The Sandia survey notes that larger enclosures are hard to inspect fully and that sensor data must be authenticated. - Proves that work was done, not that no capacity remains (scope limitation, theoretical argument, in Proofs of useful work for capacity accounting; https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/evidence/flaws/1/) [11]. Proof-of-work accounting bounds unmonitored compute only relative to an estimate of what the actor has. Attestable states that the verifier "needs a credible estimate of the compute available" to the actor, and that a proof "cannot discover a datacenter that was never declared". Related mechanism: Chip registries and manufacturing records (R1, not in the proposal). A registry of chips is one basis for the estimate of available compute that the flaw's source says the verifier needs. Related mechanism: Remote detection of data centres (R1, in the proposal). Looks for data centres that were never declared, which a proof cannot discover. - Facilities can be disguised or hidden (scope limitation, theoretical argument, in Remote detection of data centres; https://trustbutveri.fyi/mechanisms/remote-detection-of-data-centres/evidence/flaws/1/) [16]. Halstead and Larsen discuss two ways to hide a facility. One is to disguise it as a legitimate industrial site. The other is to build it underground, with cooling that avoids visible heat plumes. They note that the underground option requires bespoke engineering. - Small sites may not be detectable (scope limitation, theoretical argument, in Remote detection of data centres; https://trustbutveri.fyi/mechanisms/remote-detection-of-data-centres/evidence/flaws/2/) [16][18]. Halstead and Larsen conclude that a sufficiently small covert project could not be ruled out with confidence. In their estimates, the chance of detection is lower for smaller sites. Krawec notes that small data centres in existing buildings may lack the distinctive features of large facilities. Related mechanism: Chip registries and manufacturing records (R1, not in the proposal). Accounts for chips from the fab onwards, which does not depend on a site being visible. **Open questions** - Security rests on new hardness assumptions (open question, open question, in Proofs of useful work for capacity accounting; https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/evidence/flaws/2/) [13][14]. Komargodski and Weinstein base security on hardness assumptions about batches of low-rank random linear equations, and list PoUW "from more standard or well-studied assumptions" as an open problem. Pearl's floating-point variant introduces a further "quantized-subspace hardness" assumption. - Search for unknown sites is undemonstrated (open question, open question, in Remote detection of data centres; https://trustbutveri.fyi/mechanisms/remote-detection-of-data-centres/evidence/flaws/3/) [18]. Krawec reports that telling data centres apart from other industrial facilities systematically is difficult. Automating detection would need large amounts of training imagery and a purpose-trained model. In Krawec's words, automated data-centre detection "remains primarily conceptual at present". **Not yet demonstrated** - Proofs of useful work for capacity accounting: Proposed (legacy code R1), assessed for bounding the spare capacity of declared hardware that could run training - Remote detection of data centres: Proposed (legacy code R1), assessed for finding undeclared data centres above an agreed compute threshold ## Possible additions Mechanisms on the map, not in the proposal, that the records connect to an unaddressed or partly addressed claim, an open failure or a dependency. Pointers, not recommendations: each brings its own readiness level and findings, and none is claimed to close a failure. None found. ## Dependencies **Blockers** - Tamper evidence for verifier devices: No tamper-evident enclosure has been designed for AI verifier hardware at retrofit scale. (hardware trust) [7] - Tamper evidence for verifier devices: Battery-backed designs add bulk, limit operating temperature (+10 °C to +35 °C for the IBM 4765) and complicate transport. (performance & compatibility) [2] - Tamper evidence for verifier devices: Active monitoring needs power, and visual inspection of large enclosures faces access limits. (access & governance) [6] - Tamper evidence for verifier devices: No evaluation has been published in the AI verification setting. (adversarial validation) [7] - Proofs of useful work for capacity accounting: Bounding spare capacity needs a credible estimate of the compute available to the actor, including third-party access. (capacity bounds) [11] - Proofs of useful work for capacity accounting: Proofs of work cannot find facilities that were never declared. (coverage & hidden compute) [11] - Proofs of useful work for capacity accounting: As of September 2026 no implementation, demonstration or independent evaluation of proofs of work for capacity bounding has been published. (adversarial validation) - Remote detection of data centres: Wide-area, automated detection of data centres is not yet practical and needs large training datasets. (coverage & hidden compute) [18] - Remote detection of data centres: No measured detection or false-alarm rates for finding undeclared facilities have been published. (adversarial validation) [16][18] - Remote detection of data centres: Recent high-resolution imagery is costly, is limited by weather and needs trained analysts. (access & governance) [18] ## What the verifier sees - Model weights: shown by none; depends on the design for Proofs of useful work for capacity accounting; hidden by none; not involved in Tamper evidence for verifier devices and Remote detection of data centres; unspecified for none. - Inputs and outputs: shown by none; depends on the design for Proofs of useful work for capacity accounting; hidden by none; not involved in Tamper evidence for verifier devices and Remote detection of data centres; unspecified for none. - Training data: shown by none; depends on the design for none; hidden by none; not involved in Tamper evidence for verifier devices, Proofs of useful work for capacity accounting and Remote detection of data centres; unspecified for none. ## Implementations - Tamper evidence for verifier devices: [AI 2040 inference-only verification stack](https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/) (R1, proposed architecture) - Proofs of useful work for capacity accounting: [Pearl proof-of-useful-work blockchain](https://trustbutveri.fyi/implementations/pearl-proof-of-useful-work/) (R3, open-source project) - Remote detection of data centres: none on the map ## Sources 1. Anti-Tamper Radio: System-Level Tamper Detection for Computing Systems, P. Staat et al. (2022). https://ieeexplore.ieee.org/document/9833631/ 2. Secure Physical Enclosures from Covers with Tamper-Resistance, V. Immler et al. (2019). https://tches.iacr.org/index.php/TCHES/article/view/7334 3. ImpedanceVerif: On-Chip Impedance Sensing for System-Level Tampering Detection, T. Mosavirik et al. (2023). https://eprint.iacr.org/2022/946 4. IBM 4765 Cryptographic Coprocessor Security Module: Security Policy, IBM Corporation (2012). https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp1505.pdf 5. PHYSEC SEAL: Change detection for maximum safety, PHYSEC GmbH (2026). https://www.physec.de/en/solutions/physec-seal/ 6. Tamper-Indicating Enclosures, A Current Survey, H. A. Smartt & Z. N. Gastelum (2015). https://www.osti.gov/servlets/purl/1256541 7. A System Overview for Near-Term, Low-Trust AI Compute Verification, N. Cankaya (2026). https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf 8. Physical Security and Tamper-Indicating Devices, R. G. Johnston & A. R. E. Garcia (1996). https://www.osti.gov/servlets/purl/459707 9. Tamper Detection for Safeguards and Treaty Monitoring: Fantasies, Realities, and Potentials, R. G. Johnston (2001). https://www.nonproliferation.org/wp-content/uploads/npr/81john.pdf 10. Anti-Tamper Radio Meets Reconfigurable Intelligent Surface for System-Level Tamper Detection, M. S. Tabar et al. (2025). https://arxiv.org/abs/2503.14279 11. Pacing AI Requires Proof, Attestable (2026). https://attestable.com/blog/pacing-ai-requires-proof 12. Mechanisms to Verify International Agreements About AI Development, A. Scher & L. Thiergart (2025). https://arxiv.org/abs/2506.15867 13. Proofs of Useful Work from Arbitrary Matrix Multiplication, I. Komargodski & O. Weinstein (2025). https://arxiv.org/abs/2504.09971 14. Pearl Floating Point Scheme Specification, Pearl Research Team (2026). https://pearlresearch.ai/Pearl_Whitepaper.pdf 15. pearl: Monorepo for the Pearl network, Pearl Research Labs (2026). https://github.com/pearl-research-labs/pearl 16. Covert AI Projects, B. Halstead & T. Larsen (2026). https://ai-2040.com/supplements/covert-ai-projects 17. Verifying International Agreements on AI: Six Layers of Verification for Rules on Large-Scale AI Development and Deployment, M. Baker et al. (2025). https://www.rand.org/pubs/working_papers/WRA4077-1.html 18. Tracking Hyperscale AI Data Center Growth with Satellite Imagery, C. Krawec (2026). https://fas.org/publication/tracking-hyperscale/ 19. Introducing the Frontier Data Centers Hub, Epoch AI (2025). https://epoch.ai/latest/introducing-the-frontier-data-centers-hub 20. AI Data Centers Documentation – Methodology, Epoch AI (2026). https://epoch.ai/data/data-centers-documentation/methodology