With Mythos 5, Discovery Got Faster. Closure Didn't.

On August 21, 2026, Anthropic brought Claude Mythos 5, the model it held back from public release, into Claude Security and made it available in public beta to enterprise customers for vulnerability discovery and patch generation. It also announced a $35 million Defender Advantage Fund to find and patch vulnerabilities in open source software.

That's a real gain for defenders, and it makes an existing problem larger.

We measured this exact pipeline

Tuskira Research spent 63 days watching the AI-driven disclosure program behind Mythos.

In our May 22, 2026 snapshot, AI-driven vulnerability discovery outpaced visible Mythos-attributed remediation by approximately 16.5x. One pipeline disclosed 1,596 verified vulnerabilities across 281 open source projects. Roughly 95% of them had no public advisory at the time of the snapshot. Maintainers acknowledged 90.9% of reports at a median of 0.2 days, but only 6.1% were patched in response within the window.

Now put $35 million in credits behind that pipeline.

The report is deliberate about what it doesn't claim. It doesn't say coordinated disclosure is broken, that every disclosure is exploitable, or that CVE, SCA, SAST, CNAPP and vulnerability management tools are obsolete. The claim is narrower: AI-driven discovery is creating a timing and capacity mismatch that advisory-led workflows can't resolve on their own.

Two questions follow every finding

A Mythos 5 result, a Qualys scan, a Wiz finding, a CNAPP alert, an EDR detection: each one arrives at the same place.

Is this reachable and undefended in my environment? And what closes it?

Neither answer depends on which tool or model produced the finding. That's what keeps the work durable as the discovery layer keeps changing.

Governing how the models get used

At Black Hat USA 2026 we launched the Agentic Control Plane for Exposure Management, which extends our exposure-response work to frontier-model scanning. It runs a four-stage loop.

Orchestrate. Route customer-authorized frontier models to the appropriate repositories and risk tiers, and normalize what they find alongside legacy VM, SAST, SCA and cloud findings.

Govern. Enforce model selection, repository and data scope, spending limits, approval workflows and retention policies, with a complete audit trail of what was scanned, by which model and why.

Contextualize. Determine whether vulnerable code is deployed, reachable, undefended and connected to a breach path.

Respond and verify. Apply approved compensating controls through WAF, EDR, IAM or network policy, route the durable code fix, and re-test the modeled path to prove closure.

The Govern stage is the one worth dwelling on with Mythos 5 in the picture. Which repositories are in scope, which model handles which tier of code, what a scan costs, who approves it, and how long a provider keeps what you sent are all enterprise decisions. They belong upstream of the scan and evidenced afterward, not reconstructed from a bill at the end of the quarter.

The funnel

Everything comes in at the top: findings from vulnerability management tools, cloud security platforms and endpoint tools, plus the state of the infrastructure and the compensating controls already deployed, including endpoint protection, cloud detection and response, web application firewalls, next-generation firewalls and network rules.

Two problems with the top of that funnel. There's guaranteed overlap between sources, so the same issue arrives more than once from different scanners. And it's all hypothetical risk, because vulnerability tools don't account for the actual state of your environment.

Tuskira sits further down. Lattice deduplicates across overlapping tools and reclassifies risk against environmental context, so what surfaces is what's genuinely vulnerable and exploitable, with both a mitigation path and a remediation path.

The reclassification runs both directions, which is the part that matters.

A scanner reports a high-severity CVE with a high CVSS score. Public exploit code exists, it's a non-cloud asset, the attack vector is network. In isolation, that's an emergency. But the asset is running endpoint protection with suspicious-process blocking and anti-malware sensors enabled, and those controls break the exploit path. The risk drops to low. Still worth patching, during a normal cycle, not before lunch.

The next one keeps its high rating. Same profile, actively exploited in the wild, but the relevant detection-and-response policies aren't enabled. That one's real.

Four questions, four dispositions

The Patch Gap research formalizes this as a runtime decision loop built on four pillars.

• Reachability. Is the vulnerable code path exercised?
• Exposure. Who can reach the instance, and what's the blast radius?
• Active exploitation. Is exploitation occurring or observable?
• Defense coverage. Do controls block the exploit path?

Those four answers produce four dispositions: emergency patch, accelerated validated patch, standard patch window, or defer with evidence.

