Anthropic and Theorem verify 123 open-source libraries with 180 million lines of proof, turning up more than 100 bugs fuzzing missed

Anthropic's Frontier Red Team has worked with Theorem, a formal verification company, to mathematically prove security-relevant properties of 123 open-source libraries. The proofs were done against the assembly that actually runs, not the source code, and total about 180 million lines. While building them, the team found more than 100 bugs that fuzzing had not caught (Anthropic research page, primary source).

Over the past month, most news about AI in cyber defense has been about finding holes: the number of vulnerabilities Claude Mythos found, OpenAI's PHP2Shell, Glasswing's 129,000 verified findings. This announcement goes the other way. Wherever a proof goes through, that class of hole can be said not to exist. AI-driven defense is starting to expand from finding and patching holes to proving that there are none.

What they did: 123 libraries, at the assembly level, 180 million lines

The targets were 123 open-source libraries. The team proved that each library satisfies security properties, and did so at the level of the assembly compiled from the source code. Proving things at the assembly level also covers cases where compiler optimizations or the handling of undefined behavior make the machine's behavior differ from what the source means. Verifying only the source leaves that gap as an assumption.

No human team could write 180 million lines of proof by hand. For comparison, Anthropic previously reportedly used Lean to formalize Fermat's Last Theorem, writing 13 million lines in 11 days (a figure Thomas Hales cited on Tao's blog). The new work is more than ten times that size, and it targets 123 libraries in real-world use rather than a single theorem. For a long time, formal verification was an expensive technique reserved for a few flagship projects such as seL4 and CompCert. By having a model write the proofs, the work brings it into mass production.

A byproduct of proof: more than 100 bugs fuzzing missed

While building the proofs, the team found more than 100 bugs that fuzzing had not caught. The logic is simple. A proof that buggy code is correct will not go through. Examine where the proof gets stuck, and you find the bug.

Fuzzing is a probabilistic technique: it throws inputs at a program and looks for where it crashes. Rarely taken branches and defects that appear only when specific conditions line up tend to survive it. A proof covers every possible input, so these gaps don't arise. The 100-plus bugs put a number on the limits of fuzzing (OSS-Fuzz and similar tools), which has long been treated as a baseline for open-source security.

Frontier Red Team's third defensive approach

The announcement is easiest to understand alongside the defensive measures Frontier Red Team has released over the past few weeks.

Find: OSS Scanner (October 8)

Anthropic Cyber Mission's OSS Scanner scans projects that opt in, for free, using its strongest models, including Mythos. A six-month trial produced more than 29,000 candidate findings. But this approach can only report how many holes it found. It cannot say that none remain. The fact that reports reach maintainers without passing through a human has also been debated, because it adds to maintainers' workload.

Reduce: attack surface reduction (October 20)

The October 20 report catalogued the configuration options of 25 projects and removed unnecessary code paths reachable before authentication. In OpenSSH, about 4,500 lines, or 16% of the pre-authentication code, were made unreachable. Rather than hunting for holes one at a time, this approach shrinks the amount of code that can be attacked at all.

Prove: this announcement

This step shows that the code that remains has no holes. Finding, reducing and proving complement one another. Reducing the attack surface narrows what has to be proved, and the places where a proof gets stuck point to bugs that need to be found. Frontier Red Team has been known for work that measures offensive capabilities, such as self-replication experiments and its analysis of GLM-5.3. This is the clearest picture yet of how it is turning those capabilities toward defense.

What determines a proof's worth: what was assumed and what was shown

The value of formal verification, however, depends on which properties were proved and under what assumptions. The figure of 180 million lines alone does not tell you that.

First, there is the question of the specification. A proof guarantees only that the code meets the specification as written. Proving a property such as memory safety does not cover logic flaws the specification leaves out, or misuse of cryptography. Second, there is the question of whether the verifier itself can be trusted. In a guest post on Tao's blog on October 9, Hales pointed to a series of soundness bugs found in Lean's kernel in the summer of 2026 (the "Summer of Soundness Bugs") and proposed cross-checking proofs against several independent kernels. No human can read 180 million lines of model-written proof. Whether they can be trusted depends on the small core that checks them, and on whether the model defining the semantics of assembly is correct.

As of this writing, this newspaper has not been able to fully confirm which proof system was used, the exact scope of the properties proved, which Claude model was used, or whether the proofs and fixes will be published. These are the three points readers should look at when assessing the work.

What it means: "guarantee" enters the vocabulary of AI defense

In the contest between attacking AI and defending AI, defenders have generally been seen as at a disadvantage. Defenders have to close every hole, while attackers need to find only one. Epoch has estimated that open-weight models lag closed models by six to seven months in cyber capability. That gap will eventually close. If the contest is only about finding holes, defenders will keep being chased by that speed.

Proofs change that dynamic. Wherever a proof goes through, no attacking model, however capable it becomes, will find that class of hole. And if AI-written proofs are checked by a machine, there is no need to trust the AI's output itself. The 123 libraries are still a small slice of open source as a whole. Even so, at a scale of 180 million lines, the work shows that having a model mass-produce proofs makes it possible to apply formal verification to real-world software.