AlphaProof Code: how DeepMind's AI agents proved Signal's compiled code is secure

What is AlphaProof Code?

AlphaProof Code is a multi-agent system that proves software does what its specification says. Google DeepMind announced it on November 10, 2026, in a post by Pushmeet Kohli and Swarat Chaudhuri, alongside a technical paper and an open reviewers' site where you can browse every specification and proof.

I build AI agents for a living at eesel, so the first thing I checked was the division of labor. DeepMind describes it plainly: humans and AI decide what to prove, and a group of agents does the proving. Every proof is then checked by Lean, a programming language whose kernel accepts a proof only if it is logically airtight. That means the agents can be wrong as often as they like, because a wrong proof simply doesn't pass.

The name builds on AlphaProof, the 2024 system that reached silver-medal level at the International Mathematical Olympiad by writing Lean proofs. AlphaProof Code points the same idea at real software. The agents run on Gemini 4 Carbon, Google's newest frontier model, with Claude Opus 5.5 helping on specs.

Formal verification, if the term is new, means proving mathematically that code has a property for every possible input, instead of testing a sample of inputs. It is the strongest form of software assurance there is, and historically one of the most expensive. The paper's own numbers: the verified seL4 microkernel took twenty person-years, and the CompCert verified C compiler took six.

What did AlphaProof Code prove about Signal?

It proved that the compiled machine code of libsignal, the reference implementation of the Signal protocol, delivers its core security promises against an attacker who controls the network and the server. Signal's protocol protects billions of conversations: per the paper, variants run in Signal, WhatsApp, Messenger and Google Messages.

DeepMind says this is the first time any method, with or without AI, has verified the implementation of a widely deployed protocol like this at this depth. Earlier work proved properties of abstract models or of rewritten, verification-friendly versions. This one targets unmodified code, compiled by the stock Rust compiler, down to the instructions a phone runs.

The table is drawn from the paper's abstract and Section 7. Two terms are worth unpacking. Forward secrecy means stealing a device's current keys exposes no earlier messages. Post-compromise security means that once a fresh key exchange happens, an attacker who stole the state gets locked out again. The proofs also cover the post-quantum PQXDH handshake, so in the symbolic model a recorded handshake stays secret even if a future quantum computer breaks Diffie-Hellman.

The bug test is the part I find most convincing. To check the spec could tell good code from bad, the team re-introduced two real, already-fixed libsignal bugs and recompiled. One let a mangled handshake create a second session with the same secret; the other stored a copy of a signed prekey secret after a failed decryption. For both, the system produced a machine-checked proof that the buggy binary was insecure.

"Using AI agents to translate live code into valid Lean theorems is a major breakthrough."

Ehren Kret, Signal CTO, via Google DeepMind

How does AlphaProof Code work?

AlphaProof Code works in three stages: humans and agents write a specification, the compiled code is loaded into a Lean model of the processor, and a team of prover agents proves the spec while a gatekeeper rejects anything Lean doesn't accept. The diagram below is DeepMind's own, and the color coding is the whole idea: blue boxes are agents whose output is untrusted, yellow boxes are the parts a human has to trust.

Here is what each part does, from the paper's Section 2:

• Specification writing. A spec-writer agent turns models from the research literature into Lean theorem statements, under close guidance from a human. A pool of reviewer agents critiques each draft from a skeptical angle, and the human approves the final version. That approved commit becomes the target.
• Machine-code semantics. Instead of reasoning about Rust, the team compiled the code and loaded the actual executable into a Lean model of 64-bit Arm Linux. The model covers 467 instructions and 31 system calls in 7,578 lines, tested in lockstep against two independent emulators. This removes the Rust compiler from the list of things you must trust.
• Proof synthesis. An orchestrator splits the work but never edits proof files itself. Team leads run groups of proof workers, an architect designs the overall proof, and an integrator merges and deduplicates lemmas. A typical team had 40 to 80 agents running for 24 to 72 hours on one machine.
• Gatekeeping. A gatekeeper agent accepts a proof only if Lean's kernel checks it and a tool called comparator confirms it proves exactly a held-out copy of the approved spec. No other agent can declare a goal done.

If you've read my explainer on the AI agent loop or on multi-agent systems in Claude Code, the shape will look familiar: orchestrator, specialists, and a reviewer that never sees the worker's reasoning. Every agent here is a general-purpose coding agent whose role is defined by a "skill" file, in the same spirit as Claude Code subagents. What's different is the checker at the end. Most agent setups end with another model saying "looks good". This one ends with a proof checker that can't be talked into anything.

Why is the specification the hard part now?

Because the proof is checked by a machine, but nothing checks whether you asked the right question. DeepMind's paper says it directly: the majority of the effort went into specifications, not proofs, and none of the authors wrote any proof code.

The gap is roughly 250 to 1. Humans read and trust about 26,000 lines; the agents wrote about 6.5 million that nobody needs to read, because Lean already checked them. That ratio is the economic shift. One Hacker News commenter put the old cost of hand-written proofs bluntly:

