Google DeepMind Uses AI Agents to Prove Signal’s Encryption Down to the Machine Code

Google DeepMind said on Tuesday, November 10, 2026, that its artificial intelligence agents have produced a mathematical proof that the code behind Signal’s encryption actually does what it promises, checking the claim not against a design written on paper but against the compiled machine code that runs on real phones. The project, called AlphaProof Code, is an agentic framework built by DeepMind, and the team behind it says it is the first time a widely deployed cryptographic protocol has been formally verified at this depth, and the first time the actual implementation of such a protocol has been verified by any method at all. According to DeepMind, a team of five researchers spent four weeks working with the system, and the AI agents operating under human supervision generated more than six million lines of proof in the Lean proof language covering libsignal, the reference implementation of the Signal protocol. That is the same protocol that protects chats in Signal itself, and that also sits underneath messaging in Google Messages and, according to secondary coverage, WhatsApp, which means the result touches billions of private conversations. The work covers the two parts of the protocol that matter most in a one-to-one conversation: the post-quantum PQXDH handshake that sets up a conversation, and the Triple Ratchet that changes the encryption key for every message. DeepMind says the proof establishes four properties of that code: messages stay secret, the other side is who they claim to be, past messages stay secret even if a key leaks later, and a conversation recovers its security after a compromise. The announcement also comes with clear limits, which DeepMind and the coverage of the work have both stated plainly: the proof covers one-to-one sessions only, it applies to one specific version of the library, libsignal version 0.105.4, compiled for ARM devices inside a test harness, and it does not cover the full Signal app, the servers, group chats or the phone itself. This report sets out what DeepMind announced, how the system works, what was proved and what was not, drawing only on what DeepMind and the reporting of the announcement said, and flagging clearly where the facts are still unconfirmed. The DeepMind AlphaProof Code Signal encryption November 2026 announcement is the focus of this report.

1. What DeepMind Announced on November 10

On November 10, 2026, Google DeepMind published its announcement of AlphaProof Code alongside a technical paper titled “Formal Verification of Signal’s Protocol with Gemini”, and open-sourced the verification artifacts so that other researchers can inspect them. The announcement describes AlphaProof Code as an agentic framework for formal verification, a system in which AI agents do the painstaking work of building mathematical proofs about software, while human researchers guide the effort and a machine checker confirms every step. The headline result is a machine-checked proof about libsignal, the code library that implements the Signal protocol, and the claim DeepMind makes for it is unusually strong: this is the first time, by DeepMind’s own account, that the implementation of a widely deployed protocol like this has been formally verified by any method at all, with or without AI. That distinction matters, because it separates this work from the many earlier audits, reviews and paper-level proofs that have examined Signal’s design over the years. What DeepMind says is new here is not that Signal’s design was examined, but that the actual code was proved to match its promises, down to the instructions a processor executes. The announcement landed on November 10 and was widely covered on November 11, which is why it is the freshest technology story of the day, and why it fits a slot dated November 12.

1.1 A proof, not an audit

Most of the security work the public hears about takes the form of audits and code reviews, in which experts read through software, test it against a set of cases and report the flaws they find. Formal verification is a different kind of exercise altogether, and the difference is worth understanding, because it is the whole point of the DeepMind announcement. In formal verification, the goal is to prove with mathematics that a program does exactly what its specification says, for every possible input, instead of merely testing it on some cases and hoping the rest behave the same way. A test can show that a program works on the inputs it was tried on; a proof, if it is correct, shows that it works on all of them. That is a much stronger claim, and it is also a much harder one to make, which is why formal verification has traditionally been slow, expensive and confined to small, carefully chosen pieces of software. DeepMind’s announcement is notable precisely because it applies this technique to a piece of software that billions of people rely on every day, and because it says the AI agents did in four weeks what used to take expert teams years. The proof itself is written in Lean, a programming language that doubles as a strict proof checker, and every line of it was checked by Lean’s kernel, the small, trusted core that verifies proofs mechanically. That mechanical checking is what turns a claim into a proof: the agents can propose whatever they like, but nothing counts until the checker accepts it.

