🔍 Read the full analysis: The Boundaries Of Claude’s Formal Verification, Explained 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 Theorem say Claude produced machine-checked proofs that 239 entry points in 123 open-source libraries do not crash for inputs under 64 MB in specified compiled RISC-V builds. The work also found bugs, but it does not prove the libraries are bug-free or establish the same result for the x86 and ARM builds most users run.
Anthropic’s Frontier Red Team and formal-verification collaborator Theorem reported on October 22 that Claude produced machine-checked proofs for 239 fuzz-test entry points across 123 open-source libraries. The proofs cover a specific property: under stated assumptions, compiled RISC-V programs did not crash on inputs smaller than 64 MB, including by triggering an AddressSanitizer memory error or a failed assertion. The result is a large-scale test of whether AI can help verify software, not proof that the libraries are free of bugs.
The team’s method used existing fuzz tests as specifications rather than trying to define correctness for each entire library. Each test was compiled with its library into an instrumented RISC-V executable. Theorem’s formal models described the relevant processor instructions and Linux processes, and Claude generated proofs in Rocq, whose checker verified whether each proof followed from the specification.
According to the report, the proofs amount to about 180 million lines of Rocq. A typical proof was around 600,000 lines, for a binary with a median length of 18,000 RISC-V instructions. Anthropic says the work took a few weeks. It describes the project as, to its knowledge, the first large-scale use of AI for formal verification of production software at compiled assembly-code level.
The effort also exposed bugs, which Anthropic says numbered in the hundreds. Examples included memory errors requiring unusually large inputs or a particular sequence of calls, as well as a logic flaw in a file-loading restriction that did not always crash. The report also describes a rediscovery of CVE-2026-56132 in libexpat. These examples show what the proof process encountered; they do not mean every finding has been independently confirmed here or that every bug class was covered.
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
What the Proofs Can Establish
Fuzzing checks a program against many generated inputs, but it cannot establish that every possible path has been tested. A successful proof can provide a stronger guarantee for the exact program and property described: if its assumptions hold, no input in the specified range causes the instrumented binary to fail in the ways covered by the test.
That distinction matters as software systems grow and vulnerabilities can be difficult to reach through ordinary testing. Anthropic argues that AI may lower some of the labor cost that has kept formal verification uncommon. The project offers evidence that a model can help produce proofs at a scale that would be difficult to review line by line, while a comparatively small proof checker performs the verification.
The result is still bounded. It is a guarantee about a modelled build and a particular test-derived property, not a general certificate of security. Readers and developers should treat the work as a new verification method with a defined scope, rather than as a replacement for testing, review, or security response.
formal verification software tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
From Fuzz Tests to Machine Proofs
Formal verification seeks to prove mathematically that a program satisfies a stated specification. The difficulty is often not just proving the statement, but writing one that captures what the software is supposed to do. Anthropic and Theorem narrowed that problem by reusing fuzz tests already present in the OSS-Fuzz projects. In this setting, the test acts as the specification: for every input within the size limit, the test must not crash.
That approach does not prove a library correct in every use. It proves the chosen test’s stated behavior for the modeled executable. The report says Claude could patch code when a proof attempt exposed a problem, then regenerate the specification and try to prove the revised build. Anthropic is publishing proofs that did not require patching, previously unavailable trusted components, and specifications for fuzz tests it could not prove.
The report places the experiment against the longstanding expense of verification. It cites the seL4 microkernel as an example in which building the system took two person-years and verification took 20. AI-generated proofs could alter that cost, but the reported work does not yet show how economically or reliably the method will scale across other software, teams, or production environments.
“The fuzz test becomes the specification.”
— Anthropic and Theorem, as described in the report
As an affiliate, we earn on qualifying purchases.
Where the Guarantees Stop
The proofs apply to single-threaded, static RISC-V binaries linked against musl, according to the source report. Most users encounter software built for x86 or ARM systems and often linked against glibc. The report does not establish that the same proofs apply to those builds or their runtime environments.
The guarantee also depends on the accuracy of the formal models, theorem statements, and Rocq checker. Anthropic identifies additional trusted components, including hardware, the operating system, and the OCaml compiler used by Rocq. The report does not establish that every dependency or behavior outside the modeled system is covered.
It remains unclear from the supplied material how many reported bug findings were independently validated, how the findings were distributed by severity, or how quickly the method can be repeated for other architectures and libraries. A test-derived proof can also miss defects that the test does not express, including errors that do not trigger its failure conditions.
As an affiliate, we earn on qualifying purchases.
Publication and Broader Testing
Anthropic says it is publishing proofs for cases that did not require code patches, trusted components that were not already public, and specifications for fuzz tests that the team could not prove. Those materials should allow others to inspect the proof setup and assess its assumptions.
The next meaningful test is whether independent researchers and software maintainers can reproduce the results, check the reported bugs, and extend the method to the architectures and build configurations used in deployed software. The source material does not give a timetable for that work or state when wider platform coverage will be available.
As an affiliate, we earn on qualifying purchases.
Key Questions
What did Claude prove?
It produced proofs for 239 fuzz-test entry points in 123 libraries. For the modeled compiled programs, the proofs establish that inputs under 64 MB do not cause the specified test to crash, subject to the stated assumptions.
Does this mean the libraries are bug-free?
No. The proofs cover a defined property derived from each fuzz test, not every possible behavior or defect in the library. The report itself says the project found bugs and describes limits in the systems it modeled.
Why use Rocq?
Claude generated proofs in Rocq, and the Rocq proof checker checked them against formal specifications. This lets the model help construct the proof while a separate checker verifies whether it is valid within the stated formal system.
Do the results apply to software running on ordinary computers?
Not directly. The reported proofs cover single-threaded static RISC-V builds linked against musl. The source does not establish equivalent guarantees for common x86 or ARM builds or for other libraries and runtime configurations.
Source: ThorstenMeyerAI.com
Halloween Picks
halloween
As an affiliate, we earn on qualifying purchases.
