# 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-0015,M-0024&ready=R4

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.

- **Minimum readiness: R4 Deployment-ready.** Keeps mechanisms whose readiness level is at least this one. A level describes the public evidence for a mechanism's stated use, not its cost or feasibility. R3 can still have open critical flaws.

0 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 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Memory wiping and proofs of secure erasure (excluded by the filters) | R1 | Adversarial | Analysis | None | 0 / 2 / 1 | not involved | not involved | not involved |
| Bounding unexplained information in outputs (excluded by the filters) | R2 | Adversarial | Independent red-team | Retrofit device | 0 / 4 / 0 | depends | depends | not involved |

## Claims

No claims chosen.

## Mechanisms

### Memory wiping and proofs of secure erasure

Overwriting a device's memory in a way a verifier can check, so that data from earlier, undeclared work cannot persist in memory the wipe reaches. ([Memory wiping and proofs of secure erasure](https://trustbutveri.fyi/mechanisms/memory-wiping-and-secure-erasure/))

- Assessment: mechanism family.
- Readiness: R1 Proposed, assessed for showing that no data from earlier work persists in memory the wipe reaches.
- Claims in this proposal: none of them.
- Threat model: adversarial prover. Hardware: none. 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. Overwrites memory with verifier-chosen data; it does not handle model data.
- Filter conflict: Readiness R1 is below the minimum of R4.

### Bounding unexplained information in outputs

Limits the hidden information a facility's outputs can carry by measuring how much of those outputs the declared computation fails to predict. ([Bounding unexplained information in outputs](https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/))

- Assessment: mechanism family.
- Readiness: R2 Demonstrated, assessed for bounding how much hidden information can leave in checked inference outputs.
- Claims in this proposal: none of them.
- Threat model: adversarial prover. Hardware: retrofit device. Prover cooperation: required. Attack testing: independent red-team. Category: Isolation & system architectures.
- What the verifier sees: model weights depends; inputs and outputs depends; training data not involved. Depends on where recomputation runs: in a sealed enclosure, or with zero-knowledge proofs, the verifier need not see the weights or the traffic.
- Filter conflict: Readiness R2 is below the minimum of R4.


## Properties

Not counted as properties, because the filters exclude them: Memory wiping and proofs of secure erasure and Bounding unexplained information in outputs.


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

- Memory wiping and proofs of secure erasure: Analysis (excluded by filters)
- Bounding unexplained information in outputs: Independent red-team (excluded by filters)


## Limits

**Excluded by the filters**

- Memory wiping and proofs of secure erasure: Readiness R1 is below the minimum of R4.
- Bounding unexplained information in outputs: Readiness R2 is below the minimum of R4.

**Open significant flaws**