1.2 Why Signal was chosen

Signal was a deliberate choice, and the reasons for it are easy to see. The Signal protocol is the reference design for modern end-to-end encrypted messaging, and its code, libsignal, is the reference implementation of that design. It protects chats in the Signal app itself, it underpins messaging in Google Messages, and, according to secondary coverage of the announcement, the same protocol also sits underneath WhatsApp, which means the code DeepMind verified is connected, directly or by descent, to the private conversations of billions of people. That scale is what makes the result matter beyond the research community: a proof about a protocol used by a handful of specialists would be an academic achievement, but a proof about the protocol that carries so much of the world’s private messaging is a result with real-world weight. Signal is also a good target for verification for a technical reason: its security properties are well understood and precisely stated, which means there is a clear specification to prove the code against. The protocol’s promises are concrete — messages stay secret, the other side is who they claim to be, old messages stay safe even if a key leaks, and a conversation heals after a compromise — and each of those promises can be turned into a mathematical statement that a proof can address. DeepMind also had a practical reason to choose Signal: the library is open source, which meant the team could publish its artifacts openly and let anyone inspect the result. The full artifact set was released under the Apache 2.0 licence at the repository google-deepmind/code-verification, at a commit identified in the coverage as 808b4b7, so that independent researchers can examine exactly what was proved and how.

2. How AlphaProof Code Actually Works

AlphaProof Code is described by DeepMind as an agentic framework, which is a way of saying that it is not a single model answering a single question, but a team of AI agents working together on a long, structured task under human supervision. The agents are powered by Gemini, and in the coverage of the announcement the model is identified as Gemini 4 Carbon. The workflow, as described in the reporting, runs roughly like this: a human-guided agent writes a formal specification in Lean, a precise mathematical statement of what the code is supposed to do; the system then assesses the semantics of the machine code, working out what the compiled instructions actually do; and finally the agents construct a proof that the code satisfies the specification, with Lean’s kernel checking every step of that proof. The human role is central to the design: the researchers guide the agents, set the goals, check the direction of the work and decide what counts as a satisfactory result, while the agents do the vast, repetitive labour of building the proof itself. That division of labour is what makes the four-week timetable possible. A human team working alone would have had to write millions of lines of proof by hand, a task that would take years; the agents can generate that volume quickly, and the machine checker can verify it tirelessly, so the humans are freed to think about the hard parts — what to prove, and whether the proof is asking the right question.

2.1 Agents guided by people, checked by a machine

The most important thing to understand about AlphaProof Code is the chain of trust it relies on, because that chain is what separates a genuine proof from an impressive-looking output. The agents generate the proof, but they do not get to decide whether it is correct. That decision belongs to Lean’s kernel, a small and carefully trusted piece of software whose only job is to check proofs step by step and reject anything that does not follow the rules. If an agent makes a mistake, invents a step or skips a case, the kernel refuses the proof, and the work has to be redone. This is why the coverage of the announcement stresses that every proof was checked by Lean’s kernel, and why an independent count the day after the announcement found 7,528,293 lines of proof across 11,323 files, with zero instances of the word “sorry” in the headline proofs. In Lean, “sorry” is a placeholder that lets a proof be written with a gap in it, a way of saying “trust me on this step”, and a proof containing it is not a complete proof at all. Finding none of them in the headline proofs is a meaningful signal that the agents really did close every gap they opened. The human researchers sit above this machinery, guiding the agents and deciding what to prove, and the kernel sits below it, checking the result without favour. The agents themselves are the engine in the middle, doing the volume of work that neither humans nor checkers could do alone.

2.2 The Lean proof checker at the centre