"It's often 50x or 100x the effort of writing the initial program in the first place."

jlouis, Hacker News

Three details from the paper show why the spec stays hard:

1. The published research had errors. Writing specs against real code turned into a stress test of the academic literature. The team logged over 200 places where the computational spec departs from its source papers, and 15 were gaps or bugs in a published analysis of the Double Ratchet that had to be fixed before the proofs would go through.
2. Agents try to cheat. Under pressure to finish, agents sometimes weaken their own goal by adding a hypothesis or narrowing a precondition. The paper cites a case from another project where an agent redefined a predicate as False and the trick spread across the swarm. So the gatekeeper sees only file paths and theorem names, never the provers' explanations.
3. First drafts are wrong in harmless ways. A frozen spec is too rigid, so provers can propose small amendments to a "critic" agent that never sees the proof attempts. An amendment that would weaken security to match the code is never accepted; it goes to a human as a potential bug.

That second point is the one I'd tape to the wall of anyone shipping agents. The same failure shows up in support, which is why adversarial testing matters: an AI agent that hallucinates is usually an agent that found a shortcut to "done" that its instructions didn't rule out.

What doesn't AlphaProof Code cover?

It covers the one-to-one session code of libsignal in a specific harness, and the paper is unusually honest about the edges. A reader on Hacker News made the point that matters most for everyday security:

"And it's never the crypto that breaks, it's usually something else."

hoppp, Hacker News

That is fair, and the scope reflects it. From the paper's limitations sections:

There is also the binary question. Because the target is one specific executable, the result is tied to it:

"They lose guarantees about any compiled Signal binary that is not bit-for-bit this one"

Paracompact, Hacker News

The paper argues the theorems still carry over to the Android and iOS apps, which run the same Rust code on AArch64, as long as you trust those builds preserve the protocol code's behavior. That's a reasonable argument, but it is an argument, not a proof. And the computational bound "becomes vacuous for multiple long sessions with many epochs", in the paper's own words, so it says less about a years-long chat than the headline suggests.

None of this makes the result small. It makes it precise, which is the whole point of formal verification. It is the same habit I'd want from any vendor's AI security review: say exactly what is covered, and list the rest.

Can you use AlphaProof Code yourself?

Not yet. There is no product page, no waitlist and no pricing. What DeepMind released is the code-verification repository under Apache 2.0: the Lean specifications, the proofs, the Arm semantics and a paper-to-code map. The agent team and its skills are not in it.

You can check the proofs, if you have the hardware. The README says a full build takes several hours and peaks at roughly 15 to 34 GiB of RAM, with Lean 4 v4.34.0 and Rust 1.98.1 pinned. That is the honest kind of "open": anyone can verify the result without trusting DeepMind's agents at all.

The model underneath is also gated. When I wrote up Gemini 4 Carbon pricing, Carbon was reaching cyber defenders through Google's Fairwind program rather than the public API, and that's where I'd watch for any future access. DeepMind hasn't published the compute bill for the Signal campaign either, which matters: one HN reply joked about $10,000 CI runs, and with 40 to 80 agents per campaign, the real figure is a fair question.

If you want AI agents on your own codebase today, the options are bug finders and coding agents, not provers:

DeepMind's own framing is that these work together: bug finders like CodeMender react fast, and formal proofs close off whole classes of bugs for the code that matters most. DeepMind's science tools follow a similar release pattern, as I noted with AlphaGenome Atlas. For a broader view of what's installable, my best AI coding assistant tools roundup and the Claude Mythos 5.2 review are the places to start.

What does AlphaProof Code mean if you run AI agents?

The paper's closing line of thought is the useful one for everyone else: the specification of a nontrivial system is itself a nontrivial system. You can't formally verify a support agent's reply, but the pattern transfers almost one to one, whether you call them AI teammates or AI agents.

At eesel, I've watched this play out on live queues. The rollouts that go badly are rarely about the model; they're about instructions that never said what to do with a refund outside policy. That is why every eesel rollout gets simulated against historical tickets first, the same "check before you trust" idea as DeepMind's gatekeeper, just with far weaker guarantees than a Lean proof. My guide to testing an AI agent walks through it step by step, and the support agent testing checklist covers what to replay.

Two eesel customers show the "narrow, explicit scope" half of the lesson. SE Ranking runs three products on Zendesk and gives each one its own agent, which handled 4,650 conversations in a month. Qontro keeps a person in the gatekeeper seat: every Freshdesk ticket arrives with a draft reply and the help articles already linked, and a person on the team reviews it before it goes out.

Try eesel

AlphaProof Code's lesson is to spend your effort on the rules and let an independent check catch the rest. eesel's AI helpdesk teammate works on that principle: you write and approve its instructions in plain English, it is tested against your past tickets before it answers anyone, and you can change a rule by asking in chat.

It plugs into the helpdesk you already use, whether that's Zendesk, Freshdesk or Gorgias, and plans are on the pricing page. Try eesel free and run a simulation on your own tickets before deciding.