By Thorsten Meyer | October 23, 2026 | ThorstenMeyerAI.com
Get business pricing on tech for your team
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
On October 22, Anthropic’s Frontier Red Team and its collaborator Theorem reported that Claude proved security properties for 239 entry points in 123 open-source libraries, down at the level of the compiled machine code. Along the way it found bugs that years of fuzzing had missed. Here is what was actually proved, how the method works, what it cost, and where the proofs stop.
Key takeaways
- What was proved: for 239 fuzz-test entry points in 123 OSS-Fuzz libraries, the compiled RISC-V program never crashes on any input under 64 MB: no AddressSanitizer memory error, no failed assertion, under stated assumptions.
- How: the existing fuzz test becomes the specification. Claude writes the proof, the Rocq proof checker verifies it. About 180 million lines of proof needed no human review.
- Bugs found: hundreds, including ones a fuzzer would be unlikely to ever reach.
- Cost is the bottleneck: proofs can take hundreds of millions of tokens, but newer models and shared proofs need fewer.
- Limits: “formally verified” does not mean bug-free. The proofs cover single-threaded static RISC-V binaries linked against musl, not the x86 or ARM builds with glibc that most people run.
formal verification software tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Why this matters now
Anthropic opens with a blunt premise: most software is full of bugs, and AI can now find and exploit them. It points to the Linux kernel, one of the most heavily tested codebases in the world, which recently had more than 1,000 vulnerabilities disclosed. If models can chain small bugs into exploits, testing is no longer enough. You want proof that a class of bug is absent.
Formal verification provides that proof, but it has always been expensive. Anthropic cites the seL4 microkernel: two person-years to build, 20 person-years to verify. That is why verification has stayed in niches like Airbus avionics code. The claim of this paper is that language models change the economics.
I wrote recently about the referee shortage: AI made producing results cheap, but checking them stayed slow and human. Formal verification is one of the few places where checking can be handed to a machine.
As an affiliate, we earn on qualifying purchases.
From fuzz test to proof
The hard part of verification is usually the specification: what does “correct” even mean for a web browser? Anthropic and Theorem sidestep that by reusing the tests developers already wrote.
A fuzz test is a small entry point into a library. A fuzzer throws huge numbers of random and mutated inputs at it, and any crash counts as a bug. Fuzzing is brute force: no number of inputs guarantees that every code path was exercised.
The team turned each fuzz test into a specification over the compiled program: for every input under 64 MB, this test does not crash. If Claude can prove that, fuzzing that entry point can never find another crash on the modelled system.
The pipeline, as Anthropic describes it:
- The library and its fuzz test are compiled to a RISC-V executable, instrumented with AddressSanitizer so that improper memory access crashes the program.
- Theorem’s formal models of RISC-V instructions and Linux processes, plus the no-crash property, mechanically produce the specification.
- Claude writes the proof in Rocq. When the proof fails, the failure points at a possible bug. Claude patches the code, the specification is regenerated, and Claude proves it again.
- The Rocq proof checker verifies the proof against the specification.
Infographic 01 · From test to proof
Existing fuzz tests became specifications. Claude proved them.
Over a few weeks, Claude proved at the machine-code level that hundreds of real fuzz entry points can no longer crash, after patching the bugs it found.
The pipeline
From an existing test to a checked proof
- Compile. The library and its existing fuzz test become a RISC-V executable, instrumented with AddressSanitizer.
- Specify. Theorem’s RISC-V and Linux process semantics plus the no-crash property mechanically yield the specification.
- Prove. Claude writes the proof in Rocq. A failed attempt points at a possible bug; Claude patches it and proves the new spec.
- Check. The Rocq proof checker verifies the proof. Virtually none of the proof needs human review.
Fuzzing vs. proof
Same entry point, different guarantee
| Fuzzing | Proof | |
|---|---|---|
| Inputs | Fuzzing: Generated samples, typically capped at 1 MB | Proof: Every input under 64 MB |
| Paths | Fuzzing: Guided by code coverage, no guarantee | Proof: Every path reachable from the entry point |
| Result | Fuzzing: Bugs found so far | Proof: No crash left to find on the modelled system |
Typical proof: about 600,000 lines for a binary with a median length of 18,000 RISC-V instructions.
“If Claude can prove this spec, the fuzz test on RISC-V becomes superfluous.”Anthropic, 22 Oct 2026
Source: Anthropic, “LLMs are making formal software verification feasible at a much larger scale” (22 Oct 2026).
Powered by Thorsten Meyer AI
The scale is the news. Over a few weeks, Claude proved the no-crash property for 239 entry points in 123 OSS-Fuzz libraries. The proofs total about 180 million lines of Rocq. A typical proof runs to about 600,000 lines and covers a binary with a median length of 18,000 RISC-V instructions. Anthropic calls this, to its knowledge, the first large-scale use of AI to apply formal verification to production software at the assembly code level.
Nobody has to read those 180 million lines. What has to be trusted is short: the formal models of RISC-V and Linux processes, the exact theorem statements, and the Rocq checker itself. A footnote adds the hardware, the operating system and the OCaml compiler that Rocq relies on. Anthropic is publishing the proofs that did not require patching, the trusted components that were not already public, and the specifications for fuzz tests it could not prove.
As an affiliate, we earn on qualifying purchases.
Why proofs find bugs that fuzzers miss
A proof has to cover every path from the entry point, not just the paths a fuzzer happens to hit. That is why the attempt to prove found what testing had missed. Anthropic says the process “discovered hundreds of bugs.” Fuzzers typically mutate small inputs, typically capped at 1 MB, and follow code coverage. Several of the bugs Claude found sit far outside that range:
- a counter underflow in one library’s bundled copy of a decompressor that led to an out-of-bounds write, but only on inputs of around 20 MB with one rare, specific 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 that needed a particular sequence of calls across two handles to the same file;
- a rediscovery of CVE-2026-56132 in libexpat, which needs deeply nested input;
- a logic bug that never crashes: a feature meant to restrict which files an application can load was not always enforced.
Even a proof attempt that never finishes yields real bugs.
As an affiliate, we earn on qualifying purchases.
More than memory safety
Many fuzz tests check high-level properties by crashing when they fail. The LZO compression fuzz test asserts that decompressing a compressed input returns the original. Proving that test never crashes proves the round-trip property itself.
Sometimes the proof forces properties nobody wrote down. To finish the cpp-httplib proof, Claude had to rule out a stack overflow from deep recursion in a std::set destructor. That meant proving, on machine code, that libc++’s red-black tree keeps its depth logarithmically bounded.
Anthropic also describes other experiments:
- zlib: Claude wrote a formal spec of RFC 1950 and proved that the Linux kernel’s zlib implementation meets it, directly on the x86 binary, using x86 semantics that Claude generated itself. The team repeated this for half a dozen other widely used libraries and found some minor, unexploitable corner-case bugs, which are being filed upstream.
- A Python interpreter in Rust: Claude built an interpreter for a large subset of Python and proved with Verus that it follows CPython semantics from an academic paper. On 1.7 million random programs it matched CPython in 99.95% of tests.
- A widely used PDF reader: in one week of verification attempts, the team found as many security bugs as are typically reported in a year.
What it costs, and why that will fall
Anthropic is open about the main limitation: a proof can take hundreds of millions of tokens. Two measurements suggest the cost will come down:
- Newer models need fewer tokens. On 36 small verification tasks built from OSS-Fuzz code, Opus 5.5 proves half of them with about 40% fewer tokens than Opus 5.
- Proofs can be reused. When agents could copy each other’s proofs in a shared workspace, they needed 17% fewer tokens than agents working alone. Working alone cost more for 30 of the 34 completed proofs, and solo agents could not finish two of them.
Reuse is the bigger lever. Most of each proof covers code every program contains, such as C runtime start-up and AddressSanitizer, so agent teams copied and adapted finished proofs. Anthropic compares this with Mathlib, Lean’s shared library of formal mathematics, which grew to nearly 300,000 theorems from more than 700 contributors. Since dependencies follow a power law, proving a small set of shared libraries once covers a large part of the software stack. Theorem has published a roadmap for verifying the entire Nix ecosystem, including glibc, OpenSSL and cURL.
Infographic 02 · What proving finds and costs
Trying to prove found bugs. Sharing proofs made it cheaper.
Even an unfinished proof attempt yields real bugs. The token bill is the main limit, and both newer models and proof reuse push it down.
Bugs a fuzzer would be unlikely to find
Examples Anthropic lists
- ~20 MB input with one rare layout: counter underflow → out-of-bounds write in a bundled decompressor
- 64 MB input and over 2 GB of memory: out-of-bounds read in an image decoder
- Two handles to the same file, called in a particular order: out-of-bounds read
- Deeply nested input: rediscovery of CVE-2026-56132 in libexpat
- No crash at all: a file-loading restriction that was not always enforced
Why the cost should fall
Proofs can take hundreds of millions of tokens today
- Better models: newer models need fewer tokens for the same proof.
- Shared proofs: most of each proof covers code every program contains (C runtime start-up, AddressSanitizer), so teams copy and adapt finished proofs.
- Proven once, reused everywhere: dependencies follow a power law, so verifying a few shared libraries covers a large part of the stack.
- Precedent: Lean’s Mathlib grew to nearly 300,000 theorems from over 700 contributors by building on earlier proofs.
Sources: Anthropic, “LLMs are making formal software verification feasible at a much larger scale” (22 Oct 2026) and its appendix; Theorem roadmap for the Nix ecosystem.
Powered by Thorsten Meyer AI
Could Claude cheat?
If Claude may patch the code it is proving, it could rewrite a program into one that trivially never crashes. Anthropic calls this reward hacking and countered it: every patch was penalized, Claude got extra credit for proving which inputs a patch changes and how few, and patches were logged and audited. That reduces the risk; maintainers still need to review every patch.
Where the proofs stop
Anthropic’s limitations section is the part I would read twice. A proof checker confirms that the program meets the specification. It cannot confirm that the specification matches reality.
- The machine is a model. The proofs cover single-threaded, static RISC-V binaries linked against musl libc. Most people run these libraries on x86 or ARM, dynamically linked against glibc. Closing that gap needs accurate models of the systems people actually deploy.
- The claim is narrower than “safe.” AddressSanitizer does not catch every memory-safety bug. Not every entry point of each library was verified, and verifying all of them would still not cover the whole library, for example dead code.
- Callers can still misuse a library. A proven library can be called incorrectly and corrupt memory in the caller. Fixing that needs a contract for each public function that callers strictly follow.
Anthropic’s phrasing is precise: remaining bugs are either in the trusted components or outside the scope of the proof. That is still a real improvement. You know where to look, and the trusted base does not grow when you verify more projects.
Infographic 03 · What “verified” means here
Proven, assumed, not covered.
A proof checker confirms that the program meets the specification. It cannot confirm that the specification matches the machine you run.
Proven
covered
- No AddressSanitizer crash and no failed assertion
- For every input under 64 MB
- For every modelled Linux response and memory layout
- On the compiled binary, not just the source code
Assumed
trusted base
- The formal models of RISC-V and Linux processes
- The exact theorem statements
- The Rocq proof checker
- Plus the hardware, OS and OCaml compiler Rocq relies on
Not covered
gaps
- x86 or ARM builds dynamically linked against glibc (proofs: single-threaded static RISC-V with musl)
- Memory bugs AddressSanitizer does not detect
- Entry points that were not verified, and dead code
- Callers that misuse the library
“Formally verified” does not mean “bug-free.”Anthropic, 22 Oct 2026. Remaining bugs sit in the trusted base or outside the proof’s scope, and the trusted base does not grow with more projects.
Source: Anthropic, “LLMs are making formal software verification feasible at a much larger scale” (22 Oct 2026), section “Limitations” and footnote 5.
Powered by Thorsten Meyer AI
What this means for software teams
This section is my assessment, not Anthropic’s.
- Your tests become more valuable. The method turns existing fuzz tests into specifications. Projects with good fuzz harnesses and strong assertions are the ones that can be verified cheaply. Writing those harnesses is a good investment now.
- “Verified” needs a label. Expect the word in marketing soon. The useful question is always: which property, on which machine model, under which assumptions?
- Shared dependencies come first. Because proofs are reused per package, the biggest gains come from verifying common libraries once. That is a job for the open-source ecosystem and its funders.
If you maintain an open-source project, there are concrete entry points: Theorem offers to run the same pipeline for other open-source projects and publishes a Claude skill to help developers start verifying their own code, and the proofs and RISC-V and Linux semantics are on GitHub.
Verdict
Anthropic expects formal verification to “soon be as practical as fuzzing is today for almost all production software.” That is a forecast, but the evidence is strong: hundreds of proven entry points, hundreds of bugs, a small trusted base and falling token costs. The open question is how fast the models of real machines can catch up with the machines people run. Until then, a proof here means “no crash on this model, for these inputs.” That is far more than testing ever gave us, and still less than “secure.”
Source
- Anthropic: LLMs are making formal software verification feasible at a much larger scale (Frontier Red Team with Theorem, October 22, 2026), including its appendix
- Published proofs: theorem-labs/oss-verify-proofs; RISC-V and Linux semantics: theorem-labs/rocq-linux-process-semantics
- Theorem: OSS verification offer and roadmap for a verified software stack
- seL4 verification effort: Comprehensive formal verification of an OS microkernel (as cited by Anthropic)
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