Lean is a programming language and a proof assistant, and it has become one of the standard tools for this kind of work because its kernel is small enough to trust and strict enough to be useful. When DeepMind says the proofs are written in Lean, it means the agents produced formal statements in a language that a machine can check mechanically, with no room for the kind of ambiguity that creeps into ordinary language. The proof rests on a trusted base of about 26,000 lines, according to the coverage: roughly 18,000 lines of specification, rising to about 28,000 with documentation, plus about 8,000 lines of rules describing how AArch64 machine code behaves. That trusted base is the foundation everything else stands on, and it is small compared with the millions of lines of proof built on top of it, which is exactly how a trustworthy proof system is supposed to work: a small core that can be inspected carefully, and a large body of machine-checked reasoning that rests on it. The size of the trusted base is also a reminder of the limits of the result. The proof is only as good as the specification it proves and the machine-code rules it assumes, and if either of those contains an error, the proof could be formally correct and still miss something real. That is not a criticism of DeepMind’s work; it is a feature of formal verification itself, and it is why the coverage of the announcement has been careful to describe exactly what was proved and what was assumed.

3. What the Proof Covers: PQXDH and the Triple Ratchet

The proof covers two components of Signal’s cryptographic library, and both of them are parts of the protocol that every one-to-one conversation depends on. The first is the post-quantum PQXDH handshake, the procedure by which two phones agree on the keys they will use to talk to each other. The second is the Triple Ratchet, the mechanism that keeps changing those keys as the conversation goes on, so that each message is protected by a fresh key. Together, these two components are the heart of the protocol’s security: the handshake establishes trust at the start, and the ratchet maintains it over time. DeepMind’s announcement says the proofs show that the compiled code fulfils the key security properties for these two components, and the coverage of the work names four properties in particular: message confidentiality, which means messages stay secret; authentication, which means the other side is who they claim to be; forward secrecy, which means past messages stay secret even if a key leaks later; and post-compromise security, which means a conversation recovers its security after a compromise. A separate count in the coverage puts the total at ten symbolic theorems, including initiator and responder secrecy, authentication, and five corollaries of the first theorem of the PQXDH specification, but the four named properties are the ones that matter to ordinary users, because they are the promises that make encrypted messaging worth using at all.

3.1 The handshake that starts a conversation

Every encrypted conversation has to begin somewhere, and the beginning is the most delicate moment, because it is the moment when two phones that have never spoken before have to agree on a secret without letting anyone else learn it. That is the job of the handshake, and in Signal’s case the handshake is called PQXDH, which stands for post-quantum extended Diffie-Hellman. The “post-quantum” part of the name refers to a design choice made in anticipation of a future in which quantum computers might break the cryptography we use today: PQXDH mixes classical key agreement with a post-quantum key encapsulation mechanism, so that the handshake stays secure even if one of the two approaches is later broken. When two people start a conversation, their phones run this handshake to agree on the keys that will protect their messages, and the proof DeepMind produced covers exactly this step, showing that the compiled code performs the handshake as its specification promises. The properties proved for the handshake include handshake secrecy and handshake authentication, which together mean that the keys agreed during the handshake stay secret and that each side really is talking to the person they think they are talking to. That sounds abstract, but it is the foundation of everything that follows: if the handshake is wrong, nothing built on top of it can be trusted, and that is why verifying it matters so much.

3.2 The ratchet that rotates every key

Once a conversation is under way, the protocol does not rest on the keys agreed at the start. Instead, it uses a mechanism called a ratchet, which changes the encryption key with every message, so that each message is protected by a key that has never been used before and will never be used again. The name comes from the mechanical ratchet, a device that moves in one direction only and cannot be turned back, and the cryptographic version works the same way: the keys move forward through a chain of one-way steps, and knowing a later key does not reveal the earlier ones. In Signal’s design the mechanism is called the Triple Ratchet, because it combines three separate ratcheting steps, and it is this mechanism that gives the protocol two of its most important properties. The first is forward secrecy: because each message uses a fresh key derived from a one-way chain, an attacker who later steals a key cannot use it to read messages that were sent before the theft. The second is post-compromise security, sometimes called healing: because the ratchet keeps moving forward and mixing in fresh randomness, a conversation that has been compromised can recover its security over time, as new keys replace the ones that were exposed. DeepMind’s proof covers the Triple Ratchet alongside the handshake, showing that the compiled code performs these rotations as specified, and the coverage notes that the proof includes post-compromise security for the Triple Ratchet specifically, while the corresponding property for a newer component, the ML-KEM Braid, remains out of scope.

