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.

This is a real gain for defenders, and it makes an existing problem larger.

Yesterday: Find vulnerabilities faster.

Today: AI finds vulnerabilities faster than humans can remediate them.

Tomorrow: Determine which findings map to real breach paths and orchestrate the right response.

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 does not claim. It does not 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 cannot resolve on their own.

Tuskira starts where the finding lands

Our work starts when a finding lands in the platform. A Mythos 5 result, a Qualys scan, a Wiz finding, a CNAPP alert, an EDR detection: each one arrives at the same two questions.

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

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

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 is guaranteed overlap between sources, so the same issue arrives more than once from different scanners. And all of it is hypothetical risk, because vulnerability tools do not 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 is 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 is a non-cloud asset, the attack vector is network. In isolation, that is 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 are not enabled. That one is 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 is 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 is not "do not patch." It is emergency action for 3, accelerated or standard lanes for the rest, and documented deferral where the vulnerable path is not exercised. That is the difference between panic and prioritization, and it is 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 cannot 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, this is getting better return from tools you have already bought.

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

What your vulnerability scanner will not 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 have 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.

This matters more as AI does more of the work. When an agent tells you a critical finding is not urgent, you need to be able to check its reasoning rather than trust it. Nothing is 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 do not take wholesale copies of your logs, and you do not 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 is isolated to your tenant, including what the agents learn. Work done in one customer environment does not 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 is 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 is not more findings. It is 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 will not be decided by who produces the longest list. It will 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.