Google DeepMind announced on November 10, 2026, that its AlphaProof Code framework had formally verified key security properties of Signal’s core cryptographic implementation. Human experts guided the work, Gemini Carbon agents generated the proofs, and the Lean proof assistant checked them.
DeepMind says the verification took four weeks, compressing work that would previously have required years of expert effort. Its technical paper reports about 6.5 million lines of Lean proof code, connecting protocol-level security guarantees to compiled code from libsignal, Signal’s reference protocol implementation. These are DeepMind’s reported results, not independently measured performance figures. (Announcement, technical paper)
The important distinction is what those proofs establish. This is a substantial assurance result for specified cryptographic behavior. It is not a certificate that every part of Signal, every supported platform, or every future release is free of bugs.
What AlphaProof Code Actually Proved
The technical paper identifies two covered protocol components: the PQXDH handshake and Triple Ratchet. The handshake establishes a secure session; the ratchet updates cryptographic state as communication progresses.
The proofs connect their security properties to AArch64 machine code, the 64-bit Arm instruction-set architecture. That is a much more concrete target than an abstract description of how an encrypted messaging protocol should work.
The paper names four established properties:
| Property | Plain-language purpose |
|---|---|
| Forward secrecy | Protect earlier messages when secret state is compromised later. |
| Authentication | Establish the identity-related guarantees defined by the protocol’s security model. |
| Post-compromise security | Allow message protection to recover after a temporary compromise, under the model’s recovery conditions. |
| Handshake secrecy | Protect the secret established during session setup under the specified adversary model. |
These descriptions explain the goals. The formal specifications define the exact conditions, permitted attacker capabilities, and guarantees. For example, post-compromise security should not be read as protection against an attacker who retains continuing access to a device.
A formal proof establishes that the modeled implementation satisfies its mathematical specification under the stated assumptions. Choosing a specification that captures the intended security promise is therefore a central part of the work.
That is why the human role matters. DeepMind says researchers worked with models to translate Signal’s security goals into formal specifications, with experts reviewing every specification before the proof work proceeded. (DeepMind announcement)
Why Proving Machine Code Is the Significant Step
A protocol can have a sound design while its implementation gets something wrong. Developers must turn mathematical operations into state management, branching logic, data representations, and executable instructions. A proof about an abstract protocol cannot automatically settle whether those implementation details preserve its guarantees.
DeepMind’s paper says earlier work covered abstract protocol models, verification-friendly reimplementations, implementations modified to simplify verification, or narrower properties such as crash-freedom. AlphaProof Code instead targets protocol-level security guarantees for an unmodified production implementation.
Its workflow compiles libsignal’s Rust code using the standard compiler, loads the executable into Lean, and reasons about its behavior using a formal description of AArch64 instructions. DeepMind describes the result as the first connection of this kind between protocol-level security guarantees and the unmodified code of a widely used cryptographic protocol implementation. That priority claim comes from the researchers. (Technical paper)
My view is that the executable target matters more than the headline proof-line count. Millions of generated lines show the scale of the proof work. Connecting a security theorem to the instructions a processor executes addresses a specific assurance gap between a correct design and a correct implementation.
The architecture also sets a boundary: an AArch64 executable proof should not automatically be treated as a proof of every build for every processor.
How Gemini Agents and Lean Divide the Work
AlphaProof Code combines a specification-writing process, autonomous prover agents, and a machine-checking gate. The AI proposes mathematical arguments; Lean determines whether those arguments are valid against the approved statement.
The paper’s workflow separates those responsibilities:
| Stage | What happens | Why it matters |
|---|---|---|
| Specification | An agent helps translate security goals and research models into Lean statements; reviewer agents critique drafts and a human approves them. | The theorem must describe the protection people actually want. |
| Executable modeling | The compiled program is loaded alongside formal AArch64 semantics. | The proof concerns executable behavior. |
| Proof generation | Autonomous agents construct Lean proofs of the approved properties. | Agents perform the labor-intensive mathematical work. |
| Acceptance | A gatekeeper requires Lean kernel checking and a comparison against a held-out specification. | A valid proof must also prove the intended statement. |
That last check is easy to overlook. An agent could produce a mathematically valid proof of an easier or irrelevant theorem. Comparing the result with a held-out specification helps prevent that mismatch.
The framework also allows provers to propose specification amendments if they encounter a vacuous or otherwise incorrect statement. Those changes require approval through the user-set policy or explicit judgment. Specification changes are therefore part of a controlled process, not something a proof agent can silently use to claim success.
The approximately 6.5 million generated proof lines rest on about 26,000 lines of trusted specifications and AArch64 semantics, according to the paper. Those numbers represent different responsibilities: proof steps are checked, while the trusted definitions establish what program behavior and security mean inside the system.
DeepMind also says agents audited the work and flagged roughly 1% of the codebase for further human attention. That reported review figure should not be confused with the size of the trusted specification layer. (Technical paper, announcement)
Lean reduces the need to trust an AI-generated argument. Human judgment remains essential in deciding whether the checked statement is useful and whether its model matches the intended system.
Two Reintroduced Bugs Tested the Framework
DeepMind reports a useful check beyond proving properties of the current implementation: researchers reintroduced two real, previously fixed bugs into an isolated version of Signal’s code.
For both modified versions, AlphaProof Code produced machine-checked proofs that the code was insecure. (DeepMind announcement)
This matters because a weak specification can be easy to satisfy while missing the behavior that makes software unsafe. Demonstrating that the framework can establish insecurity for known-bad variants provides evidence that it distinguishes at least those failures.
I would treat this as a meaningful check, with a bounded conclusion. Two reintroduced bugs support the system’s ability to reason about those cases. They cannot measure its coverage of every vulnerability class or establish that every important security goal was specified.
The reported result is also different from discovering two new vulnerabilities in the deployed release. These were previously fixed bugs deliberately restored for the experiment.
What Signal Users Should Take From the Result
The proof’s scope is libsignal’s covered cryptographic components and properties. It does not encompass the complete Signal application, the operating system, or every surrounding service.
Frequently Asked Questions
3 questions
1Does Lean Have to Trust Gemini’s Reasoning?
Lean checks the generated proofs against formal statements. An invalid proof should be rejected even if the AI presents it confidently. The result still depends on the trusted checker, definitions, and specifications.