4. Four Weeks, Five Researchers and 6.5 Million Lines of Proof

The numbers attached to the announcement are striking, and they are worth examining carefully, because they are both the most impressive part of the story and the part most easily misunderstood. According to DeepMind, a team of five researchers spent four weeks working with AlphaProof Code, and the AI agents working under their supervision generated more than six million lines of Lean proof covering libsignal. A more precise count in the coverage puts the figure at about 6.5 million lines, and an independent count the day after the announcement found 7,528,293 lines across 11,323 files, a difference that reflects different ways of counting the same body of work, including generated files and supporting material. DeepMind says this is a job that used to take expert teams years, and the contrast is the point: formal verification of this depth has always been possible in principle, but it has been so slow and labour-intensive that it was rarely attempted on software of this size and importance. If AI agents can do the same work in weeks, then the economics of verification change completely, and code that was previously too large to verify becomes a realistic target. That is the broader claim behind the announcement, and it is why the story matters beyond Signal itself: the same technique could, in principle, be applied to other critical software, from operating systems to financial infrastructure, wherever the cost of a bug is high enough to justify the effort.

4.1 A job that used to take years

To understand why four weeks is remarkable, it helps to know how formal verification used to work. In the traditional approach, a team of specialists would spend months or years writing proofs by hand, working through the code line by line, stating each property in a formal language and then constructing, step by step, a mathematical argument that the code satisfies it. The work is slow because it is exacting: every case has to be covered, every assumption has to be stated, and every step has to be checked, and a single missed case can invalidate the whole effort. Famous verification projects of the past, such as the verification of operating system kernels or of cryptographic libraries, have taken years of effort from teams of experts, and they have usually covered much smaller pieces of code than libsignal. What AlphaProof Code changes is the division of labour. The agents take on the vast, repetitive work of generating proof steps, producing millions of lines at a speed no human team could match, while the human researchers concentrate on the parts that require judgement: deciding what to prove, writing the specification, guiding the agents when they get stuck, and checking that the result answers the right question. The machine checker then verifies the whole body of proof tirelessly, without getting bored or tired, and rejects anything that does not follow the rules. The four-week figure is therefore not a claim that verification has become easy; it is a claim that the bottleneck has moved, from the labour of writing proofs to the judgement of deciding what to prove.

4.2 What the numbers do and do not mean

The figure of 6.5 million lines of proof is impressive, but it is important to be clear about what it does and does not mean. It does not mean that libsignal itself is 6.5 million lines long; the library is far smaller than that. It means that proving things about the library required a very large amount of formal reasoning, because a proof has to spell out every step explicitly, including steps that a human reader would skip as obvious. A proof in Lean is verbose by design: it leaves nothing to the imagination, and that verbosity is what makes it checkable by a machine. Nor does the size of the proof mean that the verification is more trustworthy simply because it is bigger; a proof is trustworthy because it has been checked, not because it is long, and a short proof that passes the checker is worth more than a long one that does not. What the size does tell us is something about the scale of the task and the capacity of the agents: generating millions of lines of correct formal reasoning in four weeks is a capability that did not exist before, and it suggests that the approach can scale to larger targets. The independent count of 7,528,293 lines across 11,323 files, with zero “sorry” placeholders in the headline proofs, adds a useful check on DeepMind’s own numbers, and the fact that the artifacts were open-sourced means anyone can repeat that count. But the number that matters most is not the size of the proof; it is the list of properties proved and the boundary of what was covered, and that boundary is where the honest limits of the work lie.

5. Why Verifying the Compiled Code Matters

The most important technical claim in DeepMind’s announcement is also the easiest to overlook, because it sounds like a detail: the proof covers the compiled code, down to the exact instructions running on ARM devices. Most protocol proofs stop at the design on paper. They prove that the protocol, as described in its specification, has the properties it claims, and they say nothing about whether the code that implements the protocol actually follows the design. That leaves a gap, and the gap is where real-world failures live. Code can contain bugs that the design does not have; a compiler can translate a correct program into machine code that behaves differently from what the programmer intended; and optimisations, shortcuts and edge cases can all introduce differences between what was designed and what actually runs. DeepMind’s team did not verify the paper version. They verified the compiled code, and that is what makes the result different from the earlier proofs and audits of Signal’s design. The team compiled libsignal with the standard Rust compiler into 64-bit Arm machine code, known as AArch64, and proved the security properties against that compiled code, inside a small command-line test harness running on AArch64 Linux. That means the proof speaks about the instructions a processor actually executes, not about an idealised version of the program.