The report's worked example uses a critical nginx vulnerability across an illustrative 1,200-instance fleet. A severity-only model implies 1,200 emergency patches. A runtime model finds 720 instances with the relevant module compiled, 96 with the relevant methods enabled, 22 with the vulnerable configuration path, and 3 that are public, reachable and lack a web application firewall.

The answer isn't "don't patch." It's emergency action for 3, accelerated or standard lanes for the rest, and documented deferral where the vulnerable path isn't exercised. That's the difference between panic and prioritization, and it's the difference between a queue and a decision.

In a global financial services deployment, only 0.46% of 12.3 million findings required action, and exposure triage fell from three weeks to 30 minutes.

The response can't always wait for a patch

Patching is a change process. Approvals, regression testing, maintenance windows, the risk of breaking something else. Enabling a policy on a control you already own is a much shorter process.

So when a finding is real and the patch is weeks out, Tuskira shows you which controls in your existing stack could break the path now: a configuration change, a web application firewall rule, a network policy, an endpoint policy, tighter identity access. Framed honestly, that's getting better return from tools you've already bought.

That's the mitigation path running alongside the remediation path, not instead of it.

What your vulnerability scanner won't show you

Tuskira builds a digital twin of the environment and red-teams it, looking at your estate the way an attacker would rather than the way an asset inventory does.

That surfaces attack paths: chains where multiple vulnerabilities combine to move laterally from one compromised machine to another. It explicitly includes east-west traffic, not just internet-facing exposure.

It answers a specific objection. You've patched all your highs and criticals. Fine. What about a medium on a gateway system that reaches a critical on a backend host you believed was unreachable from the internet?

Kairo takes that further. It uses the business context already in the platform, systems carrying PII or financial data, to identify crown-jewel assets, then attacks those aggressively inside the digital twin. It validates findings against the real environment, carefully and with permission, to confirm that a breach path is real rather than theoretical. Then it replays the attack to show exactly how it would unfold, and shows the remediations.

The output is a breach graph: which assets lead to breach, and which crown jewels they expose. In one environment it surfaced a single EC2 instance role with access to both the secrets vault and the customer data lake. One node, two crown jewels, and it was vulnerable.

Not a black box

Every verdict is auditable. Execution logs show each step the agents took, every tool called and every source queried. The raw asset data and the raw scanner data are both there. Hypotheses are shown alongside the hypotheses the agent investigated and ruled out.

That matters more as AI does more of the work. When an agent tells you a critical finding isn't urgent, you need to be able to check its reasoning rather than trust it. Nothing's hidden.

Where your data goes

Since the subject is what enterprises send to AI systems, our own answer should be on the record.

Tuskira queries your tools through MCP for the information relevant to a specific investigation. We don't take wholesale copies of your logs, and you don't mirror your SIEM to us. Analysis runs at the edge where it can, and only targeted data comes back when it has to. Never application data or user data.

Everything's isolated to your tenant, including what the agents learn. Work done in one customer environment doesn't carry to another. That has a real cost: a novel technique worked out in one tenant has to be worked out again in the next. From a security perspective, that's the right trade.

The model should be interchangeable

Models will change. Providers will change. Pricing, access policies and capabilities will change.

Tuskira competes on a different axis. Reachability, defense coverage and breach paths are properties of your environment, not of the scanner or model that raised the finding, so the work holds its value as the discovery layer keeps turning over. Adopt the best tool available for finding things. The environment, the evidence and the response mechanisms stay where they are.

"AI has industrialized vulnerability discovery. The new bottleneck is determining which findings create real production risk and closing them before a patch ships. Finding vulnerabilities is becoming commoditized. Closing the right exposure with proof is the product."
Piyush Sharma, CEO and co-founder, Tuskira

The next bottleneck

Mythos 5 in Claude Security means more findings, faster, and the $35 million fund means more still. Good for defenders, and hard on the queue.

What enterprises need next isn't more findings. It's the ability to tell which of them map to a deployed, reachable and undefended path to something that matters, and to close those paths with the controls they already own while the durable fix works its way through change management.

The future of vulnerability management won't be decided by who produces the longest list. It'll be decided by who can turn discovery into the fewest necessary actions.

See it in your environment. Request a Breach Resilience Assessment to see which exposures map to reachable, undefended paths in your environment, and read The Emerging Patch Gap for the research behind these numbers.