Writing a working exploit used to be the slow, skilled part of an attack. Today, it’s an entirely different landscape. Anthropic reports that the Claude Mythos Preview found vulnerabilities and developed working exploits for them autonomously, without human direction. That undercuts an assumption most security programs are built on: that defenders have time to investigate, prioritize, and act before an attacker can exploit a weakness.
Today, security teams are feeling pressure coming from four directions at once:
1. Findings keep growing: 35,853 CVEs were published in the first half of 2026, or roughly 49% more than in the same period a year earlier. Yet only 495 of them were catalogued as exploited in the wild in that window, and 116 were under attack on the day they were published.
2. Working exploits are appearing faster, so there’s less and less time available for teams to respond.
3. Severity scores can’t show what else an attacker could exploit in a given environment.
4. Patching still depends on fixes, testing, and deployment capacity that doesn’t just scale overnight.
Anthropic's August 26 update illustrates the last point. Of 2,300 vulnerabilities disclosed to maintainers, 421 were known to have patches, and the company identified human triage and review as the bottleneck. Which gets us to the uncomfortable truth: while AI accelerates discovery; assessing findings and shipping fixes still moves at a much slower human pace.
Before a fix is available, or waiting on deployment, teams still need to establish three crucial points.
Three questions that define Mythos-readiness
Forward-thinking defenses need accurate, up-to-date answers to three fundamental questions.
- Are we exploitable? Which assets could an attacker actually compromise, given your configuration, reachability, and access conditions?
- Are our controls working? Would the defenses you’ve put in place actually block the attack or detect the behavior?
- How quickly can we respond? How soon can the team establish the exposure, choose an action, and verify that their response worked?
To keep things interesting, these answers expire. A new vulnerability can affect an asset that passed its last assessment. A policy update can weaken a control that previously blocked an attack. An infrastructure change can open a new path to a critical system.
Today, your validation program has to notice when an answer may have changed, and test again.
Why scheduled testing is giving way to change-triggered validation
A manual pentest is a point-in-time exercise. Skilled testers go deep into an agreed scope over a set period, and that depth is still hard to match any other way. But the findings hold only for that scope, and only for that moment in time.
Autonomous pentesting and breach and attack simulation made testing repeatable and frequent, so teams could validate defenses between engagements and track whether fixes improved results. But a test on a fixed schedule still leaves changes untested until the next cycle. A weekly cadence leaves up to a week between a change and the next assessment.
The next step is validation that follows change.
An emerging vulnerability, a relevant attack campaign, or a configuration update should prompt the appropriate test, shortening the period in which the team has no evidence about its current exposure. Gartner's Continuous Offensive Security Testing (COST) research describes this shift toward validation triggered by events and connected to operational workflows.
What matters now is how fast a change becomes a tested answer. Define which changes trigger validation, the time each one gets, and who acts on the result.
How Adaptive Validation matches each change to a test
At Picus, we call this approach Adaptive Validation. It’s testing that triggers automatically as threats and environments change. Each meaningful change raises a specific question, and that question selects the method.
- An emerging vulnerability asks which affected assets are actually exploitable.
- A new campaign asks whether existing controls stop its techniques.
- A policy update asks whether the controls it touches still hold.
- An infrastructure change asks whether a new attack path has opened.
The methods feed one another. An exploitable asset may require assessment of the paths it opens. A control gap needs mitigation, then a retest to prove it’s been closed.
And every finding needs an owner, so validation informs daily decisions and gives leaders verified risk reduction instead of a list of findings.
See it in practice
At The Validation Summit '26, Picus co-founder and CTO Volkan Erturk will present Proof at Machine Speed, a session on how exploitability validation, security control validation, and autonomous pentesting work together against AI-powered attackers. The summit also includes a live demonstration that takes a new vulnerability through validation, remediation and retest.
Choose October 14 at 1 PM ET or October 15 at 11 AM BST. Register here to secure your seat.