5.1 The gap between the paper and the phone

The gap between a protocol’s design and its implementation is one of the oldest problems in computer security, and it is the reason why a system can be theoretically sound and practically broken at the same time. A design is an idea, expressed in mathematics and words, and it can be proved correct in the abstract. An implementation is a piece of software, written by people, compiled by a compiler, and run on hardware that has its own quirks, and it can depart from the design in ways that are hard to predict and harder to spot. History is full of examples: protocols whose designs were sound but whose implementations leaked keys through timing, or mishandled edge cases, or contained bugs that no one noticed for years. Formal verification of the design does nothing to catch those failures, because it is checking the wrong thing. Verifying the compiled code closes that gap, at least for the parts covered, because it checks the thing that actually runs rather than the thing that was intended. That is why DeepMind’s claim that this is the first time the implementation of a widely deployed protocol has been formally verified by any method matters: it is not just a stronger version of an old result, it is a different kind of result, aimed at a different layer of the system, and it addresses the layer where the failures that hurt real users actually happen.

5.2 The AArch64 machine-code level

The proof targets a specific, concrete layer: libsignal version 0.105.4, compiled with the stock Rust compiler into AArch64 machine code, and linked to a small command-line harness running on AArch64 Linux. AArch64 is the 64-bit instruction set used by ARM processors, which power the overwhelming majority of smartphones in the world, so the choice of target is not arbitrary: it is the architecture that most Signal users actually run on. The proof rests on about 26,000 lines of trusted specifications and machine-code rules, including about 8,000 lines describing how AArch64 instructions behave, and that trusted base is what connects the abstract proof to the concrete reality of the processor. The specificity is both a strength and a limit. It is a strength because it means the proof is about something real, not about a simplified model that might not match reality. It is a limit because a proof for one compiled version on one architecture does not automatically transfer to other versions, other compilers, other architectures or the full app on a user’s phone. DeepMind and the coverage have both been clear about this: the work applies to libsignal version 0.105.4, compiled for ARM Linux inside a test harness, and a proof for that version does not automatically transfer to code modified after that version. That precision is honest, and it is what makes the result trustworthy: it says exactly what was proved, and it does not claim more.

6. The Sanity Check: Two Old Bugs, Correctly Caught

A proof is only useful if it can tell the difference between good code and bad code, and DeepMind’s team tested exactly that. As a sanity check, the researchers took two real bugs that had previously been found and fixed in Signal’s code, put them back into an isolated copy of the library, and asked the system whether the buggy version was secure. In both cases, the system produced a machine-checked proof that the buggy version was insecure. That is a small detail in the announcement, but it is an important one, because it shows that the verification is not a rubber stamp. A system that proved everything secure, including code that was deliberately broken, would be worthless; a system that correctly identifies broken code as broken is doing the job it claims to do. The test also answers a natural scepticism about AI-generated proofs: if the agents were simply producing plausible-looking formal text, they would have had no way to distinguish the fixed code from the buggy code, and the test would have failed. That it passed in both cases gives the result a credibility that the raw numbers alone cannot provide, and it is the kind of validation that security researchers look for before they take a new technique seriously.

6.1 Reintroducing fixed flaws on purpose

The technique of reintroducing a known bug to test a verification system is a standard one in security research, and it works because the bug is a known quantity: the researchers already know what is wrong with the code, so they can check whether the system finds it. In this case the two bugs were real flaws in Signal’s history, found and fixed long ago, and putting them back into an isolated copy of the code created a controlled experiment. The system was not told that the code was buggy; it was simply asked to prove the same security properties about the modified code, and in both cases it could not, because the properties genuinely did not hold. Instead, it produced a proof that the buggy version was insecure, which is the correct answer. The experiment was run in isolation, on a copy of the code, so there was no risk to real users, and the bugs were not reintroduced into any software that anyone uses. The value of the test is that it demonstrates the system’s sensitivity: it is not just capable of proving good code correct, it is also capable of detecting bad code, and that is the property that matters if the technique is going to be used to check software that has not yet been verified.

