Google DeepMind announced AlphaProof Code on November 10, 2026, releasing mathematical proofs and checking materials for security properties of Signal’s encryption code. For security teams and technology buyers, the development offers evidence to inspect behind an AI-assisted security claim—not just a promise that the software is safe.
The result concerns a particular compiled build of libsignal, Signal’s encryption library, running inside a small command-line program. The technical report explicitly distinguishes that build from Signal’s own applications. The authors report proofs covering message secrecy, authenticity and protection before and after certain key compromises. It is not a certification of everything the messaging app does.
What a mathematical proof can tell you
Formal verification starts with a precise statement of what software must do, and the assumptions under which it must do it. A proof establishes that relationship. In DeepMind’s workflow, human experts review the statements and AI agents generate proofs that Lean, a mathematical proof-checking system, checks. The checker assesses whether the proof follows—not whether the chosen statement captures every protection a user needs.
For messaging, those statements address questions such as whether stealing a current encryption key exposes earlier messages, or whether later messages can regain protection after a compromise. Signal’s ratchet specification explains how the ratchet—the mechanism for changing message keys—supports those protections. Recovery depends on fresh secrets unavailable to the attacker; it does not mean messages stay private while someone retains control of a device.
The researchers report about 6.5 million lines of proof code, with a five-person team directing the work. DeepMind says the project took four weeks. That is elapsed project time, not a disclosed computing bill or a measured cost-saving comparison.
Where the guarantees stop
The project’s paper-to-code map identifies libsignal version 0.105.4 and an executable pinned by a cryptographic fingerprint. The practical implication is that build identity matters: a result about these exact program bytes cannot simply be transferred to another version, platform or app integration.
Some low-level cryptographic and environment routines are represented by assumed contracts—statements describing how they behave—rather than proofs of their implementations. The guarantee therefore depends on those routines meeting the stated assumptions.
There are also restrictions on the conversation being modelled. The symbolic binary proof covers two participants already set up with each other’s identity keys. It does not establish the security of first-contact identity checking. Its higher-level mathematical model has broader scope, so claims about that model should not silently become claims about the executable.
The report’s exclusions include multi-device state and side channels, such as information leaking through how a program executes. Its calculated bound on an attacker’s success can also become uninformative at large modelled scales. That is a limit of the mathematical assurance, not evidence that messages become unsafe after a particular count.
The two proof approaches answer different questions. A symbolic argument treats cryptographic operations as idealised building blocks; a computational argument relates an attacker’s chance of success to assumptions about the underlying cryptography. The computational documentation explicitly limits its borrowed security results to classical attackers, not quantum ones.
The symbolic work includes a secrecy guarantee for the initial key exchange against a future quantum attacker, but the report does not establish the ratchet’s post-quantum recovery after compromise. These results should not be compressed into a blanket claim that every part of Signal is proven quantum-safe.
Public proofs make scrutiny possible
The repository’s checking instructions describe comparing the main theorem statements and their dependent definitions with a fixed reference, then replaying the proofs in a fresh Lean checker. That helps separate two jobs: checking the proof and deciding whether the statement being proved is useful.
Published instructions make outside checking possible; they do not, by themselves, demonstrate a successful independent reproduction. Checking existing proofs is also different from repeating the AI process that generated them.
The repository labels the software as research rather than an official Google product. The release does not establish commercial customer access or pricing for AlphaProof Code.
What to ask before relying on the result
For a team evaluating this evidence, the practical questions follow from the documented build and proof scope:
Which build? Obtain the artifact revision and executable fingerprint, then establish how they relate to the software being deployed.
Which guarantee? Identify the exact property, attacker model and assumptions. A proof of one protection is not a substitute for another.
Which gaps? Compare the proof’s two-party setup and component boundaries with the intended deployment, including multi-device behaviour.
Which checking record? Request a record of the proof checks for that exact artifact. Keep it separate from the authors’ result and from an assessment of deployment relevance.
Choosing the right claim matters beyond cryptography. RohitAI’s guide to assessing AI-generated scientific models explores the distinction between matching evidence and explaining it. Empirical validation and mathematical proof are different methods, but both require care about what the result actually establishes.
For ordinary Signal users, this announcement is research evidence, not a new setting to switch on. For buyers and security teams, its value lies in the ability to inspect a precise claim—and determine whether that claim answers their own security question.