Anthropic says Claude formal verification now works at real-world scale: working with the startup Theorem, Claude wrote machine-checked proofs for 123 open-source libraries. In plain terms, those proofs show certain code can’t crash on inputs up to 64 MB. Anthropic’s results were reported on October 22, 2026.
This matters because fuzzing, the usual way to hunt crashes, can only show that bugs weren’t found. A proof can show they can’t happen, at least within its stated limits.
- Scope: 239 entry points across 123 OSS-Fuzz libraries
- Roughly 180 million lines of proof code, about 600,000 per proof
- Checked by Rocq, a separate proof checker, so nobody reads every line
- Proofs cover compiled RISC-V machine code, single-threaded, on a modeled Linux
- Reported by Glitchwire as taking a few weeks of work
What Claude formal verification actually proved
The claim is narrow but strong. For each of 239 entry points, Claude proved the program won’t crash on inputs up to 64 MB. That’s a guarantee about every possible input in that range, not a sample of them.
The proofs target compiled machine code rather than source. That’s useful, because a compiler can introduce its own surprises. Proving things about the final binary closes that gap.
Writing proofs at this size by hand would take experts years. Per the reports, Claude produced them in weeks. Rocq (the tool formerly called Coq) then checked each one, so you trust the checker, not the AI.
That last point is the real shift. AI-written code and AI-written claims are hard to trust on their own. A small, well-understood checker gives you a reason to trust the result without trusting the model.
Many of these libraries sit deep inside apps you already use, handling images, compressed files and XML. A crash there can become a security hole, so fewer crashes means fewer openings for attackers.
How Claude turned fuzz tests into proofs
Claude didn’t start from nothing. It took each library’s existing fuzz tests and rewrote them as mathematical specifications. Those specs say what “safe” means for that code.
Then it built a proof that the code meets the spec. When a proof failed, that pointed to a real bug. Claude patched the bug and wrote a fresh proof for the fixed code.
Theorem, a San Francisco startup, supplied the models of the RISC-V processor and the Linux process. If you’re curious how AI is already being used to find flaws, our piece on Anthropic’s exploit chains and how to patch covers the attack side of the same story.
The bugs fuzzing missed
Interesting Engineering reports the effort turned up hundreds of bugs. Several had survived years of fuzzing. They share a trait: they only show up on rare, large, or oddly shaped inputs.
- A counter underflow that could cause an out-of-bounds write during decompression, needing about 20 MB of input with a rare data layout.
- An image decoder failure that needed a 64 MB input and more than 2 GB of memory.
- An out-of-bounds read triggered by two handles pointing to the same file.
- A logic flaw that let an app bypass a feature limiting which files it can load.
These are the cases a random tester almost never hits. A proof has to cover them, so it can’t skip them.
Where Claude formal verification stops
Don’t read this as “the internet is now bug-free.” A proof is only as good as its specification. If the spec misses a property, nothing guarantees it.
| Fuzzing | Formal proof | |
|---|---|---|
| What it shows | No crash found in the inputs tried | No crash is possible for every input in scope |
| Where it can fail | Bugs hiding on rare, huge inputs | Gaps in the specification or the model |
| Cost so far | Cheap and automated | Years of expert work, until now |
| Used here for | Source of the starting tests | The final guarantee on compiled code |
The scope is also tight. The proofs assume single-threaded, statically linked programs on RISC-V under a modeled Linux. Most phones, laptops and servers run something else. Other setups would need more modeling work.
Reports also say the framework is complex, so well-funded teams are the likely first users. Anthropic released the proofs, but the sources don’t say outsiders can use the tooling yet.
We saw similar questions about checking AI-made claims in our look at OpenAI’s math proof claims. The difference here is that a separate checker verifies each proof.
Frequently Asked Questions
Does formal verification mean the libraries are bug-free?
No. It means they can’t crash in the ways the proofs describe, under the stated assumptions. Other kinds of bugs, like logic errors outside the spec, could still exist.
Do I need to do anything as a regular user?
No. Keep your apps and system updated, since patches for the bugs found flow through normal library updates. Nothing here needs your action today.
What is Rocq?
Rocq is a proof assistant, formerly called Coq. It checks that a mathematical proof is valid, so you don’t have to trust whoever wrote it.
Can other developers use this method?
Not clearly yet. Anthropic released the proofs, but the reports don’t describe public access to the tooling. The heavy setup suggests it’s early.
My take: this is the most convincing AI-for-security result lately, because a checker proves the work rather than asking you to believe it. Treat it as a strong first step, not a finish line. If proofs like these spread to more chips and operating systems, crash bugs in core libraries could get much rarer.
Leave a Reply