DeepMind takes AI-generated proofs down to Signal’s machine code

Google DeepMind has used AI agents to produce machine-checked proofs for selected security properties of Signal’s cryptographic implementation, extending formal verification from a mathematical protocol model down to compiled instructions.

The 10 November AlphaProof Code announcement describes a substantial research result. Its scope is also specific: a command-line harness built around libsignal, rather than the complete Signal mobile or desktop applications. The distinction determines what users and developers can reasonably conclude from it.

What has actually been checked

The current technical artifact identifies libsignal-protocol v0.105.4 and SPQR v1.6.0, compiled for AArch64 Linux. It covers the harness’s session-initialisation, send and receive operations. Key generation is outside the verified interface.

That reaches below the level of source-code review. The researchers connect security arguments to the behaviour of a compiled executable, so an argument about an idealised protocol is not the final stopping point. The authors report approximately 6.5 million lines of Lean proof code. The volume describes the work produced, not an independent measure of how secure every deployment is.

Formal verification asks whether a precisely stated property follows from a model and its assumptions. Testing instead observes selected executions. A proof can cover cases that a test suite never exercises, but it can still answer the wrong question if its specification or environmental assumptions do not match the system people actually use.

AI writes the proofs; people define the claim

AlphaProof Code separates proof generation from proof checking. DeepMind says Gemini 4 Carbon agents generated the proof code, while Lean checked the resulting formal arguments. The model’s confidence is therefore not the acceptance criterion: a proof has to satisfy the checker.

The research account describes five researchers working over four weeks, with agents running continuously on their workstations. People selected the scope, developed and reviewed specifications, guided strategy and examined issues raised during the work. Gemini 4 Carbon and Claude Opus 5.5 also assisted specification drafting and review. This was a supervised research effort, not an unattended model certifying a product.

The useful development is the division of labour. If agents can shoulder much of the labour-intensive proof construction, specialists can spend more time deciding what must be proved and whether the assumptions are defensible. The reported four-week effort is a case study, not a controlled measurement of how much faster every verification project will become.

The trust boundary is part of the result

The paper identifies roughly 26,000 lines of trusted specification and instruction-set code, alongside other assumptions. The proof depends on Lean’s kernel, the security models and the machine/environment model. Some cryptographic routines are represented by contracts rather than proofs of their implementations. Proving the surrounding program under those contracts does not independently verify every primitive it calls.

There are substantial exclusions. The work does not verify Signal’s whole application, multi-device state or side-channel resistance. Its computational security theorem does not establish security against quantum attackers. A symbolic handshake result addresses a future quantum attacker under its idealisations, but the ratchet result does not establish SPQR’s post-quantum healing guarantee.

Even the quantitative security claims have a limited useful range. The authors state that their bounds become vacuous for some large message-and-session configurations. That means the bound stops providing a meaningful guarantee there; it does not demonstrate that an attack succeeds.

These details matter when deciding whether the technique transfers to another codebase. Engineers need to compare the proven interface and assumptions with their own deployment, rather than treating a successful proof as a universal security badge.

Old bugs, deliberately put back

The researchers also reintroduced two previously fixed libsignal bugs into isolated versions of the code, recompiled them and produced machine-checked disproofs of the symbolic security theorem. That is evidence that the formal setup can distinguish those flawed variants from the verified one. It is not a report of two newly discovered vulnerabilities in current Signal releases.

What developers can inspect now

The public repository includes specifications, proofs, the harness, build instructions and checking tools. Its default licence is Apache 2.0, with third-party and file-specific exceptions, including libsignal’s AGPL-3.0-only code. Open proof artifacts should not be confused with released model weights or a generally available AlphaProof Code service.

Sulat has reviewed the published materials, not independently rebuilt the proof suite.

The next practical test is reproducibility and transfer: whether other teams can check the artifacts, identify mismatches between a model and a deployment, and repeat the approach on different software. For background on why a small checker can validate much larger AI-generated arguments, see Sulat’s earlier coverage of Lean and formal verification.

Photo: Anthony Quintano, “Google at the 2012 Democratic National Convention North Carolina”, captured 6 September 2012. CC BY 2.0. Resized and cropped. Historical company-identification photograph, not the AlphaProof Code launch; no endorsement implied.