Claude writes 180 million lines of machine-checked security proofs

The latest:

Anthropic’s Frontier Red Team said Claude produced machine-checked formal proofs that 239 fuzz-test entry points across 123 open-source libraries exit cleanly on any input below 64 megabytes, with no memory-safety errors or failed assertions. The work, published October 22, 2026 with the firm Theorem, took a few weeks and ran against compiled RISC-V assembly rather than source code.

Details:

• The scale: The proof corpus totals roughly 180 million lines in the Rocq proof language, with a typical single proof running about 600,000 lines, according to Anthropic. The median verified binary contains 18,000 RISC-V instructions, and a single proof may require hundreds of millions of tokens to generate.
• The specification: Anthropic said the team reused fuzz tests already running in OSS-Fuzz projects as formal specifications, the property being that the test never crashes on any input under 64 megabytes. The proofs rely on Theorem’s formal semantics for RISC-V and Linux system calls, with the Rocq checker validating each one.
• The trusted base: Only three components must be trusted for the results to hold, per Anthropic: the RISC-V and Linux process models, the theorem-prover scripts, and the Rocq checker. Everything else in the pipeline is machine-verified rather than assumed correct. The guarantees hold for a statically linked single-threaded binary with a fixed memory budget, running on RISC-V under Linux with musl libc — unlike real machines running x86 and ARM with dynamic glibc linking.
• The bugs: Claude uncovered hundreds of defects that had survived trillions of fuzzing executions, patching them before completing the proofs. Examples include a counter underflow in a decompression tool causing an out-of-bounds write at roughly 20 megabytes of input, and an out-of-bounds read in an image parser needing a 64-megabyte input and over 2 gigabytes of memory.
• The notable finds: One out-of-bounds read required a specific call sequence across two handles to the same file. Claude independently rediscovered CVE-2026-56132 in libexpat, flagged a file-upload restriction that was not consistently enforced, and surfaced a logic bug undetected for more than a decade in several widely used critical implementations. While verifying a widely used PDF reader, it found in one week a number of vulnerabilities comparable to a typical year’s reports against that software.
• Beyond RISC-V: Claude wrote a formal specification of zlib based on RFC 1950 and proved the Linux kernel’s zlib implementation correct at the x86 binary level using x86 semantics it generated itself, repeating the exercise for about six other libraries and finding minor non-exploitable edge-case bugs.
• The Python work: Claude also built an interpreter for a large subset of Python in Rust and verified it with the Verus tool against CPython semantics. Across 1.7 million randomly generated programs, the verified interpreter matched CPython’s behavior in 99.95% of cases.
• Efficiency and gaming: On 36 small verification tasks drawn from OSS-Fuzz, Opus 5.5 proved half of them using about 40% fewer tokens than Opus 5, and agents sharing proofs in one workspace consumed 17% fewer tokens than solo agents. Anthropic penalized patching in its incentives, credited proofs covering inputs a patch changes, and logged and reviewed every patch.
• The benchmark: Anthropic contrasted the result with seL4, the verified microkernel that required two person-years to implement and 20 person-years to formally verify, a cost that confined formal verification to a handful of high-assurance systems.
• What ships: A subset of proofs is on github.com/theorem-labs/oss-verify-proofs, with the RISC-V and OS semantics at github.com/theorem-labs/rocq-linux-process-semantics. Theorem is offering to run the same pipeline for other open-source projects via theorem.dev/oss-verify and is publishing a Claude skill for developers. Proofs that could expose unpatched vulnerabilities are being withheld. Anthropic stressed that formal verification does not mean bug-free code: AddressSanitizer misses some memory-safety errors, not all entry points were verified, and callers who misuse a library can still corrupt memory.

Background:

Formal verification proves mathematically that software cannot enter a failure state, rather than testing it against sample inputs. Its cost has historically kept it to aerospace, defense and a few operating-system kernels, with verification routinely consuming far more effort than writing the code being verified.

Between the lines:

The seL4 comparison carries the argument: 20 person-years for one kernel against a few weeks for 123 libraries. Theorem’s offer to run the pipeline for other projects, plus the published semantics and the Claude skill, points at verification being requested like a pull request rather than budgeted as a multi-year program. The withheld proofs also show a disclosure problem arriving with it — a proof can point straight at an unpatched hole.

What’s next

Watch how many open-source projects take up Theorem’s offer, whether the published RISC-V and Linux semantics hold up under outside scrutiny, and whether the approach extends to x86 and ARM binaries with dynamic glibc linking.