AlphaProof Code verifies Signal properties in machine code. That is a precise claim
Lean checks the generated proofs, while the specification and threat model define the result’s limits.
Google DeepMind says AlphaProof Code has verified key security properties of Signal's cryptographic implementation at the machine-code level. The announcement is striking because it connects formal reasoning to compiled code, rather than stopping at an idealized description of how a protocol should work.
It is also a claim that needs a carefully drawn boundary. The technical paper covers properties of libsignal's PQXDH handshake and Triple Ratchet under specified models and assumptions. It does not certify every part of the Signal app, every device running it or every possible attack on a user's messages.
The proof is checked separately from the agent
AlphaProof Code uses a human-guided process to create formal specifications in Lean. Once a person has approved the specification, prover agents construct proof code. Lean's kernel checks whether those proofs establish the specified result.
This arrangement addresses a familiar weakness in AI-generated reasoning. A fluent explanation can be wrong while sounding complete. A machine-checkable proof must satisfy a separate checker. The system is not asking a reader to accept the agent's confidence as evidence that the software is secure.
However, the specification remains crucial. Proving the wrong property perfectly does not establish the property a user actually needs. The trusted definitions, the model of machine instructions and the assumptions about cryptographic components form the foundation on which the proof rests.
The paper reports around 6.5 million lines of checked Lean proof code supported by about 26,000 lines of trusted specifications and AArch64 semantics. The scale illustrates how much formal work was generated. It is not a score that can be compared directly with lines of application code or used to infer how many vulnerabilities were removed.
Compiled code closes an important gap
A protocol can be secure in an abstract model while an implementation fails to follow that model. Verifying machine code aims to connect the security argument to instructions that a processor actually executes. The paper's AArch64 scope is therefore substantive, not an incidental mention of an architecture.
The authors describe security properties including authentication, secrecy and recovery-related guarantees under the relevant threat models. These are meaningful properties of a messaging protocol, but their names should not be shortened into a general “unhackable” label.
The paper explicitly leaves side channels and some secrets in memory outside one of its modeled attacker scopes. It also explains limits around replay and the relationship between its ratchet theorems and post-quantum healing. Those qualifications are part of the result, not reasons to discard it. They show what the mathematical statement actually says.
A proof does not eliminate the surrounding system
Messages still pass through applications, operating systems and devices. A compromised endpoint can create risks outside the protocol property being proved. Likewise, an interface bug or an unsafe user action is not automatically covered by a theorem about a compiled cryptographic component.
The researchers also discuss tests involving reintroduced, previously fixed bugs. Such checks help demonstrate that the method distinguishes relevant incorrect behavior; they do not establish that a new live vulnerability was found in every case or that all possible mistakes are now excluded.
The important advance is a more inspectable kind of assurance for a difficult piece of real software. AI supplies much of the labor, while a formal checker supplies the acceptance rule. The enduring question is whether the approved statement captures the risk that matters. A checked proof earns confidence by being exact about that statement—not by expanding its conclusion beyond it.
