Anthropic’s Work Shows A Connection Between Fuzz Tests And Proofs

🔍 Read the full analysis: Anthropic’s Work Shows A Connection Between Fuzz Tests And Proofs on ThorstenMeyerAI.com

Buying for a business?Offer from Amazon

Get business pricing on monitors, keyboards and dev gear

• 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 collaborator Theorem reported October 22 that Claude proved a no-crash property for 239 fuzz-test entry points in 123 open-source libraries, using proofs checked by the Rocq proof assistant. The work also uncovered hundreds of bugs, according to Anthropic, but its results apply to specific compiled RISC-V programs and stated assumptions—not to every version or use of the libraries.

The team used existing fuzz tests as the basis for formal specifications. Each test was treated as an entry point, and the property to prove was that the compiled program would not crash on any input smaller than 64 MB. In the reported setup, a crash included an AddressSanitizer memory error or a failed assertion. The property is bounded by that input limit and by the modelled system; it does not establish that a program behaves correctly in every respect.

Anthropic and Theorem compiled the libraries and tests into RISC-V executables, with AddressSanitizer instrumentation, and used formal models of RISC-V instructions and Linux processes to generate specifications. Claude produced proofs in Rocq, whose checker tested them against those specifications. When an attempt failed, the failure could point to a possible bug; the team says Claude could patch the code, regenerate the specification and attempt a new proof.

The reported scale was substantial: the proofs total about 180 million lines of Rocq, with a typical proof around 600,000 lines. Anthropic said the work took place over a few weeks. It described the project as, to its knowledge, the first large-scale use of AI for formal verification of production software at the assembly-code level. It says it is publishing successful proofs that required no patching, some previously unpublished trusted components, and specifications for tests it could not prove.

Where Proofs Reach Beyond Fuzzing

Fuzzers test many inputs and use coverage information to explore program behavior, but a finite run cannot establish that every possible input or path has been tested. A successful formal proof can cover all behavior within its stated model and input boundary. That difference helps explain why Anthropic says the work found bugs that existing fuzzing had not reached.

The reported examples include a decompressor issue requiring an input of about 20 MB with a rare layout, an image-decoder read requiring a 64 MB input and more than 2 GB of memory, and a problem dependent on a particular sequence of calls using two handles to the same file. Anthropic also reported rediscovering CVE-2026-56132 in libexpat, which it says requires deeply nested input. These examples illustrate how bugs can sit beyond the inputs commonly exercised by fuzzers; they do not show that every finding would have been impossible to discover through other testing.

The approach also matters because formal verification has traditionally required substantial specialist effort. Anthropic cites the seL4 microkernel project as an example in which verification took far more work than implementation. If models can generate proofs that independent mechanical checkers validate, some verification tasks may become less dependent on line-by-line human review. The reported proof volume is not, by itself, evidence that the method is inexpensive: Anthropic identifies token use and the time required to complete proofs as major constraints.

How Tests Became Specifications

Fuzz testing and formal verification address software reliability in different ways. A fuzz test repeatedly supplies inputs and treats crashes or failed assertions as evidence of a defect. A formal proof instead establishes a property for every execution covered by its specification and model. In this project, the existing test supplied a practical starting point for defining that property, avoiding the need to specify each library’s full intended behavior.

That choice also limits what the results mean. The proven claim is that the particular test entry point does not crash under the defined conditions—not that all features work as intended, that all security weaknesses are absent, or that the software is free of bugs. The source describes a specific environment: single-threaded, static RISC-V binaries linked against musl. Most users may encounter different builds, including x86 or ARM binaries linked against glibc.

The proof checker is only one part of the trust basis. Anthropic says the formal models, theorem statements and Rocq checker are among the components that must be trusted; its account also identifies hardware, the operating system and the OCaml compiler used by Rocq as relevant dependencies. The team’s publication of proofs and specifications is intended to let others inspect parts of that basis, rather than asking readers to trust Claude’s generated text alone.

“The process “discovered hundreds of bugs.””

— Anthropic

Limits of the Proven Builds

The results do not cover the versions most users necessarily run. The reported proofs apply to single-threaded static RISC-V binaries linked with musl, not automatically to x86 or ARM builds using glibc. Whether the same properties hold in those environments remains unestablished by this work.

A no-crash proof also does not rule out every kind of defect. It addresses the behavior encoded by each fuzz test and its formal specification, under the chosen model and input limit. The source gives an example of a file-loading restriction that was not always enforced, a logic flaw that did not itself cause a crash. The broader scope of properties proved across all 239 entry points is not fully detailed in the supplied account.

Cost and completion are also open issues. Anthropic says proof attempts can consume hundreds of millions of tokens, although newer models and reuse of shared proofs can reduce the amount needed. The source does not give a full cost per library, a comparison with the cost of conventional verification, or a complete account of how many attempts failed or remained unfinished. Nor does the provided material specify the disclosure and remediation status of every reported bug.

Published Proofs and Follow-Up

Anthropic says it is publishing proofs that succeeded without code patching, trusted components that were not already public, and specifications for fuzz tests it could not prove. Those materials will allow researchers and software maintainers to inspect the claims, examine the assumptions and assess how much work is needed to reproduce or extend the results.

The next practical test is whether the method can be applied to different architectures and build configurations, and whether its proof costs fall enough to make broader use feasible. The source describes newer models and shared proofs as ways to reduce token demand, but it gives no schedule or quantified target for extending the project. Until such results are reported, the work is evidence of a large AI-assisted verification effort in a constrained setting, not a general certification of the libraries involved.

Key Questions

What did Claude prove?

It proved a defined no-crash property for 239 fuzz-test entry points across 123 open-source libraries: in the modelled setup, the compiled program does not crash on inputs under 64 MB, including through an AddressSanitizer memory error or failed assertion.

Does this mean the libraries are bug-free?

No. The proofs cover a specific property at each test entry point, under stated assumptions. They do not establish that every library feature works correctly or that every class of bug is absent.

Why did the work find bugs fuzzers had missed?

Fuzzers try many inputs but cannot guarantee that they have exercised every possible path. A proof must account for all behavior covered by its specification and model, which can expose defects requiring rare inputs or call sequences.

Do the results apply to the builds people commonly use?

Not automatically. The reported proofs cover single-threaded, static RISC-V binaries linked against musl. Anthropic says they do not establish the same properties for x86 or ARM builds linked against glibc.

What is the main obstacle to using this approach more widely?

Proof cost and completion time remain constraints. Anthropic says some proofs can require hundreds of millions of tokens, while newer models and shared proofs may reduce that demand.

Source: ThorstenMeyerAI.com