Google DeepMind announced on November 10, 2026, that its AlphaProof Code framework had formally verified key security properties of the compiled code behind Signal’s core cryptographic protocol. The project combined human-approved specifications, AI-generated proofs and checks by the Lean theorem prover. Google released a technical paper and verification artifacts for inspection.
The paper reports about 6.5 million lines of machine-checked Lean proof code covering parts of libsignal, Signal’s reference protocol implementation. Google says the verification took four weeks, compared with years of expert work using earlier methods. That timeline and the project’s claims of historical novelty come from the researchers; this article analyzes the published evidence without independently reproducing the checks.
The consequential detail is where the proofs connect to the software: compiled AArch64 machine code. That brings the argument closer to the implementation people depend on, while leaving specific assumptions and boundaries that matter just as much as the headline.
What AlphaProof Code Proved
The proofs cover Signal’s PQXDH handshake and Triple Ratchet. The handshake establishes a secure session, while the ratchet mechanisms evolve cryptographic state as messaging continues.
The paper identifies four security properties. In plain language, their goals are:
| Property | What it means |
|---|---|
| Forward secrecy | Compromising current secret state should not expose protected earlier messages. |
| Authentication | The protocol should provide the specified assurances about who is participating in a session. |
| Post-compromise security | Message protection can recover after a temporary compromise, under the model’s recovery conditions. |
| Handshake secrecy | The session-establishment process should keep its resulting secrets protected under the specified threat model. |
These are summaries, not replacements for the formal definitions. The exact statements determine which adversary capabilities, compromise events and conditions the proofs address. The researchers provide those statements through the paper and browsable Lean development.
The released repository identifies the software as libsignal v0.105.4 with spqr v1.6.0, compiled for AArch64, the 64-bit Arm instruction-set architecture. It describes the verification target as the compiled library in a command-line harness, “with hooked cryptographic primitives.” Those hooks model certain operations through specified contracts, making them an important part of the proof’s boundary. See the repository overview.
This scope does not make Signal bug-free. It establishes specified properties for the modeled implementation and execution environment, with stated assumptions. It is not a certification of the entire messaging app, every platform build, future releases or the operating system beneath it.
How Humans, AI Agents and Lean Divide the Work
AlphaProof Code separates deciding what security should mean from proving that the executable satisfies that definition.
According to Google’s announcement, researchers worked with models to translate Signal’s security goals into mathematical specifications, and human experts reviewed every specification. Agents powered by Gemini Carbon then generated the proofs.
The technical paper describes a more detailed workflow:
- Write and approve the specification. A specification-writing agent works with a human user, drawing on security models and properties from the literature. Reviewer agents critique drafts before approval.
- Compile the implementation. The unmodified Rust code is compiled with the standard compiler. The executable is brought into Lean alongside a formal description of AArch64 behavior.
- Generate proofs. Autonomous prover agents attempt to establish the approved properties about that executable.
- Check the result. A gatekeeper accepts a proof only after Lean’s kernel checks it and a comparator confirms that it proves the held-out specification.
The framework also allows proposed amendments to specifications, subject to the configured approval policy or explicit human judgment. An impressive proof of an empty or incorrectly framed claim would offer little security value, and the paper’s workflow explicitly accounts for this problem.
Lean is the proof checker, not another language-model reviewer. Its kernel checks whether a proof follows the formal rules and establishes the stated theorem. An AI agent’s confidence or explanation cannot substitute for that check.
The comparator addresses another failure mode: proving something easier than the approved target. The repository says it compares headline theorems with trusted challenge statements, including their transitive definitions, and replays exported proofs in a fresh Lean kernel. It also checks that they use only the listed standard Lean axioms. Those checks are documented in the repository README.
I’d put more weight on this separation than on the six-million-line headline. Large output volume shows the scale of the development; checking the proof against a separately preserved target explains why that output deserves attention.
Google also says agent auditing highlighted about one percent of the codebase for additional human attention. That is the company’s reported review workflow, not a general finding that humans can safely inspect one percent of any security-critical project. Human approval of specifications remains central.
Why Checking Machine Code Matters
A protocol design can be secure while its implementation makes a consequential mistake. Formal reasoning about the design answers whether the modeled protocol provides a guarantee. Connecting that guarantee to compiled code addresses a further question: whether the implementation actually carries out the required behavior.
The authors position AlphaProof Code against earlier work on abstract protocol models, verification-friendly reimplementations, implementations modified to simplify verification, and narrower properties such as crash-freedom. They claim the first proofs connecting protocol-level security guarantees to the unmodified code of a widely used cryptographic protocol implementation. That is the researchers’ novelty claim, not an independently established historical finding here.
AArch64 semantics supply the bridge. They give Lean a mathematical account of what the relevant machine instructions do, allowing the proofs to reason about executable behavior.
A practical consequence follows from this choice: the build identity becomes part of the evidence. A proof about one executable cannot simply be carried over to a newly compiled binary without establishing the necessary connection.
The repository makes that dependency unusually visible. It pins Rust to version 1.98.1 and warns against overriding the pin because generated Lean material depends on the exact compiler output. It also supplies commands to build an AArch64 ELF executable, verify its SHA-256 pin and check the binary-level headline theorems. Those details connect the security claims to a reproducible artifact instead of an unspecified build.
Google performed a separate negative test by reintroducing two real, previously fixed bugs into an isolated version of the code. It says AlphaProof Code produced machine-checked proofs that both buggy versions were insecure. This is useful evidence that the framework could express and prove insecurity in those cases. Two such examples do not measure its ability to find every class of vulnerability. The experiment is described in the announcement.
The Assumptions Still Carry Security Weight
The paper reports roughly 26,000 lines of trusted specifications and AArch64 semantics beneath the much larger generated proof development. It also identifies trust in:
- Lean’s kernel, which checks the proofs.
- The specifications and machine semantics, which define the claims and executable behavior.
Frequently Asked Questions
3 questions
1Which Signal Version Was Verified?
The released artifacts identify libsignal v0.105.4 with spqr v1.6.0, compiled to AArch64 machine code in the documented harness.
