Anthropic: Claude Proved 123 Libraries Crash-Free With Formal Verification

Anthropic's Frontier Red Team has published research arguing that large language models are making formal software verification feasible at a much larger scale. In its post, LLMs are making formal software verification feasible at a much larger scale, Anthropic says Claude proved security properties at the RISC-V assembly level for 123 open-source libraries, covering 239 OSS-Fuzz entry points, in a few weeks. The work was done with Theorem, a formal-methods company, and found hundreds of bugs along the way.

The headline is not "AI proved software correct." It is narrower and more interesting: a proof-writing job that used to cost person-years can now be attempted by agents, and the checker, not the model, decides whether the result counts. This post covers what was proved, the numbers, the bugs, the caveats Anthropic itself lists, and what it means if you ship code.

Formal verification by Claude: the short version

Why formal verification has been so expensive

Formal verification means proving, with mathematical rigor, that code satisfies a specification. Unlike testing, which samples inputs, a proof covers all of them. The catch has always been labor. Anthropic points to seL4, the verified microkernel, where two person-years of implementation needed roughly 20 person-years of verification. We covered the latest seL4 proof effort in seL4 AArch64 confidentiality proofs, and the economics there are exactly what Anthropic says is changing.

The argument is that LLMs are now good at writing the long, tedious, mechanical proofs, and a proof checker cannot be fooled by a confident-sounding model. If the proof does not check, it does not count. That asymmetry is why this is a better fit for LLMs than most "AI writes code" tasks: the verification is free and exact. The same logic drove the math results we have covered, from Claude's Lean proof work on Fermat's Last Theorem to the collapse in Lean proof costs.

Puzzle pieces fitting around a green seal, a picture of formal verification proofs that a checker accepts

How the OSS-Fuzz verification worked

Anthropic's pipeline reused something the open-source world already has: fuzz tests. Each OSS-Fuzz entry point was converted into a specification. The spec says the compiled program never crashes for any input under 64 MB, in a model of executing RISC-V binaries on Linux. Claude then wrote the proofs in Rocq, and the Rocq kernel checked them.

When Claude hit a real bug, it did not stop. It patched the code, regenerated the spec and continued proving. The result, per Anthropic, is proofs for 239 entry points across 123 libraries after patching what it found.

The scale is worth sitting with. About 180 million lines of Rocq is far beyond what a human team could review, and a typical proof of roughly 600,000 lines covers a binary of a median 18,000 instructions. Nobody reads these proofs. People trust the kernel that checks them and read the spec, which is short.

The bugs: what proof found that fuzzing did not

Anthropic lists several examples, and they share a theme: the triggering input is unusual enough that fuzzers rarely reach it.

• A counter underflow in a decompressor leading to an out-of-bounds write, triggered only by roughly 20 MB inputs with one rare layout.
• An out-of-bounds read in an image decoder that needed a 64 MB input and more than 2 GB of memory.
• An out-of-bounds read in another library needing a specific sequence of calls across two handles to the same file.
• A rediscovery of CVE-2026-56132 in libexpat, which required deeply nested input.
• A logic bug where a file-restriction feature was not always enforced, with no crash involved.

Anthropic notes that fuzzers typically cap input size around 1 MB, which is one reason these survive fuzzing. A proof has no such cap by construction. In one case, verifying cpp-httplib meant proving that libc++'s red-black tree keeps its depth logarithmically bounded, which rules out a stack overflow in the std::set destructor. That is the kind of fact nobody writes a test for.

Other case studies: zlib, a Python interpreter and a PDF reader

The post goes beyond the OSS-Fuzz run.

zlib. Claude wrote a formal spec from RFC 1950 and proved the Linux kernel's zlib implementation meets it, at the x86 binary level, using Claude-generated x86 semantics. Repeating the exercise for about six other libraries turned up minor, unexploitable corner-case bugs.

A Python interpreter in Rust. Claude built an interpreter for a large Python subset and used Verus to prove it follows CPython semantics taken from an academic paper. Testing 1.7 million random programs, behavior matched CPython 99.95 percent of the time. That figure is a test result, not a proof, and it is worth keeping the two apart.

A PDF reader. Attempts to verify simple security properties found, in one week, as many security bugs as are typically reported in a year, according to Anthropic.

