# 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-0014,M-0022,M-0016&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 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.

- **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 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 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Bandwidth limits and compartmentalization | R2 | Adversarial | Analysis | Retrofit device | 0 / 5 / 0 | not involved | not involved | not involved |
| Side-channel suppression for isolated facilities | R1 | Adversarial | Analysis | Retrofit device | 0 / 3 / 0 | not involved | not involved | not involved |
| Timed challenge-response and memory-occupation challenges | R2 | Adversarial | Analysis | None | 0 / 1 / 1 | not involved | not involved | not involved |

## Claims

No claims chosen.

## Mechanisms

### Bandwidth limits and compartmentalization

Capping or removing network links between groups of accelerators, so that serving within each group still works but large training across groups becomes far slower. ([Bandwidth limits and compartmentalization](https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/))

- Assessment: mechanism family.
- Readiness: R2 Demonstrated, assessed for monitoring inter-node traffic with operator-run software on four GPUs.
- 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 not involved; inputs and outputs not involved; training data not involved. Caps traffic between groups of chips; it does not read the traffic's content.

### Side-channel suppression for isolated facilities

Shielding, filtering, jamming and inspecting an AI facility to limit hidden physical communication around monitored network links. ([Side-channel suppression for isolated facilities](https://trustbutveri.fyi/mechanisms/side-channel-suppression/))

- Assessment: mechanism family.
- Readiness: R1 Proposed, assessed for bounding physical covert channels out of a verified enclosure.
- 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. Shields and filters a facility; it does not handle model data.

### Timed challenge-response and memory-occupation challenges

A verifier sends unpredictable questions that a device can answer in time only if it holds specified data, or dedicates specified resources, locally. ([Timed challenge-response and memory-occupation challenges](https://trustbutveri.fyi/mechanisms/timed-challenge-response/))

- Assessment: mechanism family.
- Readiness: R2 Demonstrated, assessed for detecting whether a GPU is doing other work.
- 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 not involved; inputs and outputs not involved; training data not involved. Uses verifier-chosen challenges; it does not handle model data.


## Properties

**Built for an adversarial prover**

- Bandwidth limits and compartmentalization
- Side-channel suppression for isolated facilities
- Timed challenge-response and memory-occupation challenges

**No new hardware needed**

- Timed challenge-response and memory-occupation challenges


## 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**

- Bandwidth limits and compartmentalization: Analysis
- Side-channel suppression for isolated facilities: Analysis
- Timed challenge-response and memory-occupation challenges: Analysis


## Limits

**Open significant flaws**

- Low-communication training reduces the bandwidth training needs (theoretical argument, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/#flaw-1) [2][6][7]. DiLoCo matched fully synchronous training on 8 workers while communicating 500 times less. Rahman writes that this family of methods theoretically allows large-scale training with less than 100 Mbps. Lucid includes these methods in its bounds, but notes that extreme activation compression, architectures with unusually small inter-layer widths, or modular paradigms could erode the margin.
- Operator control of pod routing collapses the bound (theoretical argument, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/#flaw-2) [2]. Lucid's analysis finds that if the operator can freely assign pods to routers, it could dedicate a whole cell of 100 or more pods to one pipeline stage. The bound then falls to about 90–220x uncompressed and as low as about 25x with compression. The proposed mitigation, auditor-controlled random assignment that is periodically re-randomized, has not been implemented.
- Undeclared local storage raises per-pod capacity (theoretical argument, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/#flaw-3) [2]. More memory or storage per pod helps an adversary. Lucid requires per-pod storage to be declared, capped and physically inspected.
- Training within one pod is not covered (open question, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/#flaw-4) [2]. Lucid's bounds concern pre-training models larger than the pods are sized for. Training models that fit in one pod, fine-tuning and reinforcement-learning post-training within one pod are outside the modelled threat.
- Parallel scale-up switches are hard enforcement points (theoretical argument, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/#flaw-5) [5]. In GB200 topologies, GPUs reach GPUs in other nodes through NVSwitches without a NIC on the path. Amodo notes that limits are hard to enforce there because many switches work in parallel, so compromising one or two would bypass the limit.
- Supply-chain implants may evade inspection (theoretical argument, in Side-channel suppression for isolated facilities; https://trustbutveri.fyi/mechanisms/side-channel-suppression/#flaw-1) [8]. 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.
- 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) [8]. Cankaya notes that keeping attenuation high while passing high-power airflow, cabling and optical links adds complexity beyond existing shielded-enclosure specifications.
- Inspection assumptions may not hold (open question, in Side-channel suppression for isolated facilities; https://trustbutveri.fyi/mechanisms/side-channel-suppression/#flaw-3) [8]. 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.
- Remote memory narrows the timing margin (theoretical argument, in Timed challenge-response and memory-occupation challenges; https://trustbutveri.fyi/mechanisms/timed-challenge-response/#flaw-2) [3]. Data-centre remote memory access returns in about 1–2 µs, against about 70–200 ns for local DRAM. The MIRI overview says verification of memory saturation depends on ruling out remote access by latency or physical disconnection. It adds that pre-staging data is ruled out only by unpredictable, capacity-filling challenges.

  Related mechanism: Bandwidth limits and compartmentalization (R2, in the proposal). Physical disconnection is proposed to exclude remote memory between the separated groups during a challenge. It depends on the isolation boundary being enforced.

**Open minor flaws**

- Error rates not quantified (open question, in Timed challenge-response and memory-occupation challenges; https://trustbutveri.fyi/mechanisms/timed-challenge-response/#flaw-3) [9]. Monfared et al. show separable timing distributions but do not define thresholds or statistical tests, so false-positive and false-negative rates are not quantified.

**Not yet demonstrated**

- Side-channel suppression for isolated facilities: R1 Proposed, assessed for bounding physical covert channels out of a verified enclosure


## 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.

- **Tamper evidence for verifier devices** (R2 Demonstrated, assessed for detecting probing of proposed verifier hardware, using server and electronics prototypes as evidence)
  - Bandwidth limits and compartmentalization waits on it: Shaping devices and routing assignments must be trusted by both parties; Amodo has not yet fully analysed resilience to a compromised DPU.
- **Network taps and certifiers** (R1 Proposed, assessed for committing a complete record of cluster traffic, so declared inference can be checked)
  - Bandwidth limits and compartmentalization waits on it: The verifier must know that all traffic leaving a pod crosses the capped, monitored links.


## Dependencies

**Missing prerequisites**

- Tamper evidence for verifier devices (R2 Demonstrated, assessed for detecting probing of proposed verifier hardware, using server and electronics prototypes as evidence), needed by Bandwidth limits and compartmentalization

**Blockers**

- Bandwidth limits and compartmentalization: No cap that a verifier can check has been implemented or red-teamed. (adversarial validation) [2]
- Bandwidth limits and compartmentalization: The verifier must know that all traffic leaving a pod crosses the capped, monitored links. (coverage & hidden compute; waits on Network taps and certifiers) [3]
- Bandwidth limits and compartmentalization: Shaping devices and routing assignments must be trusted by both parties; Amodo has not yet fully analysed resilience to a compromised DPU. (hardware trust; waits on Tamper evidence for verifier devices) [2][5]
- Bandwidth limits and compartmentalization: Advances in low-communication training could shrink the margin that the cap enforces. (capacity bounds) [2][6][7]
- Side-channel suppression for isolated facilities: No prototype or red-team exists; the design is a first-pass viability study. (adversarial validation) [8]
- Side-channel suppression for isolated facilities: Volume costs of TEMPEST-grade power-line filters are uncertain, because existing products are mostly made to order. (performance & compatibility) [8]
- Timed challenge-response and memory-occupation challenges: No network-level memory challenge across data-centre servers has been demonstrated. (adversarial validation) [3]
- Timed challenge-response and memory-occupation challenges: Challenges that fill memory displace workloads; filling a pod's volatile memory takes tens of minutes and SSDs take hours. (performance & compatibility) [3][9]
- Timed challenge-response and memory-occupation challenges: Outside help, such as remote memory, must be excluded during challenges. (coverage & hidden compute; waits on Bandwidth limits and compartmentalization) [3]


## What the verifier sees

- Model weights: shown by none; depends on the design for none; hidden by none; not involved in Bandwidth limits and compartmentalization, Side-channel suppression for isolated facilities and Timed challenge-response and memory-occupation challenges; unspecified for none.
- Inputs and outputs: shown by none; depends on the design for none; hidden by none; not involved in Bandwidth limits and compartmentalization, Side-channel suppression for isolated facilities and Timed challenge-response and memory-occupation challenges; unspecified for none.
- Training data: shown by none; depends on the design for none; hidden by none; not involved in Bandwidth limits and compartmentalization, Side-channel suppression for isolated facilities and Timed challenge-response and memory-occupation challenges; unspecified for none.

## Implementations

- Bandwidth limits and compartmentalization: [AI 2040 inference-only verification stack](https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/) (R1, proposed architecture); [RAND secure inference data center (SIDC) design](https://trustbutveri.fyi/implementations/rand-secure-inference-data-centers/) (R1, proposed architecture)
- 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)
- Timed challenge-response and memory-occupation challenges: [Data-centre memory challenging](https://trustbutveri.fyi/implementations/data-centre-memory-challenging/) (R1, proposed architecture); [GPU contention probes](https://trustbutveri.fyi/implementations/gpu-contention-probes/) (R2, research prototype); [Low-trust AI compute verification system overview](https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/) (R1, proposed architecture); [SAGE](https://trustbutveri.fyi/implementations/sage-gpu-attestation/) (R2, research prototype); [VRAM-residency challenge](https://trustbutveri.fyi/implementations/vram-residency-challenge/) (R2, research prototype)

## Sources

1. Verification Plan, R. Dean (2026). https://ai-2040.com/supplements/verification-plan
2. Traffic Shaping for Workload Classification, Lucid Computing (2026). https://lucidcomputing.substack.com/p/traffic-shaping-for-workload-classification
3. 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
4. De-risking Interconnect Limits for AI Verification, A. Scher et al. (2026). https://techgov.intelligence.org/blog/de-risking-interconnect-limits-for-ai-verification
5. The Tray as a Bandwidth Boundary, Amodo Design (2026). https://amododesign.com/notes/2026-03-16-dpu-bandwidth-limiter/
6. DiLoCo: Distributed Low-Communication Training of Language Models, A. Douillard et al. (2024). https://arxiv.org/abs/2311.08105
7. Does Distributed Training Undermine Compute Governance?, R. Rahman (2026). https://arxiv.org/abs/2605.29359
8. 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
9. Timing and Memory Telemetry on GPUs for AI Governance, S. K. Monfared et al. (2026). https://arxiv.org/abs/2602.09369
10. SAGE: Software-based Attestation for GPU Execution, A. Ivanov et al. (2023). https://www.usenix.org/conference/atc23/presentation/ivanov
11. SWATT: SoftWare-based ATTestation for Embedded Devices, A. Seshadri et al. (2004). https://netsec.ethz.ch/publications/papers/swatt.pdf
12. Proofs of Space, S. Dziembowski et al. (2015). https://eprint.iacr.org/2013/796
13. Secure Code Update for Embedded Devices via Proofs of Secure Erasure, D. Perito & G. Tsudik (2010). https://link.springer.com/chapter/10.1007/978-3-642-15497-3_39
14. Software-Based Memory Erasure with Relaxed Isolation Requirements, S. Bursuc et al. (2024). https://ieeexplore.ieee.org/document/10664348/
15. On the Difficulty of Software-Based Attestation of Embedded Devices, C. Castelluccia et al. (2009). https://s3.eurecom.fr/docs/ccs09_Castelluccia.pdf
16. Refutation of "On the Difficulty of Software-Based Attestation of Embedded Devices", A. Perrig & L. van Doorn (2010). https://netsec.ethz.ch/publications/papers/perrig-ccs-refutation.pdf