Google DeepMind said on November 10, 2026 that a new system called AlphaProof Code helped formally verify key security properties of libsignal, the reference implementation behind the Signal protocol, at the machine-code level. That matters because formal verification has long been one of software security’s strongest but costliest tools. If AI can do more of the proof work without weakening the checking, the economics of high-assurance software could start to shift.
The useful question is not whether Signal is now unhackable. It is not, and DeepMind does not claim that. The real question is whether AI can make formal verification practical enough to become a repeatable part of how organizations ship security-sensitive code. The answer, based on the Google DeepMind announcement and its supporting materials, is that AlphaProof Code looks like a meaningful advance in proof production for a carefully bounded target. But it also suggests that the bottleneck may move, not disappear: from searching for proofs to deciding, auditing, and maintaining what gets proved.
The advance is about implementation, not just protocol theory
What DeepMind chose to verify is the crux of the story. The target is libsignal, not every app that uses Signal and not every component in the Signal ecosystem. The announced proofs cover the post-quantum PQXDH handshake and the Triple Ratchet, including forward secrecy, authentication, post-compromise security, and handshake secrecy as implemented in the reference code.
That implementation-level focus is why the work stands out. Formal verification often proves properties of a protocol description on paper, or of a relatively small critical component, while leaving a large gap between the model and the software people actually run. In the technical paper, DeepMind describes AlphaProof Code as a multi-agent system with a human-guided specification agent and autonomous prover agents. Human researchers selected and reviewed the security specifications. Agents powered by Gemini Carbon then generated roughly 6.5 million lines of Lean proof code.
The trust story matters as much as the model architecture. The AI output is not accepted on faith. DeepMind says the proofs count only when Lean’s kernel checks them against the approved specification. The system also relies on about 26,000 lines of trusted specifications and AArch64 machine-code semantics. In other words, the machine-checked part is real, but it sits on top of a smaller trusted foundation that still has to be chosen and maintained by people.
That division of labor is the best reason to take the result seriously. It is not just another claim that an AI assistant can write security code faster. It is a claim that AI agents can help search a vast proof space, while a proof assistant’s kernel mechanically decides whether the result is valid. Independent coverage from WIRED described the work as a landmark for both cryptography and AI, and that feels directionally right given how rarely formal verification reaches a widely deployed cryptographic implementation at this depth.
Where the assurance boundary really sits
The easiest mistake is to treat a machine-checked proof as a universal security verdict. Formal verification is stronger than ordinary testing for the properties that are actually specified, because it checks a mathematical proof rather than sampling inputs. But its rigor is scoped. A perfectly checked proof can still be incomplete if the model omits an attack surface that later matters.
That is why AlphaProof Code should be read as a demonstration of assurance boundaries, not their disappearance. The announced work does not show that every libsignal build, platform, compiler path, memory-safety property, side-channel property, or deployment configuration is covered. It does not prove every dependency safe. It does not report a drop in real-world vulnerabilities or incidents. And it does not make claims about the entire Signal ecosystem.
This is where the 6.5 million-line figure can mislead. Those lines are proof artifacts, not 6.5 million lines of new application code and not a numeric security score. The more important number may be the much smaller trusted base: the approved specifications and machine-code semantics that define what the checker is allowed to conclude. If a security team chooses the wrong properties, or fails to update them as software and hardware evolve, the system can still produce a valid proof of something less useful than executives assume.
That governance problem is not incidental. It is the core business issue raised by this work. Humans still decide which guarantees matter, review the formal model, and own proof maintenance when code changes. In that sense, AI may lower the cost of proof search while raising the importance of specification discipline.
What this could change for software buyers and builders
If that cost reduction is large enough, the implications go beyond messaging apps. Formal methods have traditionally been reserved for a narrow slice of critical infrastructure because they are so labor-intensive. If AI agents can absorb more of the translation from security goals into proof search over large codebases, protocol maintainers, compiler teams, cloud vendors, banks, medical-device makers, and other high-assurance software producers could start using formal verification earlier in development instead of saving it for tiny, exceptional components.
That would change procurement and product expectations. Buyers may begin asking vendors not only whether a product was tested, but whether its critical components come with machine-checkable guarantees. Open-source projects could face new pressure to publish auditable proof artifacts. Security teams may need a sharper vocabulary for distinguishing tested code from formally verified code, and for explaining what sits outside the proof boundary.
The catch is that no one can price this shift yet. Public materials do not quantify how much time, compute, staffing, or human review it took to produce the libsignal result. They do not say how often the agents failed, how the proof behaves after routine libsignal changes, or whether the workflow scales to less structured applications and third-party dependencies. There is no independent replication or production-adoption case study establishing total cost.
So AlphaProof Code lands in an important middle ground. It looks more substantial than a marketing demo because the proof and code materials are public, the target is real software, and the checker is mechanical rather than trust-me AI. But it remains a single research project around one carefully chosen protocol implementation. The near-term consequence is not that AI has made software unhackable. It is that machine-checkable proofs now look more plausible as a supply-chain control for a narrow class of security-critical components—and that puts a premium on the less glamorous question businesses will have to answer next: what, exactly, are you proving, and who will keep proving it when the code changes?
By
By
By
By
By
By
