Anthropic formal verification with Claude: proofs for 123 open-source libraries, the bugs it found, and what the proofs don't cover

Anthropic's formal verification research, published on October 22, 2026, reports that Claude produced machine-checked proofs that compiled code from 123 open-source libraries can't crash, and found hundreds of bugs along the way. Working with the verification startup Theorem, Anthropic's Frontier Red Team had Claude turn existing fuzz tests from Google's OSS-Fuzz project into mathematical specifications, then prove them for every input under 64 MB. It's a different approach from the bug scanning behind Anthropic's OSS Scanner: instead of finding bugs, the goal is to prove there are none of a certain kind.

This story is based on Anthropic's post and its appendix, Theorem's OSS Verify page and the released proof repositories, checked October 26, 2026. Anthropic is the author of both the method and the results; no outside group has published a replication.

The short version

• What was proved: for 239 entry points across 123 OSS-Fuzz libraries, the compiled program always exits normally, with no memory-safety error or failed assertion, for any input under 64 MB.
• How: Claude wrote proofs about RISC-V machine code in Rocq (formerly Coq), using Theorem's model of RISC-V instructions and Linux processes; Rocq's checker verified them.
• Scale: about 180 million lines of checked proof, with a typical proof around 600,000 lines.
• Bugs: "hundreds," which Claude patched before completing the proofs. Anthropic names one CVE and describes a handful of others.
• Limits: the proofs cover one specific build setup and one definition of "crash." Anthropic says plainly that "'Formally verified' does not mean 'bug-free.'"

What did Claude actually prove?

OSS-Fuzz runs fuzz tests, small programs that feed random inputs into a library and flag crashes caught by AddressSanitizer, a memory-error detector. A fuzz test only checks the inputs it happens to try. Anthropic's idea was to treat each fuzz test as a specification and prove it for all inputs.

For the libraries that succeeded, Anthropic says "Claude proved that these programs will always exit normally without triggering memory-safety errors or failing assertions," for "every input less than 64 MB and every modeled Linux operating system (OS) response and memory layout." When a fuzz test asserts a deeper property, the proof covers that too. Anthropic's example is a test for the LZO compression algorithm that checks that compressing and then decompressing returns the original data.

The proofs are about compiled code, not source code. Claude worked from RISC-V binaries, which Theorem's semantics translate into a mathematical model. Anthropic describes this as the first large-scale effort of its kind at the assembly level. That choice matters because compilers can introduce behavior the source doesn't show.

Which tools and models were used?

The proofs rest on a chain of tools, each with its own role:

Anthropic doesn't say which Claude model produced the 123-library results. In a separate efficiency test on 36 verification tasks, it compared Claude Opus 5, Opus 5.5 and Fable 5.1, and says "Opus 5.5 proves half of them with about 40% fewer tokens than Opus 5." Agents sharing a workspace needed 17% fewer tokens than agents working alone. These are Anthropic's own results on its own tasks.

The cost is in tokens and time, not people. Anthropic says proofs "can take hundreds of millions of tokens to produce" and the main effort ran "over the span of a few weeks." It gives no dollar figure. For contrast, it cites the seL4 microkernel, which took "two person-years" to build "but 20 person-years to formally verify."

What bugs did the proofs find?

A proof fails if there's an input that crashes the program, so attempting proofs is also a way to find bugs. Anthropic says the process "discovered hundreds of bugs." Claude then "patched the code, which caused the spec to be regenerated with that patched code," and proved the patched version. The examples Anthropic gives include:

• a counter underflow in a decompressor that caused an out-of-bounds write on inputs of about 20 MB with one specific layout;
• an out-of-bounds read in an image decoder that needed a 64 MB input and more than 2 GB of memory;
• a rediscovery of CVE-2026-56132 in libexpat, which needed deeply nested input;
• a logic bug: a feature for restricting which files an application can load "isn't always enforced."

The bugs that need huge or unusual inputs show why fuzzing misses them: random testing rarely builds a 20 MB file with exactly the right shape.

