Anthropic formal verification: what it is and how to use it

Anthropic formal verification is a Frontier Red Team project in which Claude wrote machine-checked proofs that 239 fuzz-test entry points across 123 open-source libraries never crash on any input under 64 MB. You can use it two ways: check the published proofs yourself, or, if you maintain an open-source project, enroll it in Theorem's free OSS Verify program and get proofs, private bug reports and patches back.

The posts

On October 22, @AnthropicAI announced the work, noting that "formal verification can prove that code is free of certain bugs." Until now that only worked on small codebases or with a lot of expert time. The post says Claude did it for over a hundred real libraries in a few weeks.

Less than half an hour later its partner, @theoremlabs, posted "Formal verification at scale is here!" and launched OSS Verify, which proves open-source projects crash-free or sends the patches needed to get there. Theorem cofounder Jason Gross, posting as @diagram_chaser, explained what excites him: "we can section off parts of our software" and treat a verified section as having no more bugs. He calls that asymmetric defense at scale.

What Claude actually proved

The Anthropic write-up explains the method. Many open-source libraries already have fuzz tests, small entry points that tools like Google's OSS-Fuzz hammer with random inputs to look for crashes. The team turned each fuzz test into a formal statement: this compiled program never crashes, fails an assertion or trips a memory-safety check for any input under 64 MB. Claude then wrote the proofs, and the Rocq proof checker confirmed each one.

The proofs are about the compiled RISC-V binary, not the source code, so a compiler quirk can't sneak a bug past them. The total is about 180 million lines of Rocq, with a typical proof around 600,000 lines.

I care more about the bugs than the proofs. A failed proof usually meant a real bug, and Anthropic reports hundreds, including a counter underflow in a decompressor, an out-of-bounds read in an image decoder and a rediscovered libexpat vulnerability. Claude patched the code and proved the new version, with patches penalized and audited so it couldn't game the proof by making a program that does nothing.

On cost, Anthropic says Opus 5.5 proved half of a 36-task test set using about 40% fewer tokens than Opus 5. A full proof can still burn hundreds of millions of tokens, so this isn't something you run on a laptop over lunch.

How to try it

The proofs repo currently holds 60 entry points across 25 libraries, among them openssl, zstd, simdjson, bzip2 and mbedtls. The README walks through checking one (coturn/FuzzStunClient) inside a pinned Docker image with networking turned off. Anthropic is holding back some proofs because they would point to bugs that haven't been patched yet.

To enroll, the oss-verify repo asks a maintainer to:

• fork it and add a projects/<name>/ folder with project.yaml, a Dockerfile and build.sh that produce static riscv64 binaries
• run tools/validate.py, then tools/check --no-shell --twice <name> to confirm two builds come out byte-identical
• open a pull request and fill out the checklist

There's a shortcut: the repo ships a Claude skill and an AGENTS.md, so you can open a coding agent in your checkout and have it do the setup. It asks what "correct" means for your code before it writes anything. Findings go privately to your security contact, and Theorem warns that they are AI-generated and need review before you merge a patch.

My read

This is the natural next step after Anthropic OSS Scanner. The scanner finds bugs, while OSS Verify proves a whole class of bugs is absent from a piece of code. Both write-ups are plain about the limits. A proof is only as good as its spec and its model of the machine, it covers only the code each entry point reaches, and the model is musl on RISC-V while most servers run glibc on x86 or ARM.

The timing is hard to ignore, though. This week's PHP2Shell flaws were found by AI and exploited before the patch shipped. If attackers have the same models, I'd rather have a proof that a parser can't be crashed than another scan report.

What it means for a business

You won't run Rocq. But your website, payment plugins and office software sit on libraries like openssl and zstd, and those libraries are now getting proofs and patches. You only get those fixes if your vendors ship them and someone on your side installs them, and knows which versions you run. Updates can go wrong too: the LiteLLM compromise this week was a poisoned release.

If nobody knows which software your business depends on or who patches it, New Face Design's free process audit is a good place to start that list.