# 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-0023,M-0014,M-0010&cols=hardware

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 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Safeguard attestation | R2 | Semi-trusted | Analysis | Existing features | 0 / 5 / 0 | depends | depends | not involved |
| Bandwidth limits and compartmentalization | R2 | Adversarial | Analysis | Retrofit device | 0 / 5 / 0 | not involved | not involved | not involved |
| On-chip telemetry from timing, memory and performance counters | R2 | Semi-trusted | Red-teamed | Existing features | 1 / 3 / 1 | depends | depends | depends |

## Claims

No claims chosen.

## Mechanisms

### Safeguard attestation

Hardware-signed evidence that an AI service ran its declared safeguards, such as a guardrail classifier or monitor, when producing a given response. ([Safeguard attestation](https://trustbutveri.fyi/mechanisms/safeguard-attestation/))

- Assessment: mechanism family.
- Readiness: R2 Demonstrated, assessed for attesting that a declared safeguard mediated a service's responses.
- Claims in this proposal: none of them.
- Threat model: semi-trusted prover. Hardware: existing features. Prover cooperation: required. Attack testing: analysis. Category: Cryptographic & computational.
- What the verifier sees: model weights depends; inputs and outputs depends; training data not involved. The enclave route signs hashes of the safeguard, request and response; a low-trust design has the verifier re-run and screen sampled requests itself.

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

### On-chip telemetry from timing, memory and performance counters

Uses timing, memory-residency and performance-counter signals measured on AI accelerators as evidence about which workloads they are running. ([On-chip telemetry from timing, memory and performance counters](https://trustbutveri.fyi/mechanisms/on-chip-telemetry/))

- Assessment: mechanism family.
- Readiness: R2 Demonstrated, assessed for workload evidence from GPU counters and timing, assuming authentic measurements.
- Claims in this proposal: none of them.
- Threat model: semi-trusted prover. Hardware: existing features. Prover cooperation: partial. Attack testing: red-teamed. Category: On-chip & hardware-enabled.
- What the verifier sees: model weights depends; inputs and outputs depends; training data depends. Counters do not read weights or data, but richer counters can leak secrets through side channels.


## Properties

**Built for an adversarial prover**

- Bandwidth limits and compartmentalization

**No new hardware needed**

- Safeguard attestation
- On-chip telemetry from timing, memory and performance counters


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

- Safeguard attestation: Analysis
- Bandwidth limits and compartmentalization: Analysis
- On-chip telemetry from timing, memory and performance counters: Red-teamed


## Limits

**Open critical flaws**

- Software-read telemetry can be forged by the operator (theoretical argument, in On-chip telemetry from timing, memory and performance counters; https://trustbutveri.fyi/mechanisms/on-chip-telemetry/#flaw-1) [20][22]. NVML-based classification assumes trustworthy telemetry. Without a tamper-resistant read path, an authenticated telemetry channel and secure boot of the monitoring software, an operator who controls the full software stack could forge counter values. Monfared et al. start from the same premise: current GPUs expose little trusted telemetry and can be modified or virtualized.

  Related mechanism: Hardware-enabled guarantees (flexHEG) and guarantee processors (R1, not in the proposal). A guarantee processor on the chip would give the tamper-resistant, authenticated telemetry path the flaw says is missing.

**Open significant flaws**

- Attestation shows a safeguard ran, not that it is effective (theoretical argument, in Safeguard attestation; https://trustbutveri.fyi/mechanisms/safeguard-attestation/#flaw-1) [1]. Proof of guardrail ensures that the guardrail executed, but the guardrail can still err or be jailbroken. Because the guardrail must be open source, a malicious developer can attack it with jailbreaks while still presenting a valid proof. In the authors' evaluation, Llama Guard 3 reached an F1 score of 0.56 on the unsafe class of the ToxicChat dataset. The authors state that proof of guardrail should not be interpreted or advertised as proof of safety.
- Selective attestation leaves traffic uncovered (theoretical argument, in Safeguard attestation; https://trustbutveri.fyi/mechanisms/safeguard-attestation/#flaw-2) [1][4][9]. Attestations are issued per response. In the prototype, the agent offers them when it receives high-stakes questions, so nothing shows that unattested traffic went through the same path. PAL*M's authors note that a prover could cherry-pick favourable executions, and suggest verifier-published nonces or requesting only session-level proofs. A governance analysis notes that auditors also need assurance that all activity is accounted for, since a host could start a second confidential virtual machine that bypasses monitoring.

  Related mechanism: On-chip telemetry from timing, memory and performance counters (R2, in the proposal). On-chip counters are a proposed route to evidence about everything a chip runs, including a second virtual machine that skips the safeguard.
- Measurements may omit behaviour-relevant configuration or runtime changes (theoretical argument, in Safeguard attestation; https://trustbutveri.fyi/mechanisms/safeguard-attestation/#flaw-3) [9]. Every component that influences inference behaviour must be covered by the launch measurement, including feature flags, environment variables and invocation arguments. A launch measurement also does not show that a program keeps running as measured if the kernel is later compromised.
- Components outside the attested boundary (theoretical argument, in Safeguard attestation; https://trustbutveri.fyi/mechanisms/safeguard-attestation/#flaw-4) [1][2]. In the proof-of-guardrail experiments, the guardrail model and the agent's backend model were both reached through external APIs, and the authors leave the decision to trust those APIs to the verifier. The measured wrapper must also have no vulnerability that lets the unmeasured agent bypass the guardrail, for example by executing arbitrary commands inside the enclave. The code's README states that the enclave does not currently restrict the agent's arbitrary command execution, which could be used to bypass guardrails.
- Memory-bus interposition extracts attestation keys and forges attestations (demonstrated attack, in Safeguard attestation; https://trustbutveri.fyi/mechanisms/safeguard-attestation/#flaw-5) [1][4][7][8][9][10][11][12][13]. Inherited finding. Applies to variants using the affected Intel or AMD trust roots. PAL*M excludes physical attacks. A TDX-backed safeguard claim against a physical host attacker would be defeated, but these studies do not demonstrate a break of the AWS Nitro proof-of-guardrail prototype or of verifier-side recomputation. The TEE findings cover DDR5 attacks on Intel TDX, the H100 relay demonstration, DDR4 attacks on AMD SEV-SNP, and software-only SEV-SNP forgery before AMD's fixes. These are inherited hardware limits; a governance analysis explains why physical access matters in a treaty setting. Related finding: https://trustbutveri.fyi/mechanisms/tee-remote-attestation/#flaw-1.

  Response: Intel and AMD place the physical attack class outside their threat models, according to the researchers. AMD reports firmware fixes for RMPocalypse.

  Related mechanism: Hardware-enabled guarantees (flexHEG) and guarantee processors (R1, not in the proposal). A tamper-protected enclosure around the chip is the proposed answer when the party that holds the hardware may attack it physically.
- 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) [15][18][19]. 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) [15]. 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) [15]. 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) [15]. 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) [17]. 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.
- Adversarially disguised fine-tuning partly evades classification (demonstrated attack, in On-chip telemetry from timing, memory and performance counters; https://trustbutveri.fyi/mechanisms/on-chip-telemetry/#flaw-2) [22]. Across 20 evasion strategy families in five monitor-evader rounds, the classifier's accuracy against the most challenging disguised workloads held out from training was 43–87%. White-box LoRA fine-tuning was the only evasion family detected less than half the time. The evaluation covered single nodes, PyTorch-level evasion and NVIDIA hardware.
- Timing challenges do not identify the individual chip (theoretical argument, in On-chip telemetry from timing, memory and performance counters; https://trustbutveri.fyi/mechanisms/on-chip-telemetry/#flaw-3) [20]. GEMM and VDF challenges can be answered by identical GPUs elsewhere, and floating-point fingerprints distinguish GPU models, not individual devices. GPU virtualization adds timing leakage that prevents attributing compute use.
- Counters leak information about protected workloads (theoretical argument, in On-chip telemetry from timing, memory and performance counters; https://trustbutveri.fyi/mechanisms/on-chip-telemetry/#flaw-4) [9][23]. Performance counters have been used as a side channel against TEEs, for example in CounterSEVeillance. NVIDIA disables performance counters in full confidential-computing mode, stating that they could provide an avenue for side-channel attacks. Richer counters for verification therefore pull against confidentiality.

**Open minor flaws**

- No quantified error rates or formal thresholds for timing primitives (open question, in On-chip telemetry from timing, memory and performance counters; https://trustbutveri.fyi/mechanisms/on-chip-telemetry/#flaw-5) [20]. Monfared et al. state that false-positive and false-negative rates are not quantified and leave hardware-specific formal thresholds to future work.


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

- **Hardware-enabled guarantees (flexHEG) and guarantee processors** (R1 Proposed, assessed for checking and enforcing training-compute limits on chips, against adversaries up to states)
  - Bears on the open critical flaw "Software-read telemetry can be forged by the operator" in On-chip telemetry from timing, memory and performance counters. A guarantee processor on the chip would give the tamper-resistant, authenticated telemetry path the flaw says is missing.
  - Bears on the open significant flaw "Memory-bus interposition extracts attestation keys and forges attestations" in Safeguard attestation. A tamper-protected enclosure around the chip is the proposed answer when the party that holds the hardware may attack it physically.
  - On-chip telemetry from timing, memory and performance counters waits on it: Shipping accelerators need a tamper-resistant, authenticated telemetry path.
- **Model identity attestation** (R3 In production, assessed for showing users that a service runs the declared model weights)
  - Safeguard attestation waits on it: Safeguard evidence must be bound to the model actually served, which depends on model-identity attestation.
- **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)
  - Safeguard attestation waits on it: Frontier model inference typically needs several GPUs, GPU confidential computing is less mature than CPU support, and CPU inference, which an enclave prototype had to use, ran about 100 times slower than GPU inference.
  - Safeguard attestation waits on it: Trust rests on a small number of hardware vendors, and a per-CPU Intel attestation key has been extracted by physical attack.
  - On-chip telemetry from timing, memory and performance counters depends on it.
- **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**

- 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 Safeguard attestation and On-chip telemetry from timing, memory and performance counters
- Model identity attestation (R3 In production, assessed for showing users that a service runs the declared model weights), needed by Safeguard attestation
- 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

**Shared foundations**

- TEE remote attestation for AI workloads, relied on by Safeguard attestation and On-chip telemetry from timing, memory and performance counters

**Blockers**

- Safeguard attestation: No published design shows that all of a provider's traffic passes through the attested safeguard path; current evidence covers individual attested responses. (coverage & hidden compute) [1][9]
- Safeguard attestation: Frontier model inference typically needs several GPUs, GPU confidential computing is less mature than CPU support, and CPU inference, which an enclave prototype had to use, ran about 100 times slower than GPU inference. (performance & compatibility; waits on TEE remote attestation for AI workloads) [9][24]
- Safeguard attestation: Trust rests on a small number of hardware vendors, and a per-CPU Intel attestation key has been extracted by physical attack. (hardware trust; waits on TEE remote attestation for AI workloads) [7][9]
- Safeguard attestation: Safeguard evidence must be bound to the model actually served, which depends on model-identity attestation. (evidence binding; waits on Model identity attestation) [24][25]
- Safeguard attestation: No independent red-team or audit of a safeguard-attestation system has been published, and the available prototypes are described by their authors as proofs of concept that have not been stress-tested by a counterparty. (adversarial validation) [2][6]
- Bandwidth limits and compartmentalization: No cap that a verifier can check has been implemented or red-teamed. (adversarial validation) [15]
- 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) [13]
- 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) [15][17]
- Bandwidth limits and compartmentalization: Advances in low-communication training could shrink the margin that the cap enforces. (capacity bounds) [15][18][19]
- On-chip telemetry from timing, memory and performance counters: Shipping accelerators need a tamper-resistant, authenticated telemetry path. (hardware trust; waits on Hardware-enabled guarantees (flexHEG) and guarantee processors) [21][22]
- On-chip telemetry from timing, memory and performance counters: NVIDIA's full confidential-computing mode disables the hardware performance counters its profiling tools use, so telemetry that needs them conflicts with it. (privacy & leakage) [9][23]
- On-chip telemetry from timing, memory and performance counters: Continuous challenge puzzles cost power and throughput on production workloads. (performance & compatibility) [20]
- On-chip telemetry from timing, memory and performance counters: Evaluation has not gone beyond single nodes, framework-level evasion and one vendor's hardware. (adversarial validation) [22]


## What the verifier sees

- Model weights: shown by none; depends on the design for Safeguard attestation and On-chip telemetry from timing, memory and performance counters; hidden by none; not involved in Bandwidth limits and compartmentalization; unspecified for none.
- Inputs and outputs: shown by none; depends on the design for Safeguard attestation and On-chip telemetry from timing, memory and performance counters; hidden by none; not involved in Bandwidth limits and compartmentalization; unspecified for none.
- Training data: shown by none; depends on the design for On-chip telemetry from timing, memory and performance counters; hidden by none; not involved in Safeguard attestation and Bandwidth limits and compartmentalization; unspecified for none.

## Implementations

- Safeguard attestation: none on the map
- 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)
- On-chip telemetry from timing, memory and performance counters: none on the map

## Sources

1. Proof-of-Guardrail in AI Agents and What (Not) to Trust from It, X. Jin et al. (2026). https://arxiv.org/abs/2603.05786
2. Verifiable-ClawGuard: proof-of-guardrail reference code, SaharaLabsAI (2026). https://github.com/SaharaLabsAI/Verifiable-ClawGuard
3. Safety Without Compromising on Privacy, D. McCann-Sayles et al. (2026). https://tinfoil.sh/blog/2026-09-14-safety-without-compromising-privacy
4. PAL*M: Property Attestation for Large Generative Models, P. Chantasantitam et al. (2026). https://arxiv.org/abs/2601.16199
5. Enabling Verifiably-Scoped Monitoring through Large Language Models and Trusted Compute, B. Penchas et al. (2026). https://icml.cc/virtual/2026/78630
6. Auditor-in-a-Box: Tools for Third-Party Auditing, R. Rinberg & B. Penchas (2026). https://www.lesswrong.com/posts/uWYk7MM9hAf9GEbGe/auditor-in-a-box-tools-for-third-party-auditing
7. TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition, J. Chuang et al. (2026). https://tee.fail/
8. DDRop: Active Memory Interposer Attacks on Confidential VMs by Dropping DDR5 Writes, J. De Meulemeester et al. (2026). https://ddropattack.eu/
9. On TEEs for Privacy-Preserving Monitoring in AI Governance, Gloria Z (2026). https://techgov.intelligence.org/blog/on-tees-for-privacy-preserving-monitoring-in-ai-governance
10. Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing, J. De Meulemeester et al. (2026). https://batteringram.eu/
11. RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP, B. Schlüter & S. Shinde (2025). https://rmpocalypse.github.io/
12. SEV-SNP RMP Initialization Vulnerability (AMD-SB-3020), AMD (2025). https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3020.html
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
14. Verification Plan, R. Dean (2026). https://ai-2040.com/supplements/verification-plan
15. Traffic Shaping for Workload Classification, Lucid Computing (2026). https://lucidcomputing.substack.com/p/traffic-shaping-for-workload-classification
16. De-risking Interconnect Limits for AI Verification, A. Scher et al. (2026). https://techgov.intelligence.org/blog/de-risking-interconnect-limits-for-ai-verification
17. The Tray as a Bandwidth Boundary, Amodo Design (2026). https://amododesign.com/notes/2026-03-16-dpu-bandwidth-limiter/
18. DiLoCo: Distributed Low-Communication Training of Language Models, A. Douillard et al. (2024). https://arxiv.org/abs/2311.08105
19. Does Distributed Training Undermine Compute Governance?, R. Rahman (2026). https://arxiv.org/abs/2605.29359
20. Timing and Memory Telemetry on GPUs for AI Governance, S. K. Monfared et al. (2026). https://arxiv.org/abs/2602.09369
21. Guaranteeable Memory: An HBM-Based Chiplet for Verifiable AI Workloads, J. Petrie (2025). https://openreview.net/forum?id=uc79kOv0MV
22. Detecting Hidden ML Training With Zero-Overhead Telemetry, R. Rahman & S. Tajdari (2026). https://arxiv.org/abs/2606.19262
23. NVIDIA Secure AI with Blackwell and Hopper GPUs (White Paper), NVIDIA (2025). https://docs.nvidia.com/nvidia-secure-ai-with-blackwell-and-hopper-gpus-whitepaper.pdf
24. Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments, C. Schnabl et al. (2025). https://arxiv.org/abs/2506.23706
25. How Tinfoil Proves Exactly What Model Is Running, Tinfoil Team (2026). https://tinfoil.sh/blog/2026-02-03-proving-model-identity