Mechanism · Memory wiping and proofs of secure erasure
Evidence & limits
On this page
R1Proposed for showing that no data from earlier work persists in memory the wipe reaches
ReadinessMedium confidence
The protocols are peer-reviewed and the AI use is proposed, but no public run covers the timed challenge phase on data-centre hardware.
Assessed use: showing that no data from earlier work persists in memory the wipe reaches
Rubric assessment
- R1 met: the AI 2040 plan proposes periodic memory wipes on inference units so that only verified outputs persist 1. Peer-reviewed protocols define proofs of secure erasure and their assumptions 2 3. The MIRI overview specifies filling memory with incompressible data and challenging random samples 4.
- R2 not met: complete protocols, with a separate verifier, have been reported end to end only on microcontrollers erasing 2–8 KB 8, and Bursuc et al. simulated a 32 KB erasure on a desktop computer 3. Amodo has run a Bursuc-style erasure on a Raspberry Pi 5 and benchmarked label generation on H200 and H100 GPUs, CPUs and NVMe drives 5 6. Its public code for the GPU-accelerated disk-wiping path runs on realistic hardware 7. But the repository excludes "the verifier, the RAM and GPU-HBM session code" 7, the notes report fill throughput rather than timed challenge rounds 5 6, and the GB200 figures are estimates scaled from component measurements 5 6. The fill alone does not make an erasure verifiable, so this code does not meet R2. The mechanism's implementations, AI 2040 inference-only verification stack and Low-trust AI compute verification system overview, are proposed architectures at R1.
Confidence is medium: the rating turns on the judgment that fill-path code without the challenge phase is not a working implementation of the mechanism.
Gaps to the next level
- A public end-to-end wipe of an accelerator server, covering fill and timed challenges by a separate verifier, for host memory, HBM and storage.
- Coverage of memory the wipe cannot reach: drive-controller DRAM, firmware stores, NICs, DPUs and switches, and the algorithm's own working memory.
- Adversarial evaluation in a data-centre setting, including remote-memory (RDMA) help during challenges.
Assessed 2026-09-25 against rubric v1.1.
Mechanism properties
| Threat model | Adversarial prover |
|---|---|
| Adversarial evaluation | Analysis |
| Hardware needed | None |
| Prover cooperation | Required |
| Confidentiality | Preserving |
Evidence
- Protocols. The core protocols are formally analysed 2 3. Bursuc et al. ran their prototype on a standard desktop computer and simulated the erasure of 32 KB, which took 0.25 seconds 3.
- Microcontroller comparison. Gil-Pons, Mauw and Trujillo-Rasua ran seven erasure protocols end to end on three IoT microcontrollers, erasing 2–8 KB with a laptop verifier over Bluetooth, and published their code 8. They found the protocols feasible, although slow devices may take several seconds, and that no protocol was best in every setting 8.
- First Amodo test. Amodo ran the algorithm on a Raspberry Pi 5, erasing its RAM and a connected SSD 5.
- Amodo's July 2026 analysis. Scaling measured GPU and CPU throughputs, with an assumed 1 ms round-trip time, gave 2,565 seconds (43 minutes) for the RAM and HBM of a GB200 tray 5. Drive writes slowed sharply after about 12 GiB, so Amodo estimated over 24 hours for a GB200 system with 15 TB of storage 5. Challenge-phase calculations were still to come 5.
- Amodo's September 2026 update. Amodo attributed the slowdown to consumer drives' fast write cache running out 6. Six GPUs wiping one fast drive reached 6 minutes 41 seconds per TB 6. Amodo now expects "~2.5 hours to wipe an NVL72 system's storage", using a B200 label rate estimated from its GPU benchmarks, and reports that erasure speed, not drive speed, is the bottleneck 6. Integrating the disk wipe into a full-system wipe, and memory wiping into a full verification scheme, is still to come 6.
- Public code. Amodo has published code for the disk-wiping path, which fills every sector of an NVMe drive with graph labels generated on NVIDIA GPUs 7. The repository excludes the verifier and the RAM and GPU-HBM session code 7.
Limitations
- Unreachable memory. SSD controller DRAM sits on a private bus that host commands cannot access 6. Amodo's code notes that overwriting by logical block address cannot reach over-provisioned or remapped blocks either 7. The optimized algorithm's 25 GiB of working memory is "supposedly wiped but isn't attested" 6. Amodo suggests fixes, such as wiping the HBM in several passes, but has not prototyped them 6. Amodo lists many other stores in a GB200 system and asks how network-switch memory could be wiped 5.
- Outside help. In data centres, remote memory round trips of about 1–2 µs compare with about 70–200 ns for local DRAM, which the MIRI overview puts at roughly a tenfold timing margin 4. Evasion by pre-staging data is closed only by unpredictable, capacity-filling challenges 4.
- Downtime. Filling a pod's volatile memory takes tens of minutes, and SSDs take hours 4.
- Residual gap. Memory between the erased region and full capacity could hold data 3. Bursuc et al. say that closing this gap needs future work 3.
Known flaws
Blockers
Wipes take time: tens of minutes for a pod's volatile memory and hours for SSDs, displacing work.
Timed challenges must exclude remote memory and other helpers.
All memory stores in a system must be inventoried and wiped at the same time.