- Memory the wipe cannot reach (open question, in Memory wiping and proofs of secure erasure; https://trustbutveri.fyi/mechanisms/memory-wiping-and-secure-erasure/#flaw-1) [5][6]. Amodo's inventory of a GB200 system lists many memory stores beyond GPU HBM and host DRAM. It notes that SSD controller DRAM sits on a private bus that host commands cannot read or write, and that its optimized algorithm leaves 25 GiB of HBM unattested. It also asks how switch memory could be wiped.
- Outside help during challenges (theoretical argument, in Memory wiping and proofs of secure erasure; https://trustbutveri.fyi/mechanisms/memory-wiping-and-secure-erasure/#flaw-2) [3][4]. Classic proofs of secure erasure assume the device is isolated during the protocol. Bursuc et al. relax this to a bound on how close a helper can be, enforced by round-trip times. In data centres, remote memory access has round trips of about 1–2 µs, against about 70–200 ns for local DRAM. The MIRI overview therefore says verification depends on ruling out RDMA by latency or physical disconnection.

  Related mechanism: Timed challenge-response and memory-occupation challenges (R2, not in the proposal). Timed challenges bound how far away a helper can be by how quickly it must answer.

  Related mechanism: Bandwidth limits and compartmentalization (R2, not in the proposal). Removing or capping links between groups of accelerators limits remote memory access during a challenge.
- Prompt-controlled entropy inflation widens the covert channel (demonstrated attack, in Bounding unexplained information in outputs; https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/#flaw-1) [10][11]. Gumbel-based inference verification tolerates token choices that honest GPU nondeterminism could produce, and the size of that tolerated set grows with the model's output entropy. Kezins, an independent researcher, showed that an adversary who controls the prompt distribution can raise output entropy and roughly double the bits leaked per token. Across six models of 1 to 32 billion parameters, this cut the slowdown from 146–254 times under benign prompts to 60–118 times. Kezins argues that architectures built on the same unexplained-information bound inherit this attack surface, and recommends calibrating tolerances against local token entropy rather than benign traffic.

  Related mechanism: Deterministic and bit-exact inference (R3, not in the proposal). Bit-exact replay would remove the tolerance for numerical noise that sets the size of this channel. The record notes that it needs full hardware and software metadata.
- Information the declared computation explains is not bounded (theoretical argument, in Bounding unexplained information in outputs; https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/#flaw-2) [9][12]. The bound limits unexplained bits only. Outputs that the declared computation fully explains can still carry valuable information: a compression study notes that an adversary with inference access can extract more proprietary information per bit than naive transmission allows.
- Channels other than checked outputs are outside the bound (theoretical argument, in Bounding unexplained information in outputs; https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/#flaw-3) [4][10]. The inference-verification scheme treats side channels as out of scope. A low-trust system design argues that suppressing physical covert bandwidth below kilobits per second is much more achievable than aiming for zero, and that a malicious device can leak one bit of information by deliberately outputting a wrong result.

  Related mechanism: Side-channel suppression for isolated facilities (R1, not in the proposal). Physical side channels need separate suppression, which is this mechanism's purpose.
- The facility-level design is untested (open question, in Bounding unexplained information in outputs; https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/#flaw-4) [9]. The compute-verification architecture is described with protocol details, potential attacks and prototyping plans, but no prototype results have been published.

**Open minor flaws**

- Gap between erased and total memory (theoretical argument, in Memory wiping and proofs of secure erasure; https://trustbutveri.fyi/mechanisms/memory-wiping-and-secure-erasure/#flaw-3) [3]. Bursuc et al. note that memory left between the erased region and the device's full memory could hold data, and that their bounds are tighter only against a restricted adversary.

**Not yet demonstrated**

- Memory wiping and proofs of secure erasure: R1 Proposed, assessed for showing that no data from earlier work persists in memory the wipe reaches


## 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). Excluded by the filters: readiness R3
  - Bears on the open significant flaw "Prompt-controlled entropy inflation widens the covert channel" in Bounding unexplained information in outputs. Bit-exact replay would remove the tolerance for numerical noise that sets the size of this channel. The record notes that it needs full hardware and software metadata.
  - Bounding unexplained information in outputs waits on it: Tolerance for numerical nondeterminism sets the size of the residual channel; bit-exact replay would remove it but needs full hardware and software metadata.
- **Bandwidth limits and compartmentalization** (R2 Demonstrated, assessed for monitoring inter-node traffic with operator-run software on four GPUs). Excluded by the filters: readiness R2
  - Bears on the open significant flaw "Outside help during challenges" in Memory wiping and proofs of secure erasure. Removing or capping links between groups of accelerators limits remote memory access during a challenge.
  - Bounding unexplained information in outputs waits on it: The prover's compute must be isolated so that all traffic passes through the verifier's interlock; any unmonitored path voids the bound.
- **Timed challenge-response and memory-occupation challenges** (R2 Demonstrated, assessed for detecting whether a GPU is doing other work). Excluded by the filters: readiness R2
  - Bears on the open significant flaw "Outside help during challenges" in Memory wiping and proofs of secure erasure. Timed challenges bound how far away a helper can be by how quickly it must answer.
  - Memory wiping and proofs of secure erasure waits on it: Timed challenges must exclude remote memory and other helpers.
- **Side-channel suppression for isolated facilities** (R1 Proposed, assessed for bounding physical covert channels out of a verified enclosure). Excluded by the filters: readiness R1
  - Bears on the open significant flaw "Channels other than checked outputs are outside the bound" in Bounding unexplained information in outputs. Physical side channels need separate suppression, which is this mechanism's purpose.
  - Bounding unexplained information in outputs waits on it: Physical side channels need separate suppression, and one design treats a low residual bandwidth, rather than zero, as the realistic target.
- **Sampled inference recomputation** (R3 In production, assessed for checking untrusted workers' activations against the declared model, prompt and precision). Excluded by the filters: readiness R3
  - Bounding unexplained information in outputs depends on it.
- **Network taps and certifiers** (R1 Proposed, assessed for committing a complete record of cluster traffic, so declared inference can be checked). Excluded by the filters: readiness R1
  - Bounding unexplained information in outputs depends on it.


## Dependencies

**Missing prerequisites**

- Timed challenge-response and memory-occupation challenges (R2 Demonstrated, assessed for detecting whether a GPU is doing other work), needed by Memory wiping and proofs of secure erasure
- Sampled inference recomputation (R3 In production, assessed for checking untrusted workers' activations against the declared model, prompt and precision), needed by Bounding unexplained information in outputs
- Bandwidth limits and compartmentalization (R2 Demonstrated, assessed for monitoring inter-node traffic with operator-run software on four GPUs), needed by Bounding unexplained information in outputs
- Side-channel suppression for isolated facilities (R1 Proposed, assessed for bounding physical covert channels out of a verified enclosure), needed by Bounding unexplained information in outputs
- Network taps and certifiers (R1 Proposed, assessed for committing a complete record of cluster traffic, so declared inference can be checked), needed by Bounding unexplained information in outputs

**Blockers**

- Memory wiping and proofs of secure erasure: Wipes take time: tens of minutes for a pod's volatile memory and hours for SSDs, displacing work. (performance & compatibility) [4][5][6]
- Memory wiping and proofs of secure erasure: Timed challenges must exclude remote memory and other helpers. (coverage & hidden compute; waits on Timed challenge-response and memory-occupation challenges) [3][4]
- Memory wiping and proofs of secure erasure: All memory stores in a system must be inventoried and wiped at the same time. (coverage & hidden compute) [5]
- Bounding unexplained information in outputs: The prover's compute must be isolated so that all traffic passes through the verifier's interlock; any unmonitored path voids the bound. (coverage & hidden compute; waits on Bandwidth limits and compartmentalization) [9]
- Bounding unexplained information in outputs: Physical side channels need separate suppression, and one design treats a low residual bandwidth, rather than zero, as the realistic target. (coverage & hidden compute; waits on Side-channel suppression for isolated facilities) [4][10]
- Bounding unexplained information in outputs: Tolerance for numerical nondeterminism sets the size of the residual channel; bit-exact replay would remove it but needs full hardware and software metadata. (protocol soundness; waits on Deterministic and bit-exact inference) [4][11]
- Bounding unexplained information in outputs: Recomputation over confidential weights and inputs needs a protected setting: prover recomputation in a verifier-controlled enclosure, verifier recomputation in a prover-controlled enclosure, or zero-knowledge proofs. (privacy & leakage) [9]
- Bounding unexplained information in outputs: No prototype of the facility-level architecture exists to red-team. (adversarial validation) [9]


## What the verifier sees

- Model weights: shown by none; depends on the design for Bounding unexplained information in outputs; hidden by none; not involved in Memory wiping and proofs of secure erasure; unspecified for none.
- Inputs and outputs: shown by none; depends on the design for Bounding unexplained information in outputs; hidden by none; not involved in Memory wiping and proofs of secure erasure; unspecified for none.
- Training data: shown by none; depends on the design for none; hidden by none; not involved in Memory wiping and proofs of secure erasure and Bounding unexplained information in outputs; unspecified for none.

## Implementations

- Memory wiping and proofs of secure erasure: [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)
- Bounding unexplained information in outputs: none on the map

## Sources

1. Verification Plan, R. Dean (2026). https://ai-2040.com/supplements/verification-plan
2. 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
3. Software-Based Memory Erasure with Relaxed Isolation Requirements, S. Bursuc et al. (2024). https://ieeexplore.ieee.org/document/10664348/
4. 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
5. Memory Wipes - Performance Analysis, Amodo Design (2026). https://amododesign.com/notes/2026-07-01-memory-wiping/
6. Improving Disk Wiping Speed for Memory Wipes, Amodo Design (2026). https://amododesign.com/notes/2026-09-14-disk-wiping-speed/
7. Amodo-Design/PoSE-Memory-Wiping (GitHub repository), Amodo Design (2026). https://github.com/Amodo-Design/PoSE-Memory-Wiping
8. Empirical Evaluation of Memory-Erasure Protocols, R. Gil-Pons et al. (2025). https://www.scitepress.org/Papers/2025/135548/135548.pdf
9. Verifying AI Compute by Bounding Unexplained Information Exfiltration, J. Petrie & Y. Mühlhäuser (2026). https://openreview.net/forum?id=qtgG5HZSsk
10. Verifying LLM Inference to Detect Model Weight Exfiltration, R. Rinberg et al. (2025). https://arxiv.org/abs/2511.02620
11. Adversarial Entropy Inflation Against Gumbel-Based Inference Verification, N. Kezins (2026). https://arxiv.org/abs/2608.23375
12. Haiku to Opus in Just 10 bits: LLMs Unlock Large Compression Gains, R. Rinberg et al. (2026). https://arxiv.org/abs/2604.02343