The honest limits Anthropic lists

The research is unusually direct about what "verified" does not mean, and a reader should hold these next to the headline.

• A proof is relative to a spec. A checker cannot confirm the spec matches what you wanted. Bugs can live in the spec, the machine model, or trusted pieces: Rocq itself, the RISC-V and Linux semantics, the hardware, and the OCaml compiler Rocq relies on.
• Environment mismatch. The proofs cover single-threaded static RISC-V binaries linked against musl libc. Most users run x86 or ARM builds dynamically linked against glibc.
• Incomplete coverage. AddressSanitizer does not catch every memory-safety bug, not all entry points were verified, dead code is not covered, and a caller that misuses a library can still corrupt memory.
• Reward hacking. Claude could satisfy a "never crashes" proof by rewriting the program so it never does anything risky. Anthropic penalized patches, gave extra credit for characterizing which inputs a patch changes, and audited patches. We looked at the broader problem in Anthropic's work on reward hacking.

What it costs: tokens, reuse and Opus 5.5

Proofs can take hundreds of millions of tokens. Anthropic reports that on 36 small verification tasks, Opus 5.5 used about 40 percent fewer tokens than Opus 5. When agents shared a workspace, they needed 17 percent fewer tokens on average, and some succeeded where solo attempts failed. In the OSS-Fuzz effort, teams often copied and adapted finished proofs, since much of each proof covers shared runtime code such as libc.

That reuse point is the strategic one. Verify a widely shared library once and every project that depends on it benefits. Anthropic compares this to Mathlib, which holds nearly 300,000 theorems from over 700 contributors, and notes that Theorem has published a roadmap for verifying the Nix ecosystem. For background on Claude's proof tooling, see Boris Cherny on Opus 5.5 with Lean and TLA+.

How this fits Anthropic's security push

This is the latest in a run of Anthropic security work. The company has opened OSS Scanner for free vulnerability scans of open-source projects, a tiered cyber verification program, and published a Frontier Red Team study of a self-replicating AI botnet. Scanning finds bugs; verification proves their absence for a stated property. They are complementary: a scanner that finds nothing is weak evidence, a checked proof is strong evidence about exactly what it states.

If you worry about what AI coding agents do to your own systems while they work, AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions. It is a different layer from proofs about library code, but the same goal: not trusting output you have not checked.

What this means if you ship software

• If you maintain a C or C++ library with OSS-Fuzz coverage, your fuzz harness is now a ready-made spec. That is the cheapest on-ramp.
• If you write Rust, the Verus result suggests proof-carrying code for core modules is becoming plausible, not just academic.
• If you depend on libraries, treat "formally verified" as a claim with a scope. Ask what property, which binary, which semantics.
• If you use AI to write code, the lesson is to pair generation with an exact checker. Tests are a weak checker; types and proofs are stronger.

Anthropic and Theorem say they are ready to help. Theorem will run the pipeline for other open-source projects, and a Claude skill is available for developers verifying their own code. Anthropic's closing prediction is that formal verification will become as routine as fuzzing, and it encourages developers who gave up on earlier models to try again. That is a forecast, not a result: nothing in the post shows a project adopting this in production yet.

Our read

The strongest part of the post is its restraint. It does not claim bug-free software; it claims machine-checked no-crash proofs for named binaries under named assumptions, and then lists the assumptions. The weakest part is that the code and proofs released are a subset, so independent readers cannot yet re-check the whole 180 million lines. Watch for third-party audits of the spec and the RISC-V and Linux semantics, because that is the small trusted core everything else rests on.

For readers learning AI, this is a clean example of verification asymmetry: when an answer can be checked cheaply and exactly, models can be pushed much harder, with far less trust required. That pattern explains why math and proofs have moved faster than open-ended tasks.

Related reading

• Theorem OSS Verify: free crash-freedom proofs for open-source projects

• seL4 AArch64 confidentiality proofs

• Claude and the Fermat's Last Theorem Lean proof

• Lean 4 formal proof cost collapse

• Boris Cherny on Opus 5.5, Lean and TLA+

• Anthropic OSS Scanner

• Anthropic cyber verification program

• Anthropic reward hacking research

• Official: Anthropic's formal verification post and Theorem

Figures and claims are from Anthropic's post as of October 22, 2026 and may be revised.