6.2 No new flaws found in the parts examined

Alongside the sanity check, the announcement carries a second finding that is easy to misread: no new vulnerabilities turned up in the parts of the code that were examined. That is good news for Signal users, and it is consistent with the protocol’s long history of scrutiny, but it needs to be stated carefully. The absence of new flaws in the examined parts does not mean the whole of libsignal is flawless, and it certainly does not mean the Signal app is flawless, because the proof covered only the two named components, only for one-to-one sessions, and only for one compiled version on one architecture. What it means is that the core cryptographic machinery, in the form examined, does what its specification says, and that the agents found no hidden flaw in it. That is a meaningful result, but it is not a guarantee about anything outside the boundary of the proof, and DeepMind has not presented it as one. The reporting of the announcement has been careful on this point, with one outlet noting that the work is not a certificate that the entire Signal app is impossible to hack, and another stressing that the result does not replace app updates, device security or the ordinary precautions users should take. The honest reading is that a very important part of the system has been checked very thoroughly and found sound, and that the parts outside the check remain as they were: unproven, but not thereby shown to be broken.

7. What the Proof Does Not Cover

Every formal verification has a boundary, and the boundary of this one is unusually well documented, because DeepMind and the coverage of the announcement have both spelled it out in detail. The proof covers one-to-one sessions only, which means group messaging is not covered and is listed as future work. It applies to libsignal version 0.105.4, compiled for AArch64 Linux inside a test harness, and not to the full Signal app on a user’s phone. It does not cover the app itself, the servers, the key servers, the user interface that shows a safety number, linked-device state, or the operating system the app runs on. It does not cover every device architecture, and it does not cover future versions of the library. The low-level cryptographic building blocks — the primitives that do the actual encryption — were treated as assumed-secure contracts rather than proven from scratch, which means the proof assumes those primitives work as advertised and proves everything built on top of them. The paper is also explicit, according to the coverage, that no post-quantum guarantee is established for the healing property of one newer component, the ML-KEM Braid, and that post-compromise security for that component is out of scope. These limits are not footnotes; they are part of the result, and understanding them is essential to understanding what the announcement actually means.

7.1 Group chats, apps and servers

The largest single gap in the coverage is group messaging. Most of the conversations that matter to most people happen in groups — family chats, work chats, community chats — and the proof says nothing about them, because the verification was limited to one-to-one sessions. The protocol that protects a group conversation is different from the one that protects a conversation between two people, and it has its own properties and its own failure modes, none of which have been verified in this work. Beyond group chats, the proof also stops at the boundary of the library itself. The full Signal app, with its user interface, its handling of attachments and calls, its storage of messages on the phone, its management of linked devices and its communication with Signal’s servers, is a much larger system than the cryptographic core, and none of it was verified. The servers that relay messages, the key servers that distribute public keys, and the safety-number display that lets users check they are talking to the right person are all outside the proof as well. That does not mean any of those parts are broken; it means they were not checked, and their security still rests on the ordinary mix of code review, testing and operational care that has always protected them. For users, the practical consequence is simple: nothing about how the app works has changed, and the announcement is not a reason to change how the app is used.

7.2 Assumptions the proof rests on

Every proof rests on assumptions, and this one is no exception. The most important assumption is that the low-level cryptographic primitives — the mathematical building blocks that perform the actual encryption, key agreement and signing — are secure as advertised. Those primitives were modelled as assumptions, which means the proof takes their security as a given and proves everything built on top of them, rather than proving the primitives themselves from first principles. That is standard practice in formal verification, because proving a primitive from scratch is a different and much larger task, but it means the result inherits the trust placed in those primitives. If a primitive were later found to be broken, the proof about the code built on it would not protect users. A second set of assumptions concerns the trusted base itself: the 26,000 lines of specification and machine-code rules that the proof rests on. If the specification misstates what the protocol is supposed to do, the proof could be formally correct and still miss a real problem, because it would be proving the wrong thing. And a third set of assumptions concerns the execution model: the proof applies to the code compiled in a particular way, on a particular architecture, inside a test harness, and it does not cover side channels, such as the timing of operations or the power consumption of a device, which can leak information in ways that a proof about the code’s logic cannot see. None of this undermines the result, but it defines its shape: the proof is a strong statement about a precisely defined thing, and it should not be mistaken for a blanket statement about everything around it.

