# 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-08. Interactive version: https://trustbutveri.fyi/explorer/?mechanisms=M-0022,M-0018&implementations=M-0022:I-0012

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 readiness and open flaws. Readiness levels R0 to R4 describe one record's public evidence for its assessed use and are never combined. Definitions: https://trustbutveri.fyi/about/methodology/ (roles, properties and flaws) and https://trustbutveri.fyi/about/readiness/ (readiness levels).

## Filters

Filters apply to mechanisms only and describe the setting the proposal is for.

None set. Every mechanism on the map was available.

## Overview

One row per mechanism, read from its record. Open flaws: critical / significant / minor. The last three columns are the editors' reading of what the verifier sees.

| Mechanism | Readiness | Prover | Attack testing | Hardware | Open flaws | Weights | Inputs and outputs | Training data |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Side-channel suppression for isolated facilities / Low-trust AI compute verification system overview | R1 | Adversarial | Analysis | Retrofit device | 0 / 2 / 1 | unspecified | unspecified | unspecified |
| Chip location verification | R1 | Adversarial | Analysis | Existing features | 0 / 4 / 0 | not involved | not involved | not involved |

## Claims

No claims chosen.

## Mechanisms

### Side-channel suppression for isolated facilities

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. ([Side-channel suppression for isolated facilities](https://trustbutveri.fyi/mechanisms/side-channel-suppression/))

- Assessment: selected implementation [Low-trust AI compute verification system overview](https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/).
- Readiness: R1 Proposed, assessed for screening challenged records to show declared inference compute is not training.
- Claims in this proposal: none of them.
- Threat model: adversarial prover. Hardware: retrofit device. Prover cooperation: required. Attack testing: analysis. Category: Isolation & system architectures.
- What the verifier sees: model weights unspecified; inputs and outputs unspecified; training data unspecified. This Explorer has no asset-specific exposure assessment for this implementation. Check its source and deployment assumptions.

### Chip location verification

Timing a chip's signed replies to trusted servers at known places, so that the speed of light bounds how far away the chip can be. ([Chip location verification](https://trustbutveri.fyi/mechanisms/chip-location-verification/))

- Assessment: mechanism family.
- Readiness: R1 Proposed, assessed for bounding how far a chip is from trusted landmark servers when checked.
- Claims in this proposal: none of them.
- Threat model: adversarial prover. Hardware: existing features. Prover cooperation: required. Attack testing: analysis. Category: Compute accounting & provenance.
- What the verifier sees: model weights not involved; inputs and outputs not involved; training data not involved. Times signed replies from chips; it does not handle model data.


## Properties

**Built for an adversarial prover**

- Side-channel suppression for isolated facilities
- Chip location verification

**No new hardware needed**

- Chip location verification


## Attack testing

Published attempts to break a system, including those that found failures. Testing history does not establish that open flaws are resolved.

**Testing history**

- Side-channel suppression for isolated facilities / Low-trust AI compute verification system overview: Analysis
- Chip location verification: Analysis


## Limits

**Open significant flaws**

- Mismatches cannot be attributed to cheating or error (theoretical argument, in Low-trust AI compute verification system overview; https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/#flaw-1) [1]. A failed hash or replay does not show whether it came from an evasion attempt, a random bit flip or an evaluation error. The author notes that if detected anomalies can plausibly be waved off as malfunctions, deterrence becomes less effective, so the parties need an agreed escalation procedure that ends in attribution.
- Inspector agents may be manipulable (open question, in Low-trust AI compute verification system overview; https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/#flaw-3) [1]. Automated compliance screening with LLM-based inspector agents must resist prompt-injection attacks. Adversarially trained systems might hide malicious actions with steganography, which makes backdoor detection an open problem.
- Extracting a chip's key lets another device answer for it (theoretical argument, in Chip location verification; https://trustbutveri.fyi/mechanisms/chip-location-verification/#flaw-1) [4][9]. Ping-based protocols rely on cryptographic keys stored on the chip. Tee and Happel argue that an adversary with physical access could extract these keys and so compromise location verification. They propose GPU fingerprints as a mitigation, so far tested on 24 GPUs. Brass and Aarne assume the keys are stored securely, for example in a TPM.
- Added delay can shift an estimated position (demonstrated attack, in Chip location verification; https://trustbutveri.fyi/mechanisms/chip-location-verification/#flaw-2) [4][7]. Brass and Aarne cite internet-geolocation research in which artificially increased round-trip times moved the estimated location by up to 1,000 km, with a 74% chance of avoiding detection. Avellar and Grunewald list inflated ping times from circuitous routing as an evasion route. Added delay only loosens a distance bound, and Brass and Aarne propose a hard time limit as the counter: a chip that replies too slowly cannot be ruled out of a restricted location.
- Faster-than-assumed network paths (theoretical argument, in Chip location verification; https://trustbutveri.fyi/mechanisms/chip-location-verification/#flaw-3) [4][7]. Brass and Aarne list dark fibre and other private high-speed interconnects as ways to lower measured delays artificially. They judge that leasing dark fibre would probably not be a considerable challenge for covertly or openly adversarial actors. Avellar and Grunewald note that this can make a chip appear to be somewhere else entirely. A limit set at the vacuum speed of light cannot be beaten, but it makes honest chips fail more often.
- Compromised landmarks can falsify measurements (theoretical argument, in Chip location verification; https://trustbutveri.fyi/mechanisms/chip-location-verification/#flaw-4) [4][7][8]. A party that controls landmark servers can report false timing. Brass and Aarne cite research in which manipulating a third of the landmarks shifted the estimated location by about 700 km. Avellar and Grunewald note that compromised landmarks let adversaries spoof travel-time measurements directly. The draft specification asks verifiers to require anchors in diverse places, run by several independent operators.

**Family finding context**

- Context for Low-trust AI compute verification system overview; applicability depends on the finding's scope. Supply-chain implants may evade inspection (theoretical argument, in Side-channel suppression for isolated facilities; https://trustbutveri.fyi/mechanisms/side-channel-suppression/#flaw-1) [3]. Cankaya identifies malicious hardware embedded deep in purchased components as a residual risk that visual inspection and disassembly may not catch. He notes that radiographic examination under high-security standards could mitigate it.
- Context for Low-trust AI compute verification system overview; applicability depends on the finding's scope. Openings for airflow, power and optics weaken shielding (theoretical argument, in Side-channel suppression for isolated facilities; https://trustbutveri.fyi/mechanisms/side-channel-suppression/#flaw-2) [3]. Cankaya notes that keeping attenuation high while passing high-power airflow, cabling and optical links adds complexity beyond existing shielded-enclosure specifications.
- Context for Low-trust AI compute verification system overview; applicability depends on the finding's scope. Inspection assumptions may not hold (open question, in Side-channel suppression for isolated facilities; https://trustbutveri.fyi/mechanisms/side-channel-suppression/#flaw-3) [3]. The design's statistical argument assumes that visual or disassembly inspection catches every flaw that is present in a sampled unit. Cankaya is unsure whether destructive teardowns are defence-dominant or offence-dominant.

**Open minor flaws**

- Deliberate faults leak a bit each (theoretical argument, in Low-trust AI compute verification system overview; https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/#flaw-2) [1]. A malicious device can leak one bit by deliberately outputting a wrong result, which blocks a disclosure when the cross-comparison fails. The design therefore needs a pre-agreed budget of tolerated faults.

**Not yet demonstrated**

- Side-channel suppression for isolated facilities: R1 Proposed, assessed for screening challenged records to show declared inference compute is not training
- Chip location verification: R1 Proposed, assessed for bounding how far a chip is from trusted landmark servers when checked


## Possible additions

Mechanisms on the map, not in the proposal, that the records connect to an unaddressed or partly addressed claim, an open flaw or a dependency. Pointers, not recommendations: each brings its own readiness level and flaws, and none is claimed to close a flaw.

- **Deterministic and bit-exact inference** (R3 In production, assessed for reproducing open-model inference from receipts in Gensyn's information-market service)
  - Side-channel suppression for isolated facilities waits on it: Exact replay needs complete hardware and software metadata, and the tolerable slowdown from emulation is an open question.
- **Tamper evidence for verifier devices** (R2 Demonstrated, assessed for detecting probing of proposed verifier hardware, using server and electronics prototypes as evidence)
  - Side-channel suppression for isolated facilities waits on it: Tamper-evident, rapidly mass-manufacturable and retrofittable enclosures for side-channel defence are an open research question, and physical security against covert communication in every monitored data centre is challenging.
- **Timed challenge-response and memory-occupation challenges** (R2 Demonstrated, assessed for detecting whether a GPU is doing other work)
  - Side-channel suppression for isolated facilities waits on it: Distinguishing one server's DRAM contents from another's by challenge-response timing, and a general challenge-response protocol for diverse data types, are open.
- **Network taps and certifiers** (R1 Proposed, assessed for committing a complete record of cluster traffic, so declared inference can be checked)
  - Side-channel suppression for isolated facilities waits on it: Empirical feasibility of passive optical splitting at 53–112 GBaud under realistic conditions is an open question.
- **TEE remote attestation for AI workloads** (R3 In production, assessed for showing which software ran to a party that distrusts the operator holding the hardware)
  - Chip location verification depends on it.


## Dependencies

**Missing prerequisites**

- Network taps and certifiers (R1 Proposed, assessed for committing a complete record of cluster traffic, so declared inference can be checked), needed by Side-channel suppression for isolated facilities
- Deterministic and bit-exact inference (R3 In production, assessed for reproducing open-model inference from receipts in Gensyn's information-market service), needed by Side-channel suppression for isolated facilities
- TEE remote attestation for AI workloads (R3 In production, assessed for showing which software ran to a party that distrusts the operator holding the hardware), needed by Chip location verification

**Blockers**

- Side-channel suppression for isolated facilities: Empirical feasibility of passive optical splitting at 53–112 GBaud under realistic conditions is an open question. (performance & compatibility; waits on Network taps and certifiers) [1]
- Side-channel suppression for isolated facilities: Exact replay needs complete hardware and software metadata, and the tolerable slowdown from emulation is an open question. (performance & compatibility; waits on Deterministic and bit-exact inference) [1]
- Side-channel suppression for isolated facilities: Tamper-evident, rapidly mass-manufacturable and retrofittable enclosures for side-channel defence are an open research question, and physical security against covert communication in every monitored data centre is challenging. (hardware trust; waits on Tamper evidence for verifier devices) [1]
- Side-channel suppression for isolated facilities: A mass-manufacturable, good-enough side-channel defence, particularly power-line filtering, has not been constructed or red-teamed. (coverage & hidden compute; waits on Side-channel suppression for isolated facilities) [1]
- Side-channel suppression for isolated facilities: Distinguishing one server's DRAM contents from another's by challenge-response timing, and a general challenge-response protocol for diverse data types, are open. (coverage & hidden compute; waits on Timed challenge-response and memory-occupation challenges) [1]
- Side-channel suppression for isolated facilities: The threat model is under-developed and needs input from cybersecurity and AI threat-modelling experts. (adversarial validation) [1]
- Chip location verification: No public code or reproducible end-to-end location results are available for the reported H100 prototype. (adversarial validation) [5][6]
- Chip location verification: Per-chip keys must be provisioned and protected against extraction; hardware-integrated, tamper-resistant versions still need R&D. (hardware trust) [4][9][11]
- Chip location verification: The time limit forces a trade-off: a limit at the speed of light in fibre can be beaten by faster links, while one at the vacuum speed of light makes honest chips fail often. (protocol soundness) [4]
- Chip location verification: A trusted landmark network must be built and secured, and who should operate it, under what oversight, is unsettled. (access & governance) [4][7]


## What the verifier sees

- Model weights: shown by none; depends on the design for none; hidden by none; not involved in Chip location verification; unspecified for Side-channel suppression for isolated facilities.
- Inputs and outputs: shown by none; depends on the design for none; hidden by none; not involved in Chip location verification; unspecified for Side-channel suppression for isolated facilities.
- Training data: shown by none; depends on the design for none; hidden by none; not involved in Chip location verification; unspecified for Side-channel suppression for isolated facilities.

## Implementations

- Side-channel suppression for isolated facilities: [AI 2040 inference-only verification stack](https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/) (R1, proposed architecture); [Low-trust AI compute verification system overview](https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/) (R1, proposed architecture); [RAND secure inference data center (SIDC) design](https://trustbutveri.fyi/implementations/rand-secure-inference-data-centers/) (R1, proposed architecture)
- Chip location verification: [Lucid sovereignty (location) certificates](https://trustbutveri.fyi/implementations/lucid-location-certificates/) (R1, standard)

## Sources

1. 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
2. Fingerprinting All AI Cluster I/O Without Mutually Trusted Processors, N. Cankaya et al. (2026). https://arxiv.org/abs/2606.10724
3. Suppressing Side Channels in an Untrusted Data Center via Retrofitted Defenses, N. Cankaya (2026). https://techgov.intelligence.org/blog/suppressing-side-channels-in-an-untrusted-data-center-via-retrofitted-defenses
4. Location Verification for AI Chips, A. Brass & O. Aarne (2024). https://www.iaps.ai/research/location-verification-for-ai-chips
5. Location Verification for AI Chips (issue brief), A. Brass (2025). https://static1.squarespace.com/static/64edf8e7f2b10d716b5ba0e1/t/6827b67275666f3757f134ea/1747433075281/Location+Verification+two-pager.pdf
6. Ping-based Location, Ulyssean (2025). https://ping-location.info/
7. Near-Term Verification Methods for AI Chip Exports, B. Avellar & E. Grunewald (2026). https://www.iaps.ai/research/near-term-verification-methods-for-ai-chip-exports
8. Sovereignty Certificates: draft specification, version 0.1.0, Sovereignty Certificates Working Group (2025). https://github.com/Lucid-Computing/sovereignty-certificate-specification
9. GPU Fingerprinting for Location Verification, W. Tee & J. Happel (2026). https://arxiv.org/abs/2605.01930
10. Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing, O. Aarne et al. (2024). https://www.cnas.org/publications/reports/secure-governable-chips
11. Hardware-Level Governance of AI Compute: A Feasibility Taxonomy for Regulatory Compliance and Treaty Verification, S. Ansari (2026). https://arxiv.org/abs/2604.04712