Google DeepMind has used human experts and AI agents to formally verify libsignal, the reference implementation of the Signal protocol, and the project is notable for its scale. The agents produced about 6.5 million lines of Lean proofs, and the Lean proof assistant accepted or rejected each one. The work covers core security guarantees for code behind a protocol that also runs in WhatsApp and Google Messages, and Google is publishing the specifications and proofs for outside review.
A Formal Proof at Unusual Scale
Formal verification means using mathematics to show that software behaves as its specification says, for every possible input rather than a sample of test cases. It has historically been reserved for the most critical systems because it demands specialists and long timelines. Researchers involved in the project say that five people completed the proof work in four weeks. Specialists have traditionally needed years for comparable efforts.
The AI systems did the bulk of the proof writing. Carbon-based agents, running on Google's Gemini 4 Carbon model, generated the roughly 6.5 million lines of Lean code. The key design choice is that the checker does not trust the output. Lean rejects any invalid proof, so an AI can propose thousands of attempts and only the valid ones survive.
What Was Proven
The libsignal work targets three properties. Forward secrecy means that past messages stay protected even if long-term keys are later compromised. Post-compromise security means that a session can recover its protection after an attacker has temporarily gained access. Authentication means each party can confirm who it is communicating with. Each is a central promise of the Signal protocol.
One detail stands out. Most protocol verification examines only the design, meaning the abstract description of how the protocol should work. Google says these guarantees hold for the compiled machine code, which is what actually runs on a device. The gap between a verified design and a verified binary is where many real bugs hide, so that difference is significant.
People also remain central. Humans wrote the specifications that define what must be proven, working with agents running on Carbon and Anthropic's Claude Opus 5.5 to draft specifications and proofs. The specification is the hardest part to get right, because a proof is only as meaningful as the claim it checks.
Testing the Method
To check that the approach can catch real problems, the team reinserted two old, already-patched libsignal bugs into the code and proved that those builds break the security guarantees. The method flagged the flaws, which suggests that the proofs are sensitive to genuine errors rather than passing everything.
That kind of validation is what separates a demonstration from a credible research result. A verification effort that only confirms correct code has not shown much. One that reproduces known failures has shown that it can fail when it should.
The Limits
The scope is narrower than some headlines suggest. The results cover Google's own build of libsignal, run through a small command-line wrapper, and they do not extend to Signal's own apps. Side channels, which are attacks that observe timing or other physical leakage rather than the logic itself, were excluded from parts of the analysis. One commentary piece noted that at least one headline framed the work as proving Signal's encryption works, which overstates what was checked.
These limits do not diminish the achievement. They define what has been established, and they mark the next steps for security teams that want to extend the approach to their own systems.
Reaction From the Field
Signal's chief technology officer, Ehren Kret, said the work "gives us even greater confidence in our code's privacy guarantees." Researchers on the project made a broader claim: "AI can make formal verification, historically too expensive for most software, practical for real-world systems." That is an ambitious statement, and it will be tested as other teams try similar projects.
Why It Matters
AI-written code is spreading quickly, and the central question for security teams is how to trust it. Testing samples inputs and cannot prove absence of bugs. Formal proofs offer a different kind of assurance, one that does not depend on trusting the model that wrote the code. If that method becomes cheaper, it could change how critical software is reviewed.
The shift also moves the bottleneck. Writing proofs is increasingly a machine task, while writing correct specifications remains a human one. Teams adopting this approach should treat the specification as the most important artifact, because that is where errors hide and where review effort should concentrate.
