# 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-0013,M-0024&implementations=M-0013:I-0011

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.

None set. Every mechanism on the map was available.

## 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 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Network taps and certifiers / AI 2040 inference-only verification stack | Proposed | No published adversarial analysis recorded | Adversarial | None | Retrofit device | 0 / 1 / 0 | unspecified | unspecified | unspecified |
| Bounding unexplained information in outputs | Research demonstration | Published attack testing | Adversarial | Independent red-team | Retrofit device | 0 / 1 / 0 | depends | depends | not involved |

## Claims

No claims chosen.

## Mechanisms

### Network taps and certifiers

A proposed retrofit that splits data centres into isolated inference units, copies front-end traffic and re-runs random samples to confirm only declared inference runs. ([Network taps and certifiers](https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/))

- Assessment: selected implementation [AI 2040 inference-only verification stack](https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/).
- Development: Proposed (legacy code R1), assessed for showing that retrofitted data centres run only inference.
- Security evidence: No published adversarial analysis recorded. 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: required. Attack testing: none. 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.

### 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.
- Development: Research demonstration (legacy code R2), assessed for bounding how much hidden information can leave in checked inference outputs.
- Security evidence: Published attack testing. 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: 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.


## Properties

**Built for an adversarial prover**

- Network taps and certifiers
- Bounding unexplained information in outputs


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

- Bounding unexplained information in outputs: Independent red-team


## Limits

**Open significant failures**

- A recomputation family degrades against prompt-controlling adversaries (known failure, demonstrated attack, in AI 2040 inference-only verification stack; https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/evidence/flaws/3/) [1][2][6][7]. The plan's companion page names DiFR among the recomputation schemes being tested. An independent study found that Gumbel-based inference verification, the family that includes Token-DiFR, leaks roughly twice as many bits per token when the adversary chooses prompts that disrupt the text's structure, across six models of 1 to 32 billion parameters. The slowdown it imposes on a hidden-signalling adversary falls from 146–254 times under benign prompts to 60–118 times. The attack weakens the bound on hidden information in outputs, which the plan relies on to keep undeclared results from leaving.
- Prompt-controlled entropy inflation widens the covert channel (known failure, demonstrated attack, in Bounding unexplained information in outputs; https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/evidence/flaws/1/) [6][7]. 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.

**Family finding context**

- Context for AI 2040 inference-only verification stack. Findings from the mechanism family appear here as context. They apply to an implementation only when its own record lists them, under the conditions stated there. Output nondeterminism leaves covert capacity (known failure, theoretical argument, in Network taps and certifiers; https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/evidence/flaws/1/) [7][8]. Hashing cannot remove information hidden in the outputs themselves. The Secure Gateway Device paper estimates that about 0.1 bit per token remains even with seed-synchronized replay checks. For a 200k-GPU inference cluster at full load (2,000 tokens per GPU per second), that is about 40 Mbit/s of covert egress, enough to move a 1 TB model in under three days. The paper names this the core remaining challenge and points to deterministic replay or active scrubbing of hardware-induced entropy. An independent study found that an adversary who chooses the prompts roughly doubles the bits leaked per token under Gumbel-based inference verification; see Bounding unexplained information in outputs.

  Related mechanism: Deterministic and bit-exact inference (R3, not in the proposal). Deterministic replay is one of the two remedies the flaw's source names.

  Related mechanism: Bounding unexplained information in outputs (R2, in the proposal). Bounds the hidden information outputs can carry by measuring what the declared computation fails to predict.
- Context for AI 2040 inference-only verification stack. Findings from the mechanism family appear here as context. They apply to an implementation only when its own record lists them, under the conditions stated there. Some links cannot be passively tapped (scope limitation, open question, in Network taps and certifiers; https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/evidence/flaws/2/) [9][10]. Cankaya notes that copper-connected scale-up domains (for example NVL72 racks and TPU v7 cubes) are much harder to tap than fibre, and that optical budgets make passive taps impractical on 400GBASE-SR8 multimode links. Amodo found no taps advertised for 53 GBaud links as of May 2026.
- Context for AI 2040 inference-only verification stack. Findings from the mechanism family appear here as context. They apply to an implementation only when its own record lists them, under the conditions stated there. Encrypted fabrics hide plaintext from both parties (scope limitation, open question, in Network taps and certifiers; https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/evidence/flaws/3/) [9]. Cankaya notes that with TEE-protected sessions whose keys are ephemeral and managed inside the TEE, neither the operator nor the manufacturer can recover session keys after the session, so tapped traffic could not be opened for recomputation. For other encrypted fabrics, the operator can retain keys.
- Context for AI 2040 inference-only verification stack. Findings from the mechanism family appear here as context. They apply to an implementation only when its own record lists them, under the conditions stated there. Residual side channels in simple passive setups (known failure, theoretical argument, in Network taps and certifiers; https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/evidence/flaws/4/) [5]. Amodo's analysis of its own tapped prototype lists unvalidated header fields, timing of permitted traffic and variation in response formatting as residual channels, and concludes that the passive tap must be replaced by an active one.
- Context for AI 2040 inference-only verification stack. Findings from the mechanism family appear here as context. They apply to an implementation only when its own record lists them, under the conditions stated there. Completeness rests on physical monitoring left out of scope (scope limitation, open question, in Network taps and certifiers; https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/evidence/flaws/5/) [8]. The Secure Gateway Device paper assumes the facility is physically monitored, and states that the whole architecture depends on the device being the only communication channel. It names radio emanation, power-line signalling and thermal channels as covert channels beyond that scope.

  Related mechanism: Side-channel suppression for isolated facilities (R1, not in the proposal). Addresses the radio, power-line and thermal channels that network-level designs leave out.
