AlphaProof Code verifies Signal code, not every security claim
Google DeepMind’s AlphaProof Code is a useful answer to a difficult question: can AI help prove that real software does what its security design promises? In its November 10 announcement, Google describes human-guided agents verifying key properties of Signal’s cryptographic implementation. It is not a certificate that the entire messaging app is immune to attack.
The important change is what gets checked
Google says Gemini Carbon powered the proof work, with Lean checking the resulting proofs. Researchers decided and reviewed what the system should prove. The team reports a four-week verification effort and has released formal verification artifacts. That is different from asking a chatbot whether code looks secure: a convincing explanation is not the acceptance test.
The technical paper identifies the target as libsignal-protocol v0.105.4 with spqr v1.6.0, compiled for AArch64 Linux inside a command-line harness. About 6.5 million lines of checked Lean proofs rest on roughly 26,000 lines of trusted specifications and machine semantics. Human judgment has not disappeared; it has moved toward defining the claim and its assumptions.
Read the guarantee with its boundaries
| Evidence | What not to infer |
|---|---|
| Proofs connect specified security properties to compiled code. | Every platform build or the entire Signal application was verified. |
| Lean checks proof validity against the specification. | The specification, cryptographic assumptions and external contracts need no scrutiny. |
| The computational model has explicit exclusions. | It covers quantum attackers, multi-device state or every first-message scenario. |
The paper also warns that its computational bound becomes uninformative for multiple long sessions with many epochs. These limits matter because “formally verified” is incomplete without saying which property, implementation and threat model were verified.
The bug experiment was not a new Signal breach
Researchers reintroduced two previously fixed bugs into an isolated build and proved that the altered binaries violated their symbolic security theorem. This checks whether the specification can reject known mistakes. It does not report those bugs as newly discovered in production.
What developers can take from this
Before accepting any AI-generated security assurance, ask for three things: the exact build, the property being proved and the assumptions left outside the proof. A passing result is useful only when that combination matches the system you actually depend on.
For example, a proof about message confidentiality cannot, by itself, answer whether an account-recovery screen exposes personal data. Those are different questions. The practical advance here is stronger evidence for a defined question, not permission to stop testing everything else.
AlphaProof Code’s research artifacts are distinct from Gemini 4 Carbon’s paid API release. Buying model access does not give a project these proofs or reproduce the researchers’ verification work. ByteForward has reviewed the published explanation and paper, not independently rerun the proof development.
Featured image: official AlphaProof Code launch artwork, Google DeepMind. Used for editorial identification; no endorsement implied.
