How Google DeepMind’s AlphaProof Code Verified Signal Encryption in Four Weeks

Google DeepMind says it used an AI-assisted verification framework to prove key security properties of the code behind Signal’s encryption. The work addresses a difficult question: whether protections described at the protocol level also hold for compiled implementation code. The company reports completing the verification process in four weeks, according to its November 10, 2026 announcement.

Aspect	Reported result
Framework	AlphaProof Code, a multi-agent formal verification framework
Target	Key security properties of libsignal at the machine-code level
Reported duration	Four weeks
Historical bug check	Two previously fixed bugs were reintroduced and their insecurity proved

What changed with AlphaProof Code?

In its technical paper dated November 10, 2026, the research team says it connected protocol-level security guarantees to the unmodified implementation of libsignal, the Signal protocol’s reference implementation. The distinction matters because a sound protocol design can still be implemented incorrectly; examining compiled code addresses a different layer from studying an abstract design alone.

Formal verification expresses a security claim precisely and establishes mathematically that the specified claim follows for the modeled software. That makes the statement being proved central to interpreting the result: a proof answers the question written into its specification, rather than every possible question about a product.

Google DeepMind’s result concerns particular properties of the cryptographic implementation under its stated assumptions. It is not a blanket proof that every Signal feature or deployment is secure. For teams considering AI and automation services, the project illustrates a potential role for agents in demanding engineering work where the result must be checked against a precise specification.

The researchers also report an additional check: when they reintroduced two historical, already fixed bugs into an isolated version of the code, the system produced machine-checked proofs that the altered versions were insecure. That result tests whether the chosen security statements can expose those particular mistakes; it is a distinct claim from the four-week verification of the correct implementation.

How AlphaProof Code turns AI output into checked proof

The framework divides verification into two connected jobs: defining the claim precisely and proving that the implementation satisfies it. Researchers approve specifications written in Lean, a language and proof system for expressing mathematical statements. Those specifications determine what the proof must establish; they are part of the foundation on which the result depends.

The next step connects those statements to the compiled program. Google DeepMind’s technical paper describes using semantics for AArch64 machine code: a formal account of what the processor instructions do. This lets the verification reason about implementation behavior at the machine-code level while relating it to higher-level security claims.

Where the agents and Lean each fit

Autonomous prover agents work on the formal proof obligations generated by that setup. Their output is Lean proof code, which must pass checking by Lean’s kernel. An agent can propose a proof, but a proposal that fails the kernel’s checks does not establish the theorem. The division gives the agents room to search for proof steps while placing acceptance behind a separate mechanical check.

That distinction also explains why a convincing explanation from an AI system is not enough for this workflow. The deliverable is a formal argument that Lean can check against a stated proposition. Its value depends on the proposition and machine-code model describing the behavior that researchers intend to examine.

Running the proof development

The public proof repository documents the project’s prerequisites and build process. One command it provides builds the Lean development:

lake build

For an engineering team considering where this approach fits, project consultation can help frame the verification target: which implementation behavior needs a precise claim, and where that claim belongs in the broader development workflow.

What the Signal proof actually covers

The verification focuses on two parts of libsignal: the PQXDH handshake and the Triple Ratchet. The handshake establishes shared key material when participants begin communicating; the ratchet then evolves keys as a conversation continues. Google DeepMind’s technical paper describes how the researchers specified security properties for these mechanisms and connected them to the implementation.

From handshake secrecy to recovery

The properties address different threats. Handshake secrecy concerns the confidentiality of material established during the initial exchange, while authentication concerns whether the protocol connects the intended participants. Forward secrecy limits what an attacker can learn about earlier communications after obtaining later key material. Post-compromise security concerns the ability to regain protection after a compromise, under the conditions stated in the model.

These are separate claims: evidence for one does not automatically establish the others. The project’s description of the proof identifies the protocol components and properties examined, giving readers a starting point for interpreting each result in its proper context.

Where the modeled boundary ends

The paper describes assumptions about cryptography, trusted contracts and the modeled environment. Those assumptions form part of the argument: a theorem about modeled behavior cannot by itself settle questions outside that model. The authors also identify post-quantum healing as a limitation and describe group messaging, sealed sender and server-side protocols as areas for possible future work.

For teams planning secure messaging features during application development, that boundary matters when assessing what evidence applies to their own design. A property established for the examined implementation and assumptions should be matched to the component and conditions in question, rather than treated as a finding about an entire application.

Why four weeks matters for formal verification

Google DeepMind reports that the Signal verification took four weeks. Its announcement presents the result as an example of AI agents helping produce proofs for complex software. The duration is the researchers’ reported result, not an independently established benchmark.

The technical paper places that timeline alongside earlier verification projects, reporting approximately twenty person-years for seL4 and six years for CompCert. Those figures describe different projects and measures of effort: person-years aggregate people’s work, while elapsed years measure calendar time. They therefore do not establish a direct speed comparison with the Signal project.

The practical question for a high-assurance team is whether the effort needed to formalize and prove a critical property is justified by the consequences of an implementation error. The project offers an example of applying autonomous proof search to that work; a team considering generative AI services would still need to define the verification task and assess the resources it requires.

What readers can inspect, build and reuse

The public code-verification repository contains the Lean development and describes the prerequisites for working with it, including pinned Lean and Rust toolchains. Its proof structure gives readers a way to trace formal statements and supporting artifacts through the development.

The repository licenses its code under Apache 2.0, while third-party libsignal material retains its own licensing terms. Anyone planning to reuse material should check the applicable license for the specific files involved. The repository also describes itself as a research project rather than an official Google product.

Public artifacts provide a concrete starting point for examining the work, but they are not the same as a documented hosted offering. The official materials describe no commercial plan, price, credit system or usage quota for AlphaProof Code.

Applying the evidence to another project

For teams considering mobile application development, the useful distinction is between adopting a software component and adopting evidence about its behavior. A proof can inform a decision only when the component, stated property and assumptions match the intended use.

That distinction also affects how the result should be communicated: a claim about a particular implementation property carries more meaning than a general label such as “verified encryption.”

Conclusion

The answer to how Google DeepMind’s AlphaProof Code verified Signal encryption in four weeks should be treated as evidence for the properties specified in the research, rather than universal certification of Signal or AI-written software.

Before citing or adopting the method, read the technical paper and inspect the public proof repository.