The news. On May 22, 2026, Anthropic published its first Glasswing update, reporting that the program's ~50 partners — Cloudflare, Mozilla, and others — found more than 10,000 high- or critical-severity vulnerabilities in their own infrastructure software in one month using Claude Mythos Preview as a continuous code auditor. Two especially load-bearing per-partner data points: Cloudflare reports 2,000 bugs found (400 high/critical) at an FP rate "better than human testers"; Mozilla's Firefox 150 shipped with 271 vulnerabilities found and fixed via Claude — over ten times Firefox 148. Separately, Anthropic runs its own audit over upstream open-source dependencies and discloses what Claude finds to maintainers: of 23,019 total candidates flagged, 1,752 high/critical were independently reviewed by six security firms (90.6% / 1,587 confirmed as true positives, 62.4% / 1,094 confirmed as high-or-critical). 530 H/C bugs have been disclosed to upstream maintainers; 75 of those have been patched (65 with public advisories). Anthropic's framing: "Progress on software security used to be limited by how quickly we could find new vulnerabilities. Now it's limited by how quickly we can verify, disclose, and patch them."

Picture the metaphor. The old model of vulnerability research was a few ranger lookouts on hilltops, scanning the forest with binoculars; over a month they'd spot maybe a dozen smoke plumes, and the ground crew had time to put each one out, write up the after-action report, and stand down before the next plume. Now a satellite spotter sweeps the entire forest every fifteen minutes and beams down ten thousand red dots — every smoldering pile, every cigarette butt, every campfire. The spotters that own the forest (the partners on their own code) can radio their own crews and put out a lot of the fires themselves — Mozilla literally shipped Firefox 150 with 271 of them already extinguished. But where the spotters find fires on land owned by someone else (Anthropic's audit of upstream OSS), they have to file paperwork with the landowner, wait for the landowner's own crew, and watch the smoke keep rising in the meantime. That second pipeline is the one that's detection-saturated.

What changed is the economics of finding bugs. A bug bounty pays a researcher to spend a week reading code; a critical-severity finding might be worth $20,000 — meaning the marginal cost of one bug, on the human-research path, is days of expert time. A Claude-style audit runs in minutes per package, and each candidate is cheap enough that running the auditor over every dependency on every commit becomes affordable. The 90.6% true-positive rate matters here because a noisy auditor would re-bottleneck on triage: 10× the candidates at 30% TPR would mean reviewers wading through false positives, and the program would collapse back into a "let humans verify each one" pace. At 90.6%, ~9 of 10 reports are real, so the triage step adds minutes per bug rather than days.

The under-appreciated piece is what the new bottleneck actually is — and it depends on who owns the code. When the patcher is in-house (Cloudflare patching Cloudflare; Mozilla patching Firefox), the pipeline can move at the partner's own release cadence; Firefox 150 demonstrates that throughput can be high. But when the patcher is an outside maintainer (Anthropic disclosing to upstream OSS), every fix requires coordinating a CVE ID, notifying maintainers, agreeing on an embargo, and waiting for the upstream's own release schedule — none of which scales at AI speed. Anthropic's own Claude Opus 4.7 patched over 2,100 vulnerabilities in three weeks inside Claude Security, which sets the upper bound for what's possible when the AI also writes the patch on a single owner's codebase. The 75-of-530 OSS number is the lower bound: same auditor, different patcher, an order of magnitude slower.

Where the wall-clock hours actually go

Numbers to make the bottleneck concrete (per Anthropic's first-month report; per-engineer rates illustrative). Take Anthropic's OSS-disclosure pipeline as the cleanest case study, because the patcher is external. The funnel: 530 H/C bugs disclosed to maintainers, 75 patched in roughly one month — a ~7× gap that opened up in the first month and will keep widening unless OSS-maintainer capacity grows. Each unpatched bug sits in a queue that depends on a different organization's release cadence, embargo decisions, and downstream-coordination cost; none of those shorten with a faster detector.

Now the partner side, where the patcher is in-house. Cloudflare has found 2,000 bugs (400 H/C) over the month — roughly 67 finds / day at Cloudflare alone. Even if Cloudflare patches in-house at its own pace, just verifying-and-fixing that flow at 3 bugs per engineer-day (a generous sustained-load figure) requires roughly ~20 dedicated engineers of capacity. Cloudflare appears to have it; smaller partners with thinner security teams face a starker ratio between inflow and verification headcount. The 50-partner program's collective 10,000+ finds in one month is the upper-bound forcing function for how much verification capacity the industry will need to staff as Glasswing-style auditing diffuses outward.

Bottleneck before and after

A small but load-bearing caveat: the 90.6% TPR is on Anthropic's curated 1,752-vulnerability assessment set reviewed by six independent security firms, not on the full open-ended corpus of finds. Real-world TPR almost certainly varies by partner, by language, by codebase shape — the headline is a ceiling, not a contract. The "10,000+" is also a one-month snapshot of the partner program's collective output; whether the rate is sustainable, accelerating, or already plateauing is a question for the next quarterly update.

Goes deeper in: AI Agents → Security & the Lethal Trifecta → Capability Scoping

Related explainers

• PromptArmor — Image-URL exfiltration in Copilot Cowork — the other side of the AI-and-security story: agent UIs as a new attack surface even as agents help find bugs in old surfaces
• Camouflage injection — the detection gap — why catching prompt-injection attacks is harder than catching code vulnerabilities; complements Glasswing's "detection is solved" framing