Proposal Explorer

Add claims to see which ones the mechanisms address.

Built for an adversarial prover

Whole-workload recomputation (reproducible packets) and Proofs of useful work for capacity accounting

No new hardware needed

Safeguard attestation and Proofs of useful work for capacity accounting

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.

• Safeguard attestation: Analysis
• Proofs of useful work for capacity accounting: Analysis

Open significant failures

3 failures in 2 mechanisms

• Components outside the attested boundary in Safeguard attestation

  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. ^{1 2}

  Known failure · Theoretical argument · Significant · Open. On the record

• Memory-bus interposition extracts attestation keys and forges attestations in Safeguard attestation

  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. ^{1 4 7 8 9 10 11 12 13}

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

  Known failure · Demonstrated attack · Significant · Open · Inherited finding. On the record · Related finding in TEE remote attestation for AI workloads

  Related mechanism Proposed Hardware-enabled guarantees (flexHEG) and guarantee processors: A tamper-protected enclosure around the chip is the proposed answer when the party that holds the hardware may attack it physically. A pointer, not evidence that this failure is mitigated. Add

• Known shortcuts let a miner claim somewhat more work than it did in Proofs of useful work for capacity accounting

  Pearl's specification lists known mining speedups: crafted inputs, precision shortcuts, seed grinding, work reuse, and faster kernels or hardware. A policy check caps the summands a miner may skip at one-sixteenth of those in a tile. For capacity bounding, any gap between work proven and work possible leaves spare capacity. ²³

  Known failure · Theoretical argument · Significant · Open. On the record

Scope limitations

• Attestation shows a safeguard ran, not that it is effective in Safeguard attestation

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

  Scope limitation · Theoretical argument. On the record

• Selective attestation leaves traffic uncovered in Safeguard attestation

  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. ^{1 4 9}

  Scope limitation · Theoretical argument. On the record

  Related mechanism Research demo On-chip telemetry from timing, memory and performance counters: On-chip counters are a proposed route to evidence about everything a chip runs, including a second virtual machine that skips the safeguard. A pointer, not evidence that this failure is mitigated. Add

• Measurements may omit behaviour-relevant configuration or runtime changes in Safeguard attestation

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

  Scope limitation · Theoretical argument. On the record

• Spare compute is outside the scheme in Whole-workload recomputation (reproducible packets)

  The plan states that it does not verify that spare compute is not used for unapproved workloads, because this seems very challenging. Recomputation checks the correctness of declared work, not its completeness. ^{14 15}

  Scope limitation · Theoretical argument. On the record

  Related mechanism Proposed Proofs of useful work for capacity accounting: Proposed as one input to accounting for spare capacity on declared hardware. A pointer, not evidence that this failure is mitigated. In the proposal.

• Proves that work was done, not that no capacity remains in Proofs of useful work for capacity accounting

  Proof-of-work accounting bounds unmonitored compute only relative to an estimate of what the actor has. Attestable states that the verifier "needs a credible estimate of the compute available" to the actor, and that a proof "cannot discover a datacenter that was never declared". ²⁰

  Scope limitation · Theoretical argument. On the record

  Related mechanism Proposed Chip registries and manufacturing records: A registry of chips is one basis for the estimate of available compute that the flaw's source says the verifier needs. A pointer, not evidence that this failure is mitigated. Add

  Related mechanism Proposed Remote detection of data centres: Looks for data centres that were never declared, which a proof cannot discover. A pointer, not evidence that this failure is mitigated. Add

Open questions

• Non-compliant work could be encoded inside compliant-looking packets in Whole-workload recomputation (reproducible packets)

  The plan notes that an AI company might try to encode a non-compliant workload inside a workload that looks compliant on the surface. ¹⁴

  Open question · Theoretical argument. On the record

• Security rests on new hardness assumptions in Proofs of useful work for capacity accounting

  Komargodski and Weinstein base security on hardness assumptions about batches of low-rank random linear equations, and list PoUW "from more standard or well-studied assumptions" as an open problem. Pearl's floating-point variant introduces a further "quantized-subspace hardness" assumption. ^{22 23}

  Open question · Open question. On the record

Not yet demonstrated

Proposed Whole-workload recomputation (reproducible packets) and Proposed Proofs of useful work for capacity accounting

Mechanisms on the map that are not in the proposal. Pointers, not recommendations. ?

• Proposed Hardware-enabled guarantees (flexHEG) and guarantee processors Add
  • Bears on the open significant failure “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.
• Operational use Deterministic and bit-exact inference Add
  • Whole-workload recomputation (reproducible packets) waits on it. Workloads are not reproducible by default, and achieving reproducibility may cost performance.
• Operational use Hardware-attested weight binding Add
  • Safeguard attestation waits on it. Safeguard evidence must be bound to the model actually served, which depends on model-identity attestation.
• Operational use TEE remote attestation for AI workloads Add
  • 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.
• Proposed Network taps and certifiers Add
  • Whole-workload recomputation (reproducible packets) waits on it. All traffic must reach the recomputation server via network taps, and the server's integrity is critical.

