Two Minute Papers, the YouTube channel that explains research papers for a general audience, has picked up DeepMind's AlphaProof Code, and the paper behind it deserves the attention. The headline claim is that AI agents proved key security properties of Signal's protocol not on a simplified model, but on the machine code that actually runs on phones. For anyone who relies on Signal, WhatsApp or Google Messages, that is the level at which real bugs tend to hide.
The paper is more precise than the coverage. The target was libsignal, the reference implementation, written in Rust and compiled with the standard compiler to AArch64 machine code, which was loaded into Lean alongside a formal model of the processor. Agents produced about 6.5 million lines of machine-checked proof, resting on about 26,000 lines of trusted specification and processor semantics. The proofs cover the post-quantum PQXDH handshake and the Triple Ratchet, establishing forward secrecy, authentication, post-compromise security and handshake secrecy. DeepMind's blog says the work took four weeks, with humans reviewing every specification and about 1% of the codebase that agents flagged.
The design is what makes the claim believable. The prover agents are treated as untrusted. A gatekeeper agent accepts a proof only if Lean's kernel checks it and a comparator confirms it proves exactly a held-out copy of the approved specification, so an agent cannot quietly weaken the goal. For comparison, the paper notes that verifying the seL4 microkernel took twenty person-years and the CompCert compiler six, both written with verification in mind.
The same pattern is reaching ordinary developer tools. Our review of Lean LSP MCP covers a server that gives an agent Lean's proof state and errors so it can write proofs the checker accepts, and the agents here ran on Gemini 4 Carbon. The lesson for anyone using AI on code that matters is to put a checker that cannot be argued with between the model and the result.
The limits are written into the paper. The results trust Lean's kernel, the security of the underlying cryptographic primitives and the behaviour of some routines the code calls. A proof covers only what the specification says, so a gap in those 26,000 trusted lines would be a gap in the guarantee. The artefacts are open for others to check, and that independent scrutiny has not yet happened.