Claude’s Formal Verification Work Offers A New View Of Fuzz Testing

🔍 Read the full analysis: Claude’s Formal Verification Work Offers A New View Of Fuzz Testing on ThorstenMeyerAI.com

Buying for a business?Offer from Amazon

Get business pricing on tech for your team

• Business-only prices and quantity discounts
• Tax-exempt purchasing
• Multiple users, one account, clear invoices

Create a free Business account →Free to register

As an affiliate, we earn on qualifying purchases.Hide

Anthropic’s Frontier Red Team and formal-verification company Theorem say Claude proved a defined no-crash property for 239 fuzz-test entry points in 123 open-source libraries, checking compiled RISC-V programs with the Rocq proof assistant. The team also reports finding hundreds of bugs, including cases it says conventional fuzzing had missed; the proofs cover specific builds and assumptions, not all versions or configurations of the libraries.

The reported property is specific: for each verified entry point, the compiled program does not crash on any input under 64 MB under the team’s formal model. The property rules out AddressSanitizer-detected memory errors and failed assertions in the modeled execution. It does not establish that the software behaves correctly in every respect, or that every bug has been removed.

Anthropic and Theorem converted existing fuzz tests into specifications for compiled programs. They compiled each library and its test to a RISC-V executable, instrumented it with AddressSanitizer, and used formal models of RISC-V instructions and Linux processes. Claude generated proofs in Rocq; Rocq’s checker then checked those proofs against the specifications. When proof attempts exposed failures, the team could use them to identify possible bugs, patch code, regenerate specifications and try again.

The reported scale was substantial: the proofs total about 180 million lines of Rocq, produced over a period of a few weeks. Anthropic says a typical proof was about 600,000 lines and covered a binary with a median length of 18,000 RISC-V instructions. The company says it is publishing proofs that did not require patches, certain trusted components that were not already public, and specifications for tests it could not prove.

How Proofs Extend Fuzz Testing

Fuzzing tests software by supplying many generated or modified inputs and looking for failures. It can reveal serious flaws, but testing a sample of inputs cannot by itself establish that all inputs within a defined range are safe. Formal verification takes a different approach: a checked proof can establish a property across every input represented by its specification and model.

That difference may help explain why the project reports finding bugs that ordinary fuzzing had not reached. Anthropic describes issues requiring large inputs, unusual data layouts or sequences of calls across multiple file handles. It also reports rediscovering CVE-2026-56132 in libexpat and finding a logic flaw involving a restriction on which files an application could load. These are findings reported by the project; the published account does not mean every reported issue has been independently assessed here.

The work matters because formal verification has traditionally required substantial specialist effort. Anthropic cites the seL4 microkernel as an example of the cost, reporting two person-years to build and 20 person-years to verify. If AI can reduce the labor required to create proofs, developers may be able to apply machine-checkable guarantees to more existing code. The reported token use and proof workload, however, show that generating and checking proofs still has significant costs.

From Existing Tests to Machine-Code Proofs

A fuzz test gives the verification process a limited, concrete target. Rather than trying to define every aspect of a complex library as “correct,” the team reused each test’s behavior and asked whether its compiled execution could crash under the specified conditions. This makes the result meaningful but bounded: it proves the chosen property for the modeled program, not that the original library satisfies every possible security or functional requirement.

The distinction between tested source code and verified compiled code is central to the report. The proofs were for single-threaded static RISC-V binaries linked against musl. Anthropic’s account says this differs from common x86 or ARM builds linked against glibc. Results for one modeled binary therefore cannot automatically be transferred to other architectures, libraries or build settings.

The proof checker reduces the amount of generated material people must inspect, according to Anthropic. The company says the key trusted pieces are the formal models, the theorem statements and Rocq’s checker, while also identifying underlying dependencies such as hardware, the operating system and the OCaml compiler. Machine checking can make a large proof tractable to validate, but confidence still depends on whether the specification and trusted components accurately represent the system being assessed.

“The property is that the test does not crash for any input under 64 MB.”

— Anthropic, describing the scope of its result

What the Proofs Do Not Cover

The reported guarantees apply only to the specified entry points, inputs, binaries and execution model. The source account does not establish that the same properties hold for the libraries’ commonly deployed x86 or ARM builds, for builds linked against glibc, or for multithreaded execution. Nor does a no-crash proof rule out errors that do not trigger the modeled checks.

Anthropic says some proof attempts did not finish and that it is publishing specifications for tests it could not prove. The account does not give a complete breakdown of how many attempted proofs succeeded, failed or remained unresolved, or provide a per-library accounting of the reported bugs. It also says proof generation could consume hundreds of millions of tokens, while newer models and shared proofs can reduce the workload. How consistently those savings apply is not established by the reported results.

A proof is only as broad as its specification and assumptions. The work’s security value therefore depends on whether the selected tests capture the property users care about, whether the formal models match real execution, and whether the checked build corresponds to the software people deploy.

Publication and Broader Testing

Anthropic says it is releasing the proofs that required no code patches, trusted components that were not already public, and specifications for fuzz tests it could not prove. Those materials can allow researchers and developers to examine the proof assumptions and assess how readily the approach can be applied to other code.

The next practical questions are whether the method can cover more libraries and real-world build configurations, and whether its computational cost can fall enough for routine use. The reported work is a demonstration across a defined set of entry points; broader claims will require results across additional architectures, toolchains and software properties. The source account does not specify a schedule for that work.

Key Questions

What did Claude prove?

Anthropic and Theorem say Claude generated Rocq proofs that 239 fuzz-test entry points in 123 libraries do not crash for inputs under 64 MB in the modeled compiled programs. The property includes no AddressSanitizer memory error and no failed assertion, subject to stated assumptions.

Does this mean the libraries are bug-free?

No. The proofs cover a defined no-crash property for selected entry points and builds. They do not prove that every feature works correctly, that all bugs are absent, or that other configurations have the same guarantees.

How is formal verification different from fuzzing?

Fuzzing tests many generated inputs and searches for failures. A formal proof can establish a specified property for all inputs represented by its model, rather than only the inputs a testing run happens to reach.

Which software builds were covered?

The report covers single-threaded static RISC-V binaries linked against musl. It does not establish the same results for the x86 or ARM builds linked against glibc that are commonly used.

What remains uncertain about the project?

The report does not give a full outcome count for all attempted proofs or a complete breakdown of the reported bugs. The cost of proof generation, coverage of other build configurations and the suitability of these properties for routine deployment also remain open questions.

Source: ThorstenMeyerAI.com