AlphaProof Code Verification Signal: Have AI Write Proofs, Then Have Machines Verify Them

Even if software passes testing, it may still contain vulnerabilities that were not detected during testing. This vulnerability is particularly dangerous for encrypted communications: just because a protocol holds true in a research paper does not mean that, once it is compiled and runs on a device, every step will fulfill the original security guarantees.

On November 10, 2026, Google DeepMind released AlphaProof Code, which uses AI agents for the formal verification of an implementation of the Signal protocol. Its task is very specific: first, it identifies the security properties that need to be guaranteed; second, it writes mathematical proofs demonstrating that the code satisfies these properties; and finally, it submits the proofs to a verifier for inspection.An Introduction to DeepMindPosition this work as software security research that delves into the practical implementation layer.

Which layer has the verification reached?

This study focuses on libsignal, the reference implementation of the Signal protocol. The team compiled the Rust code into AArch64 machine code, described the behavior of processor instructions in Lean, and linked the security objectives of the protocol layer to the execution behavior of specific builds. The paper covers the PQXDH handshake and Triple Ratchet, discussing properties such as forward secrecy, authentication, post-compromise security, and handshake secrecy. The approximately 6.5 million lines of Lean proof code serve as a measure of the scale of this project. For specific definitions and conditions of applicability, seeTechnical Papers.

You can think of the challenge here as the relationship between the “design diagram” and the “construction result.” The design diagram illustrates how the door lock is supposed to work, but the actual assembly might result in incorrect wiring. Verifying the protocol design only addresses whether the logic depicted in the diagram is sound; it is only by moving on to the implementation layer that we can check whether the program has deviated from the diagram during translation, state updates, or exception handling.

AI is responsible for finding evidence—but who decides whether the evidence is correct?

The workflow of AlphaProof Code is as follows: humans and agents collaborate to write formal specifications, which are then reviewed by experts; the proof agent attempts to construct a derivation; and Lean verifies the submitted proof. The team has also established a verification mechanism to ensure that the proofs correspond exactly to the approved specifications. This distinction is crucial, as it prevents the system from quietly substituting difficult-to-achieve goals with easier-to-achieve ones.

From an engineering perspective, AI handles the search and organizational aspects of the derivation here. It may propose incorrect paths and may fail repeatedly; only results that pass verification are accepted. Compared to having a model read a piece of code and then issue a judgment that it “should be safe,” this process leaves behind verifiable outputs. However, humans still need to determine whether the specifications have omitted any issues of genuine concern.

DeepMind stated that this round of validation took four weeks. The team also reintroduced two previously fixed historical defects into an isolated version to verify whether the system could demonstrate that the defective versions were unsafe. This is a valuable form of reverse testing: a validation process that merely yields a “pass” result is unlikely to be convincing. The timeframe and experimental results were disclosed by the research team; they cannot be directly extrapolated to imply that all projects will achieve the same level of efficiency.

“Proof of validity” has clear boundaries

The most common misinterpretation is to extrapolate the findings to claim that “the entire Signal application has been proven to be absolutely secure.” The paper explicitly specifies the build and runtime environments as well as the attack scenarios. Some conclusions rely on assumptions regarding underlying cryptographic primitives and environmental behavior; side channels are not covered by the relevant proofs, and the computational security section does not provide guarantees against quantum attackers. Practical scenarios, such as multi-device states, have not been fully accounted for.

Therefore, risks such as smartphones being taken over by malware, users falling victim to phishing, and data leaks from operating systems cannot be eliminated entirely by this result alone. The guarantees provided by formal verification are as specific as the objects it examines and the conditions it specifies. When evaluating this type of research, readers should consider both “what has been proven” and “what has been assumed.”

The next thing to watch is maintenance costs.

The long-term value of this work may become apparent after software updates. If dependencies, compilers, or protocol implementations are changed tomorrow for a build that passed verification today, we’ll need to confirm which parts are still covered by the old proofs. The ability to continuously rerun tests, identify invalid assumptions, and focus manual reviews on the parts that have actually changed will determine whether this approach is suitable for daily development.

For engineering teams, a practical starting point is to first select modules with clearly defined boundaries and high costs of error, specify their inputs, state transitions, and safety goals, and then discuss verification tools. For systems where even the requirements are vague, increasing proof-computing power does not automatically compensate for the lack of requirements. The insight provided by AlphaProof Code is this: as AI takes on more and more coding tasks, we can also require it to produce evidence that is more rigorous than mere textual explanations.