Anthropic also describes case studies beyond OSS-Fuzz. Proving a widely used PDF reader found "as many security bugs in one week as are typically reported in a year." Elsewhere it found "a previously unknown logic bug that had been latent for more than a decade." For zlib, Claude proved the x86 binary against the RFC 1950 format specification, using x86 semantics that Claude itself generated and that Anthropic says were heavily tested. And in a test of building verified software from scratch, Claude wrote a Python interpreter in Rust, verified with Verus, that matched CPython on 99.95% of 1.7 million random programs.

Were the bugs disclosed and fixed upstream?

The post doesn't say most of them were. Its only statement on upstream reporting is that "some minor (unexploitable) bugs in corner cases," found while proving zlib and half a dozen other widely used libraries against their specifications, "are in the process of being filed upstream." Claude's patches were applied to the code it was proving, and Anthropic doesn't say whether maintainers have accepted them. It says it is "not releasing proofs that may reveal an unpatched bug," which suggests some bugs remain unfixed. It doesn't give the number of bugs, the affected libraries or a disclosure timeline.

That's a gap for a result built on other people's code. Anthropic's OSS Scanner has a published disclosure policy, compared in our Patch the Planet analysis, but this post doesn't say whether the same terms apply. Theorem's separate OSS Verify service says it reports bugs to maintainers privately, sets no disclosure deadline, and that its "findings and patches are generated by AI models" and may not be reviewed by a person before they're sent. Maintainers already strained by AI-generated reports, as in the PHP2Shell case, may not welcome more unreviewed patches.

How much should you trust the proofs?

The checking is strong, and the claim is narrow. Anthropic says "virtually none" of the proof code needs manual review, because Rocq's checker either accepts a proof or doesn't. What a person does have to trust is everything around the proof. Anthropic lists the limits itself:

• The build is unusual. The proofs assume "a single-threaded static binary" on RISC-V, linked against the musl C library. Most deployments run on x86 or ARM with glibc.
• "Crash" means what AddressSanitizer catches. AddressSanitizer doesn't detect every memory-safety bug, so the guarantee inherits its blind spots.
• Coverage is partial. Not every entry point was verified, and code no fuzz test reaches isn't covered. A caller that misuses a library can still corrupt memory.
• The model must match reality. If the real machine does something Theorem's semantics don't describe, the proof says nothing about it. The trusted base includes the Rocq checker, those semantics, the hardware, the operating system and the OCaml compiler.
• Specs can be wrong. A proof only shows the code meets its specification. Here the specs are fuzz tests, so a weak fuzz test yields a weak guarantee.

Reward hacking was a specific risk: Claude could make a program "never crash" by patching it to do nothing. Anthropic says it "penalized any patch," rewarded proving which inputs a patch changes, and "logged and audited the patches for these failure modes." It doesn't report how many patches were rejected. The appendix's unnamed expert review also found the proofs verbose and noted that, in earlier work, "agents hit a complexity wall" with that style, so it's unclear how far the approach scales. About 1 billion lines of Rocq were written in total, of which about 180 million were in proofs that passed.

What builders should take from it

For maintainers, the practical offer is Theorem's OSS Verify: free proofs for qualifying projects with fuzz tests, delivered privately, with a build that produces static RISC-V binaries. For everyone else, the work shows AI shifting from finding individual bugs to ruling out whole classes of them, at a cost measured in tokens rather than person-years. The same week, flaws such as HTTP2Shell, reported by OpenAI's Codex Security team, showed how much of the web still runs on code nobody has proved anything about.

What's confirmed, reported and uncertain

• Confirmed (Anthropic, published): the 123 libraries and 239 entry points, the 64 MB property, the RISC-V and Rocq setup, the 180 million lines, the bug examples and the stated limits. Anthropic's abstract says "over 100" libraries; the body gives 123.
• Vendor-reported: the bug counts, the PDF-reader comparison and the model efficiency figures, which no outside group has replicated.
• Uncertain: which Claude model produced the main results, how many bugs were reported to and fixed by maintainers, and which libraries beyond the named examples were covered.