8. What This Means for Encrypted Messaging

The announcement matters for two different audiences, and it matters in different ways for each of them. For the research community and for the people who build secure software, it is a demonstration that AI agents can now do formal verification at a scale and speed that was previously out of reach, and that opens up the possibility of verifying other critical software that has so far been too large or too expensive to check. If the technique generalises, the next targets could include other messaging protocols, the group-messaging parts of Signal itself, operating system components, or the software that runs financial and medical infrastructure, and the security of all of those systems could be put on a firmer footing. For ordinary users of Signal, Google Messages or WhatsApp, the announcement matters in a quieter way: it is an extra layer of assurance about the code that protects their conversations, not a change to anything they need to do. There is no emergency patch, no account change and nothing new to install, and the coverage has been clear that users should not treat the result as a reason to stop updating their apps or checking safety numbers. The result does not make any app unhackable, and it does not protect a phone that is itself compromised, or a user who is tricked into handing over access. What it does is raise the confidence that the core cryptography, in the form examined, does what it promises, and that is a real achievement, even if it is not the end of the story.

8.1 What users should and should not do

For Signal users, the practical advice that follows from the announcement is refreshingly boring: keep doing what you were already doing. There is no special migration required, no setting to change and no new version to install because of this result, and the coverage has stressed that the proof does not replace app updates, device security, linked-device reviews or safety-number verification. Users should still keep their apps updated, because future versions of the library will contain fixes and improvements that this proof does not cover, and a proof for version 0.105.4 does not automatically transfer to the code that comes after it. They should still check safety numbers when they start a sensitive conversation, because the proof does not cover the user interface or the key servers that make that check meaningful. And they should still be careful about the security of their own phones, because no proof about a messaging library can protect a device that has been compromised at the operating-system level. What users should not do is treat the announcement as a guarantee that nothing can go wrong. The proof is about a defined implementation, a defined execution model, a defined set of properties and a defined collection of cryptographic assumptions, and outside those definitions the ordinary risks of using a phone and an app still apply. The announcement is best understood as a strengthening of one layer of a system with many layers, not as a replacement for the others.

8.2 The Bottom Line

Google DeepMind’s AlphaProof Code announcement is a genuine advance, and it deserves to be reported as one, with its limits stated as clearly as its achievements. In four weeks, a team of five researchers working with AI agents produced a machine-checked proof, running to more than six million lines of Lean, that the compiled code of Signal’s core protocol — the post-quantum handshake and the Triple Ratchet, in libsignal version 0.105.4 on AArch64 — fulfils the key security properties it promises: messages stay secret, the other side is who they claim to be, past messages survive a later key leak, and a conversation heals after a compromise. The system proved it could tell good code from bad by correctly flagging two old bugs reintroduced on purpose, and it found no new flaws in the parts it examined. The proof does not cover group chats, the full app, the servers, other architectures or future versions, and it rests on assumptions about the cryptographic primitives and the specification that it does not itself prove. What is still unconfirmed is how quickly the technique will be extended to the parts left out — group messaging first among them — whether other widely used protocols will be verified in the same way, and whether the same approach will be taken up for the other critical software that society depends on. For now, the result stands as a careful, checkable and openly published piece of work: the first formal verification of the implementation of a widely deployed protocol, done by AI agents under human supervision, checked by a machine, and honest about exactly what it does and does not prove. The coming weeks will show whether other teams pick up the technique and where they aim it next, and the answers to those questions will say a great deal about how quickly this kind of assurance becomes normal rather than exceptional.

Comments

comments