AI Security Scanners Move the Bottleneck to Triage

Official Sources#

Anthropic's Project Glasswing update is not just a cyber story. It is a developer workflow story.

The headline number is large: Anthropic says Claude Mythos Preview and roughly 50 partners found more than ten thousand high- or critical-severity vulnerabilities. (If you missed the launch itself, our Claude Mythos Preview explainer covers the model, the pricing, and the Glasswing access model.) The more useful sentence is quieter: progress used to be limited by finding vulnerabilities, and is now limited by verification, disclosure, patch design, and deployment.

That is the category shift.

We already know coding agents can produce more code than teams can review. Now security agents are starting to produce more findings than maintainers can process. The same lesson from agent swarms needing receipts applies to security: throughput without triage discipline creates a queue, not safety.

Finding Is Getting Cheaper#

Anthropic says Project Glasswing partners have found hundreds of high- or critical-severity issues each, and that Cloudflare found 2,000 bugs across critical-path systems, including 400 high- or critical-severity findings. Anthropic also says it scanned more than 1,000 open-source projects and estimated 6,202 high- or critical-severity vulnerabilities.

The important nuance is that these are not all equally confirmed.

Anthropic reports that 1,752 high- or critical-rated open-source findings were assessed by external security research firms or Anthropic, with 90.6% proving to be valid true positives and 62.4% confirmed as high or critical severity. That is strong signal, but it still leaves a large operational gap between "model found something" and "users are safer."

The HN discussion around the post went straight to that gap. Commenters asked whether the numbers represented suspected or actual vulnerabilities, whether other frontier models plus a coordinated program could produce similar results, and whether withheld model access makes the evidence hard to reproduce. That skepticism is healthy.

The right response is not to dismiss the results. It is to separate three steps:

1. Candidate discovery.
2. Human or tool-assisted validation.
3. Patch delivery and uptake.

AI is improving step one fastest. Most organizations are still weak at steps two and three.

The New Queue Is Maintainer Attention#

Anthropic says maintainers are capacity constrained, some have asked them to slow disclosures, and a high- or critical-severity bug found by Mythos Preview takes about two weeks to patch on average. It also says only 75 of the 530 reported high- or critical-severity bugs had been patched at the time of the update.

That is not a failure of the model. It is a reminder that software security is a system.

If AI security scanning becomes cheap, every serious engineering organization needs a finding intake lane:

• reproduce the issue,
• verify exploitability,
• assign severity,
• identify owner,
• design the smallest patch,
• run regression tests,
• coordinate disclosure if external users are affected,
• ship and verify deployment.

That is less exciting than a model demo, but it is where the risk gets reduced.

This is the same operational shape as Codex cloud security: the model can work faster, so the policy and review path has to become more explicit.

AI Bug Reports Need Receipts#

Maintainers already deal with low-quality AI-generated reports. Anthropic explicitly calls that out. This is the part developer teams should internalize.

A vulnerability report from an AI system should not arrive as a confident paragraph. It should arrive as a compact packet:

• affected component and version,
• reproduction steps,
• minimal proof of impact,
• suspected root cause,
• false-positive checks performed,
• proposed patch or mitigation,
• tests added or suggested,
• disclosure status.

Without that packet, AI security tooling can make maintainers slower. A scanner that emits plausible but under-specified findings transfers work to the human queue.

The practical bar should be close to a pull request. If the agent cannot reproduce the bug, isolate the impacted path, and explain the fix boundary, the finding should be labeled as unverified triage input.

What Teams Should Do Now#

Do not wait for Mythos-class models to be broadly available before changing your workflow.

Start with generally available tools and process:

1. Run AI-assisted security scans on code you own.
2. Keep generated reports out of public issue trackers until a human verifies them.
3. Require a reproduction and patch hypothesis before escalating.
4. Track false positives and time-to-fix, not just findings.
5. Put security scans in the same receipt culture as coding agents.

This is also where prompt injection and secrets handling stop being abstract topics. If a security agent can inspect your repo, run tools, fetch dependencies, and propose patches, it needs scoped credentials, logs, and review just like any other agent.

The Take#

The bullish take is that AI security agents can help defenders finally get ahead of bug discovery.

The skeptical take is that they can flood maintainers with more work, unverifiable claims, and disclosure pressure.

Both can be true.

The winning teams will treat AI security scanning as a triage pipeline, not a magic scanner. The model finds candidates. The system validates, patches, and ships. Until that second half is real, the bottleneck has only moved.

FAQ#

What is the AI security triage bottleneck?#

The AI security triage bottleneck is the operational constraint that emerges when AI security scanners can find vulnerability candidates faster than human teams can verify, disclose, patch, and deploy fixes. Anthropic's Project Glasswing found over 10,000 high- or critical-severity vulnerabilities, but only 75 of 530 reported high- or critical-severity bugs had been patched at the time of their update. The bottleneck has shifted from finding vulnerabilities to processing them through verification, patch design, and deployment.

Why do AI security scanners create more work for maintainers?#

AI security scanners can generate large volumes of findings that require human verification before action. Each finding needs reproduction, exploitability assessment, severity assignment, owner identification, patch design, regression testing, and coordinated disclosure. Without structured triage processes, AI-generated security reports can flood maintainers with under-specified findings that transfer work rather than reduce it.

What should an AI-generated vulnerability report include?#

A quality AI-generated vulnerability report should include: the affected component and version, reproduction steps, minimal proof of impact, suspected root cause, false-positive checks performed, proposed patch or mitigation, tests added or suggested, and disclosure status. Without this packet, findings should be labeled as unverified triage input rather than actionable security work.

How accurate are AI security findings?#

According to Anthropic's Project Glasswing update, 1,752 high- or critical-rated open-source findings were assessed by external security research firms or Anthropic, with 90.6% proving to be valid true positives and 62.4% confirmed as high or critical severity. This strong signal still leaves an operational gap between "model found something" and "users are safer" that requires human verification and patch delivery.

What is receipt culture for security agents?#

Receipt culture for security agents means requiring a compact packet of evidence - reproduction steps, proof of impact, and patch hypothesis - before escalating a finding. This mirrors the approach needed for coding agents: throughput without triage discipline creates a queue, not safety. Security scans should produce verifiable artifacts, not confident paragraphs.

How long does it take to patch AI-discovered vulnerabilities?#

According to Anthropic's Project Glasswing data, a high- or critical-severity bug found by Mythos Preview takes about two weeks to patch on average. Some maintainers have asked Anthropic to slow disclosures because they are capacity constrained. This time-to-patch metric is more important than raw finding counts for measuring actual security improvement.

How should teams prepare for AI security scanning?#

Teams should: run AI-assisted security scans on code they own, keep generated reports out of public issue trackers until human verification, require reproduction and patch hypothesis before escalating, track false positives and time-to-fix rather than just findings, and apply the same receipt culture to security scans as to coding agents.

Why does AI security scanning need scoped credentials and logs?#

If a security agent can inspect your repo, run tools, fetch dependencies, and propose patches, it needs the same security controls as any other agent. Scoped credentials limit blast radius, logs enable audit trails, and review processes catch prompt injection or secrets exposure. This connects AI security scanning to broader agent security practices.

Sources#

• Anthropic: Project Glasswing: An initial update
• Hacker News: Project Glasswing discussion
• NVD: CVE-2026-5194