🔍 Read the full analysis: Anthropic’s Claude Research Offers A New Angle On Software Proofs on ThorstenMeyerAI.com
Get the latest gadgets delivered free with Prime
- Fast, free delivery on millions of items
- Prime Video, Amazon Music and more included
- Member-only deals all year
TL;DR
Anthropic’s Frontier Red Team and collaborator Theorem say Claude produced Rocq-checked proofs that 239 fuzz-test entry points across 123 open-source libraries do not crash under specified conditions. The work also exposed bugs, but the proofs apply to particular compiled RISC-V binaries and do not establish that the libraries are bug-free.
Anthropic’s Frontier Red Team and collaborator Theorem reported on October 22 that Claude proved a no-crash property for 239 entry points in 123 open-source libraries, with the proofs checked by the Rocq proof assistant. The work applies to specific compiled programs and inputs under 64 megabytes; it is not a general guarantee that the libraries are free of bugs. The effort also found bugs that the teams say existing fuzzing had missed.
The team took fuzz tests—programs that feed libraries inputs and treat a crash as a failure—and used them as the basis for formal specifications. The libraries and tests were compiled into RISC-V executables and instrumented with AddressSanitizer. Claude then generated proofs in Rocq, whose checker tested whether each proof followed from the specification and formal model. In the stated configuration, the property is that the program does not crash for any input under 64 MB, including no AddressSanitizer memory error or failed assertion.
Anthropic said the work covered 239 entry points across 123 OSS-Fuzz libraries and produced about 180 million lines of Rocq proof. A typical proof was about 600,000 lines, for a binary with a median length of 18,000 RISC-V instructions. Anthropic described the project as, to its knowledge, the first large-scale use of AI to formally verify production software at the assembly-code level. That is the company’s characterization of the work, not an independently established industry-wide finding.
The process also surfaced hundreds of bugs, according to Anthropic. Reported examples include memory-access errors requiring unusually large or carefully structured inputs, and a bug involving a sequence of calls across two file handles. The source also describes a logic error in a feature intended to restrict which files an application could load. These are findings reported by the team; the material does not give a complete breakdown of confirmed fixes or independent validation for every issue.
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
Proofs Reach Compiled Library Code
The result matters because it tests whether AI can help make formal verification more practical, rather than only generating code or finding likely defects. Conventional fuzzing tries many inputs, but a successful test campaign cannot establish that every possible input has been tried. A machine-checked proof can establish a property across all inputs within the exact model and conditions stated.
That distinction could affect how software teams evaluate safety claims. Anthropic argues that AI-generated proofs can reduce the human effort involved in verification, a field historically known for high costs. The scale reported here is notable, but the work does not show that verification is now cheap in general: the source says some proofs required hundreds of millions of tokens. Nor does proving the selected no-crash property establish that a program behaves correctly in every other respect.
As an affiliate, we earn on qualifying purchases.
From Fuzz Tests to Specifications
Fuzzing is widely used to find software faults by supplying programs with random or altered inputs. It can uncover crashes and other failures, but it samples behavior rather than proving that every reachable path is safe. The approach described by Anthropic and Theorem starts with existing fuzz-test entry points and treats each test’s crash conditions as a property to prove for the compiled program.
Formal verification has traditionally demanded substantial specialist work. Anthropic cites the seL4 microkernel as an example, saying its development took two person-years and its verification took 20. The new project shifts much of the proof-writing work to Claude while relying on a separate checker. The company says the trusted base includes the formal models of RISC-V instructions and Linux processes, the theorem statements, and Rocq’s checker, along with supporting hardware and software components.
Anthropic said it is publishing proofs that did not require code patching, components of the trusted base that were not already public, and specifications for fuzz tests it could not prove. This material may let outside researchers inspect parts of the method, though publication alone does not establish that the full system or every result has been independently reproduced.
AddressSanitizer compatible software tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
The Proofs Have Firm Boundaries
The central limitation is scope. The proofs cover single-threaded, static RISC-V binaries linked against musl, not necessarily the x86 or ARM builds linked against glibc that most users run. The guaranteed property is also narrow: no crash under the stated test, instrumentation, input-size limit, and model assumptions. It does not rule out all logic errors, security vulnerabilities, failures in other configurations, or harmful behavior that does not trigger a crash.
The source does not specify how many reported bugs have been fixed, how many were independently confirmed, or whether the proofs have been reproduced by outside groups. It also says proof generation can consume hundreds of millions of tokens, while newer models and shared proofs may reduce that cost. The size and practical economics of future verification efforts remain unsettled.
formal verification software tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Publication and Independent Checks
Anthropic says it is releasing selected proofs, additional trusted components, and specifications for tests that the system could not prove. Those materials create an opportunity for researchers and software maintainers to inspect the assumptions, checker outputs, and reported defects. The source does not announce a schedule for broader coverage or independent replication.
The next meaningful tests are whether other teams can reproduce the results, whether maintainers fix the reported bugs, and whether the method can cover more architectures and ordinary build configurations at a manageable cost. Until then, the reported proofs are evidence for specific properties of specific binaries—not a blanket certification of the libraries.
As an affiliate, we earn on qualifying purchases.
Key Questions
What did Claude prove?
According to Anthropic and Theorem, Claude produced Rocq-checked proofs that 239 fuzz-test entry points do not crash for inputs under 64 MB in the specified compiled setup. The property includes no AddressSanitizer memory error or failed assertion.
Does this mean the 123 libraries are bug-free?
No. The proofs cover a defined no-crash property under specific assumptions and configurations. They do not establish that every library behavior is correct or that every vulnerability has been found.
What bugs did the project find?
Anthropic says the effort found hundreds of bugs, including memory-access issues tied to large or unusual inputs and a logic flaw in a file-loading restriction. The source does not provide a full accounting of fixes or independent confirmations.
Why use Rocq to check Claude’s work?
Claude generated the proofs, while Rocq’s checker verified that they followed from the formal specifications and models. This separates proof generation from the mechanical checking used to validate each proof.
Do the results cover software people commonly run?
Not necessarily. The reported proofs concern single-threaded static RISC-V binaries linked against musl. Anthropic says they do not directly cover the x86 or ARM builds linked against glibc that many users rely on.
Source: ThorstenMeyerAI.com
Halloween Picks
halloween
As an affiliate, we earn on qualifying purchases.