- Context for AI 2040 inference-only verification stack. Findings from the mechanism family appear here as context. They apply to an implementation only when its own record lists them, under the conditions stated there. Verifier dictionary attacks on hashes (known failure, theoretical argument, in Network taps and certifiers; https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/evidence/flaws/6/) [8]. Hashes of very short outputs could be brute-forced by the verifier. The paper recommends hashing at least 5 tokens together, or at least 10 if the attacker filters for likely tokens.

**Scope limitations**

- The recomputation server must be trusted (scope limitation, theoretical argument, in AI 2040 inference-only verification stack; https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/evidence/flaws/1/) [1][2][4]. The plan calls the integrity of the recomputation server an extremely important aspect, and its argument that sampling verifies all outputs assumes that the server's computations and outputs can be trusted. The companion page notes that the server sits inside the prover's facility, possibly under the prover's physical control, and that hardening it against integrity attacks needs significant research. Amodo rates recomputation-server security as not on track.
- Spare compute is not verified (scope limitation, theoretical argument, in AI 2040 inference-only verification stack; https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/evidence/flaws/2/) [1]. The plan states that it does not verify that spare compute is unused for unapproved workloads, because this seems very challenging. It relies instead on side-channel bounds and memory wipes, so that the only results that persist are verified inference outputs.
- Information the declared computation explains is not bounded (scope limitation, theoretical argument, in Bounding unexplained information in outputs; https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/evidence/flaws/2/) [11][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 (scope limitation, theoretical argument, in Bounding unexplained information in outputs; https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/evidence/flaws/3/) [6][13]. 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.

**Open questions**

- The facility-level design is untested (open question, open question, in Bounding unexplained information in outputs; https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/evidence/flaws/4/) [11]. The compute-verification architecture is described with protocol details, potential attacks and prototyping plans, but no prototype results have been published.

**Not yet demonstrated**

- Network taps and certifiers: Proposed (legacy code R1), assessed for showing that retrofitted data centres run only inference


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

- **Deterministic and bit-exact inference** (Operational use (legacy code R3), assessed for reproducing open-model inference from receipts in Gensyn's information-market service)
  - Bears on the open significant failure "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** (Research demonstration (legacy code R2), assessed for monitoring inter-node traffic with operator-run software on four GPUs)
  - 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.
- **Tamper evidence for verifier devices** (Research demonstration (legacy code R2), assessed for detecting probing of proposed verifier hardware, using server and electronics prototypes as evidence)
  - Network taps and certifiers waits on it: Checking that taps are correctly installed and stay in place at scale is not a solved problem, and hardening the recomputation server inside the prover's facility needs significant research.
- **Memory wiping and proofs of secure erasure** (Proposed (legacy code R1), assessed for showing that no data from earlier work persists in memory the wipe reaches)
  - Network taps and certifiers waits on it: Memory wiping may use existing algorithms, but hardware testing is at an early stage.
- **Side-channel suppression for isolated facilities** (Proposed (legacy code R1), assessed for bounding physical covert channels out of a verified enclosure)
  - Network taps and certifiers waits on it: There is no plan yet for quickly scaling side-channel defences on a frontier cluster; only early theoretical pieces exist.
  - 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.
- **Whole-workload recomputation (reproducible packets)** (Proposed (legacy code R1), assessed for recomputing whole workloads to show a cluster runs only declared inference)
  - Network taps and certifiers waits on it: A fully reproducible inference stack needs substantial software and tooling, and per-packet network reproducibility may need considerable software, firmware and possibly hardware work.
- **Sampled inference recomputation** (Operational use (legacy code R3), assessed for checking untrusted workers' activations against the declared model, prompt and precision)
  - Network taps and certifiers depends on it.
  - Bounding unexplained information in outputs depends on it.


## Dependencies

**Missing prerequisites**

- Sampled inference recomputation (Operational use (legacy code R3), assessed for checking untrusted workers' activations against the declared model, prompt and precision), needed by Network taps and certifiers and Bounding unexplained information in outputs
- Whole-workload recomputation (reproducible packets) (Proposed (legacy code R1), assessed for recomputing whole workloads to show a cluster runs only declared inference), needed by Network taps and certifiers
- Bandwidth limits and compartmentalization (Research demonstration (legacy code R2), 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 (Proposed (legacy code R1), assessed for bounding physical covert channels out of a verified enclosure), needed by Bounding unexplained information in outputs

**Shared foundations**

- Sampled inference recomputation, relied on by Network taps and certifiers and Bounding unexplained information in outputs
- Side-channel suppression for isolated facilities, relied on by Network taps and certifiers and Bounding unexplained information in outputs

**Blockers**

- Network taps and certifiers: A fully reproducible inference stack needs substantial software and tooling, and per-packet network reproducibility may need considerable software, firmware and possibly hardware work. (performance & compatibility; waits on Whole-workload recomputation (reproducible packets)) [2]
- Network taps and certifiers: Passive optical taps work at 400G, but the 800G and 1600G line rates now arriving in data centres are undemonstrated. (performance & compatibility; waits on Network taps and certifiers) [2]
- Network taps and certifiers: Checking that taps are correctly installed and stay in place at scale is not a solved problem, and hardening the recomputation server inside the prover's facility needs significant research. (hardware trust; waits on Tamper evidence for verifier devices) [2][4]
- Network taps and certifiers: There is no plan yet for quickly scaling side-channel defences on a frontier cluster; only early theoretical pieces exist. (coverage & hidden compute; waits on Side-channel suppression for isolated facilities) [2]
- Network taps and certifiers: Memory wiping may use existing algorithms, but hardware testing is at an early stage. (coverage & hidden compute; waits on Memory wiping and proofs of secure erasure) [2]
- Network taps and certifiers: Robust red-teaming of recomputation schemes has not started, and most algorithm development remains academic. (adversarial validation) [2][4]
- 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) [11]
- 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) [6][13]
- 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) [7][13]
- 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) [11]
- Bounding unexplained information in outputs: No prototype of the facility-level architecture exists to red-team. (adversarial validation) [11]


## 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 none; unspecified for Network taps and certifiers.
- Inputs and outputs: shown by none; depends on the design for Bounding unexplained information in outputs; hidden by none; not involved in none; unspecified for Network taps and certifiers.
- Training data: shown by none; depends on the design for none; hidden by none; not involved in Bounding unexplained information in outputs; unspecified for Network taps and certifiers.

## Implementations

- Network taps and certifiers: [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); [SASH confidential network logger](https://trustbutveri.fyi/implementations/sash-confidential-network-logger/) (R1, research prototype)
- Bounding unexplained information in outputs: none on the map

## Sources

1. Verification Plan, R. Dean (2026). https://ai-2040.com/supplements/verification-plan
2. Get Involved in Verification, AI Futures Project (2026). https://ai-2040.com/supplements/verification-plan/get-involved
3. Verifying international AI deals: Plan A, the state-of-play, and what you can do to help, T. Milton et al. (2026). https://amodo.substack.com/p/verifying-international-ai-deals
4. AI 2040 Plan A — Verification SITREP, Amodo Design (2026). https://amododesign.com/ai-verification/plan-a-sitrep/
5. Fitting a Network TAP to our Inference Verification Prototype, Amodo Design (2026). https://amododesign.com/notes/2026-09-15-network-tap-inference-verification/
6. Verifying LLM Inference to Detect Model Weight Exfiltration, R. Rinberg et al. (2025). https://arxiv.org/abs/2511.02620
7. Adversarial Entropy Inflation Against Gumbel-Based Inference Verification, N. Kezins (2026). https://arxiv.org/abs/2608.23375
8. Fingerprinting All AI Cluster I/O Without Mutually Trusted Processors, N. Cankaya et al. (2026). https://arxiv.org/abs/2606.10724
9. The Fundamentals and Feasibility of Secure Network Taps for Verifying AI Datacenter Use, N. Cankaya (2026). https://nacicankaya.substack.com/p/research-note-the-fundamentals-and
10. Network Tapping for AI Verification: A Technical Assessment, Amodo Design (2026). https://amododesign.com/notes/2026-05-03-network-tapping/
11. Verifying AI Compute by Bounding Unexplained Information Exfiltration, J. Petrie & Y. Mühlhäuser (2026). https://openreview.net/forum?id=qtgG5HZSsk
12. Haiku to Opus in Just 10 bits: LLMs Unlock Large Compression Gains, R. Rinberg et al. (2026). https://arxiv.org/abs/2604.02343
13. 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