AI Verified Parts of Signal's Security. Does That Make It Unhackable?

On November 10, 2026, Google DeepMind announced AlphaProof Code, combining human expertise and AI agents to verify specific security properties in Signal's code. This is an interesting development in software security, but calling Signal “unhackable” would erase important boundaries around the work.

The useful questions are which properties were proved, which code was examined, and which assumptions must remain true.

What was announced

According to DeepMind's announcement, researchers used AI agents to prove security properties of Signal's protocol implementation. The technical project page describes work on libsignal down to machine code, with machine-checked proofs.

The object of the claim matters: particular properties of an examined implementation. This article does not independently reproduce the proofs or extend their guarantees to the entire application, users' devices, or related accounts.

How this differs from finding bugs

Ordinary testing tries selected inputs and checks whether the outputs meet expectations. Passing tests provide evidence that those examples work. They do not automatically cover every possible state.

Formal verification starts with a statement to guarantee and a model or specification that defines it. A proof connects an implementation to that statement under declared assumptions. The statement and assumptions are essential engineering work, rather than paperwork before running a tool.

Consider an invoice approval system. We could test ten examples showing that an ordinary employee cannot approve their own invoice. A stronger verification target would require that rule to hold across all modeled states. But if the business rule itself is wrong, proving that an implementation follows it will not fix the business problem.

Why the guarantee does not cover an entire service

A guarantee about cryptographic code does not by itself explain what happens when a user gives a login code to a scammer or loses control of a device. Those are different objects of assessment.

What business software teams can use

A business owner does not need a mathematical proof for every button. Start with the rules whose failure would have the greatest impact: separation between customers, payment approval, or preventing actions without authorization.

Ask the developer to express those rules in language you can review. Then choose a suitable combination of testing, review, and verification methods. “AI checked it” needs to become assessable evidence: which tests, which version, which findings, and who accepted the changes.

This is why I distinguish generating code from having a system ready for use. I discuss that in vibe coding and the continuing need for developers. For review points in an AI workflow, see where humans should still check the work.

If an important rule in your business application has no clear test, we can start by defining the behavior that needs to be guaranteed.

Sources checked November 10, 2026. The invoice example illustrates verification scope; it is not a finding from the Signal research.

Cover photo: Tyler on Unsplash, used under the Unsplash License. This is an illustrative stock photo, not documentation of the incident, featured product, or a test result.