Missing prerequisites

• Operational use TEE remote attestation for AI workloads needed by Safeguard attestation Add
• Operational use Hardware-attested weight binding needed by Safeguard attestation Add
• Operational use Deterministic and bit-exact inference needed by Whole-workload recomputation (reproducible packets) Add
• Proposed Network taps and certifiers needed by Whole-workload recomputation (reproducible packets) Add

Blockers

12 blockers recorded

• 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}
  • 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 25}
  • 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 evidence must be bound to the model actually served, which depends on model-identity attestation. Evidence binding. Waits on Hardware-attested weight binding ^{25 26}
  • 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}
• Whole-workload recomputation (reproducible packets)
  • Workloads are not reproducible by default, and achieving reproducibility may cost performance. Performance & compatibility. Waits on Deterministic and bit-exact inference ¹⁴
  • Network packets are not individually reproducible by default; making them so may need considerable software, firmware and hardware work. Amodo rates this 'not on track'. Performance & compatibility ¹⁷
  • All traffic must reach the recomputation server via network taps, and the server's integrity is critical. Hardware trust. Waits on Network taps and certifiers ^{14 17}
  • Recomputing training steps needs checkpoints: writing one at every step would cost more than 100% overhead, so Amodo's design needs a spare data-parallel replica that tracks the weights instead. Performance & compatibility ¹⁵
• Proofs of useful work for capacity accounting
  • Bounding spare capacity needs a credible estimate of the compute available to the actor, including third-party access. Capacity bounds ²⁰
  • Proofs of work cannot find facilities that were never declared. Coverage & hidden compute ²⁰
  • As of September 2026 no implementation, demonstration or independent evaluation of proofs of work for capacity bounding has been published. Adversarial validation

From the family or selected implementation's record. ?

Model weights

Depends on the design for Safeguard attestation, Whole-workload recomputation (reproducible packets) and Proofs of useful work for capacity accounting.

Inputs and outputs

Depends on the design for Safeguard attestation, Whole-workload recomputation (reproducible packets) and Proofs of useful work for capacity accounting.

Training data

Depends on the design for Whole-workload recomputation (reproducible packets).

Not involved: Safeguard attestation and Proofs of useful work for capacity accounting.

Safeguard attestation

None on the map

Whole-workload recomputation (reproducible packets)

• Proposed AI 2040 inference-only verification stack Proposed architecture, AI Futures Project

Proofs of useful work for capacity accounting

• Operational use Pearl proof-of-useful-work blockchain Open-source project, Pearl Research Labs

1. Proof-of-Guardrail in AI Agents and What (Not) to Trust from It, X. Jin et al. (2026). Original
2. Verifiable-ClawGuard: proof-of-guardrail reference code, SaharaLabsAI (2026). Original
3. Safety Without Compromising on Privacy, D. McCann-Sayles et al. (2026). Original
4. PAL*M: Property Attestation for Large Generative Models, P. Chantasantitam et al. (2026). Original
5. Enabling Verifiably-Scoped Monitoring through Large Language Models and Trusted Compute, B. Penchas et al. (2026). Original
6. Auditor-in-a-Box: Tools for Third-Party Auditing, R. Rinberg & B. Penchas (2026). Original
7. TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition, J. Chuang et al. (2026). Original
8. DDRop: Active Memory Interposer Attacks on Confidential VMs by Dropping DDR5 Writes, J. De Meulemeester et al. (2026). Original
9. On TEEs for Privacy-Preserving Monitoring in AI Governance, Gloria Z (2026). Original
10. Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing, J. De Meulemeester et al. (2026). Original
11. RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP, B. Schlüter & S. Shinde (2025). Original
12. SEV-SNP RMP Initialization Vulnerability (AMD-SB-3020), AMD (2025). Original
13. A System Overview for Near-Term, Low-Trust AI Compute Verification, N. Cankaya (2026). Original
14. Verification Plan, R. Dean (2026). Original
15. Example Schemes for Verifying High-Stakes AI Agreements, Amodo Design (2026). Original
16. Scaling Recomputation Inference Verification, Amodo Design (2026). Original
17. AI 2040 Plan A — Verification SITREP, Amodo Design (2026). Original
18. Get Involved in Verification, AI Futures Project (2026). Original
19. Proof-of-Learning is Currently More Broken Than You Think, C. Fang et al. (2023). Original
20. Pacing AI Requires Proof, Attestable (2026). Original
21. Mechanisms to Verify International Agreements About AI Development, A. Scher & L. Thiergart (2025). Original
22. Proofs of Useful Work from Arbitrary Matrix Multiplication, I. Komargodski & O. Weinstein (2025). Original
23. Pearl Floating Point Scheme Specification, Pearl Research Team (2026). Original
24. pearl: Monorepo for the Pearl network, Pearl Research Labs (2026). Original
25. Attestable Audits: Verifiable AI Safety Benchmarks Using Trusted Execution Environments, C. Schnabl et al. (2025). Original
26. How Tinfoil Proves Exactly What Model Is Running, Tinfoil Team (2026). Original