AlphaProof Code: What a Signal Proof Still Asks Humans to Trust

AI can write a proof without deciding whether the theorem captures the requirement people intended. DeepMind’s November 10 AlphaProof Code study reports verification of key libsignal security properties at the machine-code level. Its scope does not amount to a guarantee that the entire Signal application has no vulnerabilities.

A generated proof must pass a kernel

Section 2 separates human-guided specification writing, formal AArch64 semantics, and autonomous prover agents. Lean’s kernel must accept the resulting proof against the approved specification. A reviewer agent’s agreement is not the acceptance rule.

The conceptual path is an approved specification, proof generation, and kernel checking. This describes the paper’s structure; we did not run the proof checker. A valid proof of the wrong requirement still leaves the intended requirement unresolved.

Proof volume is different from the trusted base

Section 7 reports five people working over four weeks and about 6.5 million lines of Lean proof. It describes roughly 18,000 lines of repository definitions and specifications to read and trust, plus about 8,000 lines of AArch64 semantics. Line count is not a security score. The assumptions connecting the binary, its model, and its environment determine what follows from the proof.

The development connects execution of libsignal-cli to a Lean model, then lifts security-game results for that model to the machine code. Cryptographic primitive contracts and execution assumptions remain part of the review. Another build, operating system, or surrounding service does not automatically inherit the result.

Reintroducing bugs tests the specification’s reach

Section 6 reintroduces two previously fixed libsignal bugs and proves that the changed binaries violate the symbolic security theorems. This checks whether the specification distinguishes those faulty behaviors. It does not establish detection of every unknown vulnerability.

The purpose resembles injecting faults to check a test suite, but the evidence differs: here the result is a proof of violation of a particular security theorem. Tests observe executions on chosen inputs; formal verification addresses stated properties under explicit assumptions. Both require a defensible account of what was included.

Start with a state transition people can define

For an authorization component, a team might require that a revoked credential cannot perform a protected operation. Writing that requirement precisely forces decisions about revocation time, concurrent requests, and cached permissions. This is an editorial application example, not a workload verified by the Signal study.

A narrow, stable function with costly failures can justify this investment. Rapidly changing interface requirements need a separate maintenance-cost judgment. The practical contribution is a clearer boundary between properties humans approve and evidence machines check. Regression testing and operational observation still answer questions outside that boundary.