🔍 Read the full analysis: Understanding What Claude’s Fuzz Tests And Formal Proofs Can Establish on ThorstenMeyerAI.com
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
TL;DR
Anthropic’s Frontier Red Team and collaborator Theorem reported that Claude produced Rocq-checked proofs for 239 fuzz-test entry points across 123 open-source libraries. The proofs establish a defined no-crash property for specific compiled RISC-V programs under stated assumptions; they do not show that the libraries are bug-free or prove the behavior of the x86 and ARM builds most users run.
Anthropic’s Frontier Red Team and collaborator Theorem reported October 22 that Claude helped prove a defined no-crash property for 239 fuzz-test entry points in 123 open-source libraries. The proofs were checked with Rocq against compiled RISC-V programs, and the team says the process found hundreds of bugs; the result applies only to the modeled programs and conditions, not to every version or use of those libraries.
The property proved was specific: for each entry point, the compiled program would not crash on any input smaller than 64 MB, under the project’s stated assumptions. A crash included an AddressSanitizer memory error or a failed assertion. The work does not establish that a library is free from all defects, nor that it behaves correctly in every respect.
The team reused existing fuzz tests as specifications. It compiled the library and test into an instrumented RISC-V executable; Claude then generated proofs in Rocq, a proof assistant whose checker mechanically verifies whether a proof follows from its specification. When proof attempts exposed a possible bug, Claude could patch the code and attempt a proof against a regenerated specification.
Anthropic said the proofs comprise about 180 million lines of Rocq, with a typical proof around 600,000 lines. The company’s account says those lines did not require human review: confidence instead rests on the theorem statements, the formal models of RISC-V instructions and Linux processes, Rocq’s checker, and other supporting components. Anthropic said it is publishing unpatched proofs, certain trusted components and specifications for fuzz tests it could not prove.
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
Where Proofs Add to Fuzzing
Fuzzing tests many inputs, but it cannot generally show that every possible input has been tried. A proof of the stated property instead covers all inputs in the modeled range and all paths the model includes. That distinction helps explain why the team says the work surfaced defects that earlier fuzzing had not found, including bugs requiring unusually large or carefully structured inputs.
Examples in the source account include a decompressor issue requiring an input of about 20 MB with a rare layout, and an image-decoder read issue involving a 64 MB input and more than 2 GB of memory. Another reported issue depended on a particular sequence of calls involving two handles to the same file. The team also cited a logic flaw in a file-loading restriction that did not necessarily cause a crash. These examples show both the reach and the boundary of the method: the proofs concern specified properties, while bug discovery can arise during attempts to establish them.
The approach addresses a longstanding cost problem in formal verification. Anthropic contrasts the work with the effort associated with verifying seL4, a microkernel, and argues that language models may reduce the human labor needed to write proofs. The reported experiment is evidence of a large application, not proof that verification is now inexpensive in general: the source says some proofs can consume hundreds of millions of tokens.
As an affiliate, we earn on qualifying purchases.
From Fuzz Tests to Rocq
In ordinary fuzzing, software receives many generated or mutated inputs, and a crash is treated as evidence of a defect. Coverage-guided fuzzers can be effective, but their results depend on the inputs and paths they reach. The Anthropic-Theorem process took an existing fuzz-test entry point and treated its behavior as the target specification, rather than attempting to define all possible meanings of “correct” for an entire library.
The team compiled each target for RISC-V and linked it against musl, with AddressSanitizer instrumentation. Theorem supplied formal models of the relevant machine instructions and Linux process behavior; Claude generated Rocq proofs against the resulting specifications. The checker validates proof steps, but the conclusions remain dependent on the correctness and scope of the models and theorem statements.
Anthropic characterized the effort as, to its knowledge, the first large-scale use of AI for formal verification of production software at assembly-code level. That is the company’s characterization of the work. The reported target set was 123 libraries from OSS-Fuzz, and the experiment ran over a period of a few weeks.
“To our knowledge, the first large-scale use of AI to apply formal verification to production software at the assembly code level.”
— Anthropic, describing the experiment
AddressSanitizer memory error detector
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Limits of the Verified Builds
The proof scope does not cover every configuration people use. The reported binaries were single-threaded, static RISC-V builds linked against musl; the source says most users encounter x86 or ARM builds linked against glibc. It is not established that the same properties hold for those builds, or for different compiler settings, dependencies or runtime environments.
“No crash” is also narrower than “no bug.” The property covers AddressSanitizer memory errors and failed assertions in the specified test, but does not establish the absence of every security weakness, incorrect result or harmful behavior. The report itself describes a logic bug that did not necessarily crash. The source material also does not give a complete public accounting of all discovered bugs, their severity, or how many were independently confirmed and fixed.
The practical cost remains uncertain. Anthropic reports very large proof artifacts and says proof generation can use hundreds of millions of tokens, while newer models and reusable proofs may reduce that burden. The reported experiment does not by itself establish the cost, speed or reliability of applying the approach across a much broader software ecosystem.
As an affiliate, we earn on qualifying purchases.
Published Proofs and Wider Testing
Anthropic said it would publish the proofs that required no patches, trusted components that were not already public, and specifications for fuzz tests it could not prove. Those materials give researchers a way to examine the stated properties, proof artifacts and supporting assumptions. The source account does not specify a full publication schedule or establish that every artifact is already available.
The next technical question is whether the method can be repeated at lower cost and extended to additional software builds and properties. Independent review of the proofs, models and reported bugs will help clarify how much confidence the results support beyond the exact RISC-V binaries. Until those checks and broader applications are reported, the finding is best read as a substantial experiment in proving a narrow class of software behavior—not as certification that the covered libraries, or their commonly deployed versions, are safe.
fuzz testing tools for open-source libraries
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Key Questions
What did Claude prove?
It helped produce Rocq-checked proofs that 239 specified fuzz-test entry points in compiled RISC-V programs would not crash on inputs under 64 MB, under the project’s assumptions. This is a narrow no-crash property, not proof that the libraries have no bugs.
Does this mean the libraries are bug-free?
No. The proofs cover the behavior stated in each specification, including defined crash conditions. They do not establish the absence of every logic flaw, security issue or incorrect output. The reported work itself included a file-loading logic bug that did not necessarily cause a crash.
Why can a proof find bugs fuzzing missed?
Fuzzing samples inputs and execution paths, while a completed proof must account for every path represented by its model and specification. That can expose rare cases involving large inputs or particular call sequences, though it does not mean every proof attempt will finish or find a defect.
Do the results apply to software people use on PCs and phones?
Not directly. The reported proofs cover single-threaded, static RISC-V builds linked against musl. The source says common deployments use x86 or ARM with glibc, and the report does not establish that the same proofs apply to those configurations.
What will show whether this approach is practical?
Public release and independent examination of the proof artifacts and trusted components will help. Further results would also need to show whether proof costs fall, whether more properties and software configurations can be covered, and how reported bugs are confirmed and addressed.
Source: ThorstenMeyerAI.com
Halloween Picks
halloween
As an affiliate, we earn on qualifying purchases.
