I have another pet peeve.
This year the phrase “Are you Mythos-ready?” has started showing up everywhere in security conversations. Sometimes it means, “Are you prepared for attackers to find vulnerabilities faster?” Sometimes it means, “Can your vulnerability management program survive the flood of findings that is coming?” Sometimes it means, “Do your defenders have access to AI capabilities comparable to attackers?”
Those are all reasonable questions. They are also different questions, and I think we've allowed the phrase “Mythos-ready” to do a little too much work without always being clear about the problem we're trying to solve.
To its credit, the Cloud Security Alliance, working with SANS, [un]prompted, the OWASP GenAI Security Project, and an impressive list of security practitioners, actually tried to define what Mythos-ready means. Their AI Vulnerability Storm briefing describes a world where vulnerability discovery and exploitation happen faster, defenders need to automate, patching and incident response need to accelerate, security teams need AI capabilities of their own, and organizations need to become more resilient.
I agree with a lot of it. I think Mythos represents a real change in what AI can accomplish in offensive security, and I think security organizations that respond to that change by carrying on exactly as they have for the last decade are going to have a bad time.
My concern is that we're setting the bar too low. If your definition of being Mythos-ready is being able to do what an attacker with Mythos-class capabilities can do, you're aspiring to parity with the attacker.
Parity is the floor. Not the strategy.
Mythos Is a Warning, Not a Security Architecture
Let's get something out of the way first: Mythos is impressive. I don't think dismissing it as hype is particularly useful. Anthropic demonstrated a meaningful improvement in autonomous vulnerability research and exploitation, including the ability to find and exploit vulnerabilities that previous models struggled with. Project Glasswing was created specifically because Anthropic believes those capabilities will proliferate beyond the organizations currently trusted with access.
But there is an enormous leap between acknowledging that capability and deciding that the appropriate defensive response is to build the defensive equivalent of Mythos.
Mythos is still a model. An extremely capable model, apparently, but a model nonetheless. That distinction matters because I just spent an entire article arguing that if the capability of your system depends primarily on the capability of your model, you've made a bad architectural bet.
Models change. Providers have outages. Pricing changes. Token budgets become real. Latency matters. Model behavior changes between releases. The model that wins your benchmark today might lose it six months from now. Sometimes an inexpensive open-weight model turns out to be surprisingly good at the exact task you care about. Building a security architecture whose performance is overwhelmingly determined by whichever frontier model currently sits at the top of the leaderboard inherits all of those dependencies. More importantly, the model is only one computational component available to you.
Semgrep recently published an interesting example of this. In its IDOR benchmark, the open-weight GLM 5.2 reached 39% F1 and beat several frontier configurations when models were essentially given a prompt and asked to perform the task. Semgrep's purpose-built multimodal system, however, reached 53–61% F1. Their surrounding pipeline performed endpoint enumeration, context selection, and other work that made the overall system considerably more capable than the standalone models.
That shouldn't be surprising, and it leads to what I think is one of the most important ideas in this entire discussion:
You don't need a model more capable than Mythos to build a security system more capable than Mythos.
If the security industry's response to Mythos is to wait for equivalent frontier models and wrap increasingly thin harnesses around them, we're going to make exactly the architectural mistake I warned about before. Except this time we're also deliberately setting our capability ceiling at whatever the attackers happen to have. We can do better than that.
The Defender Has Something the Attacker Doesn't
Attackers have some enormous advantages. They get to choose their targets and their timing, they can concentrate effort on a narrow objective, and they only need one viable path to succeed. If AI allows them to throw enormous amounts of compute at finding that path, that's legitimately concerning.
Defenders have a much larger surface to protect, but they possess advantages too. Unfortunately, security organizations have a long history of squandering them by spending enormous amounts of effort on the wrong things, using old techniques against new problems, or simply remaining too buried in reactive work to capitalize on the information available to them.
The most obvious advantage is information. Your security organization can know your architecture, your business, which services are important and which ones aren't, your historical security decisions, compensating controls, accepted risks, recurring problem areas, deployment architecture, asset criticality, organizational risk tolerance, and all of the weird institutional scar tissue that accumulates after years of operating software.
An attacker may eventually infer quite a bit of that. The important distinction is that you don't have to. The bigger advantage, though, may be time. An attacker generally has to attack the software that exists. The defender can secure the software while it is becoming.
That distinction is becoming more important as AI accelerates software development. Coding agents are dramatically reducing the amount of time between an idea, an implementation, and something running in production. The defender's traditional head start may be shrinking, but that seems like a compelling reason to exploit the head start more aggressively rather than voluntarily surrender it.
The defender shouldn't aspire merely to become as capable as the attacker. The defender should exploit advantages the attacker can never have.
Stop Starting the Clock at Vulnerability Discovery
One of the things we've learned building AI systems for application security is that some of the most valuable security information isn't a vulnerability at all.
Years ago, one of the first capabilities we built at DryRun was a daily digest of what we called “security-interesting” changes. The idea was simple: security teams, especially small teams supporting globally distributed engineering organizations, often don't even know when something significant changes.
One of our first successes was notifying a customer's security team that engineers were substantially overhauling service-to-service authorization and introducing OIDC. Around the same time, another engineering team was changing the payment processor used by their payment gateway. Neither event required us to announce that we'd found a vulnerability. They were important because security needed to know they were happening.
If I substantially change how authorization works across services, that is security-relevant before anybody proves I introduced an exploitable vulnerability. If I replace a payment provider, create new public endpoints, change tenant isolation, introduce a new service, or redesign MFA, security may want to understand that change while it is happening.
A Mythos-class attacker can be extraordinarily capable at analyzing the resulting system. The defender gets to watch it being built. Starting the defensive clock only after a vulnerability exists throws away part of the advantage we already have.
Institutional Knowledge Should Be Executable
The same thing applies to what organizations have already learned.
Every mature engineering organization has architectural knowledge that exists somewhere between documentation and folklore. There are services that always have to go through a particular authorization path, boundaries everyone knows are dangerous to touch, configurations that caused an incident three years ago, and architectural decisions whose rationale may be understood by only a handful of people.
Historically, much of that knowledge has lived in people's heads, architecture documents, Slack messages, code review habits, and occasionally some poor security engineer who remembers the incident that caused the rule to exist in the first place.
AI gives us the opportunity to turn that knowledge into machinery.
We dogfood our own product extensively, and one of the things we've done internally is take institutional security knowledge and turn it into natural-language code policies. Humans establish the security expectation. AI helps express and investigate it. The system understands the relevant code context and evaluates changes against that expectation. When a policy is violated, we can enforce it.
That is a fundamentally different defensive capability from simply asking a model to find vulnerabilities. You're preserving what the organization already knows about how its software should work and applying that knowledge continuously as the software changes.
That has produced some of the most interesting findings we've seen internally. We've caught a change that deviated from our established multi-tenant architecture in a way that could have crossed tenant boundaries. We've found administrative controls capable of spanning organization memberships under particular conditions. We've found UI authorization behavior that exposed information before the appropriate authorization check occurred.
One of my favorites involved a twelve-hour cache. The interesting part wasn't that an AI saw the number twelve and decided twelve hours sounded scary. The system as a whole, utilizing all the weapons provided to it, understood that permissions could be revoked elsewhere in the application, understood what was being cached, recognized that there wasn't an adequate invalidation path, and reasoned that a revoked user's access could therefore remain effective for hours.
That conclusion emerged from relationships across the application, institutional knowledge, repository context construction, and everything else defenders have that attackers won’t. An attacker might eventually reconstruct some of those relationships, but the defender already owns the context that explains them. This is the opportunity I think gets lost when we reduce the conversation to whether defenders have access to an equally capable vulnerability-research model.
The Scarce Resource Is Becoming Discernment
There is another reason I'm skeptical of framing everything around an incoming “vulnerability storm.” We may absolutely be headed toward one, but I suspect we're also headed toward an enormous finding storm, and those aren't necessarily the same thing.
Anyone who has operated a bug bounty program knows exactly what I'm talking about. For every legitimately interesting report, there can be an enormous amount of stuff that gets filtered almost immediately: duplicates, misunderstandings, scanner output, technically correct but insignificant issues, reports that don't understand how the application works, and security toil that technically makes one layer of the onion thicker without meaningfully changing the risk of the system.
AI removes one of the historical constraints on producing that stuff. A machine doesn't get tired. It can continue searching, reasoning, generating candidates, and spending tokens across an extraordinary amount of software. That dramatically increases discovery capacity, but it does not follow that meaningful exploitable risk increases at the same rate.
This is why I think we need to be careful with some of the enormous numbers being discussed around Mythos and Project Glasswing. There has already been plenty of public debate about the usefulness, economics, and validation burden behind the headline numbers, and I don't intend to relitigate all of it here.
Tenable's recent write-up is instructive. Its team spent more than 500 hours, involved 11 security experts, and consumed more than 40 billion tokens while evaluating Mythos. Their conclusion wasn't that the model was useless and in fact, quite the opposite. But they explicitly noted that only a fraction of surfaced findings became true exposures after experts evaluated reachability, exploitability, and existing mitigating controls.
Semgrep has similarly pushed back on some of the lazy dismissals of Mythos while pointing out that inference economics and exploitability matter. Those debates are worth following, but they aren't really the point of this article. Even if we grant the most optimistic interpretation of Mythos's capability, the defensive engineering question remains the same.
If discovery becomes cheap enough, producing another finding becomes progressively less valuable.
The scarce resource becomes discernment.
Attackers and Defenders Have Different Jobs
A vulnerability represents risk. An exploit is the means by which that vulnerability can be exercised. For the defender, what ultimately matters is whether a vulnerability can actually be exploited in the environment, whether exploitation can lead to meaningful harm, and therefore what should be done about it.
This is why security has spent decades inventing severity and criticality systems. However imperfectly, we're trying to combine things like exploitability, likelihood, impact, category, environmental context, organizational risk tolerance, and business importance into a decision about what deserves attention.
AI doesn't eliminate that problem. If anything, an abundance of discovery makes it considerably more important. An attacker can generate 100,000 candidate vulnerabilities and tolerate an enormous failure rate. If only a tiny percentage ultimately produces something useful, the exercise may still have been worthwhile because the attacker only needs a successful path.
The defender has a very different optimization problem. If a defensive system generates 100,000 candidate vulnerabilities and dumps them onto engineering, it has created an enormous amount of security toil regardless of how technically impressive the underlying discovery system might be.
Matching the attacker's ability to generate vulnerabilities may therefore be insufficient or actively harmful unless the defensive system is better at deciding what matters. This is where the defender's information advantage becomes particularly valuable. The defender can potentially be better at discernment than the attacker because the defender possesses context the attacker has to infer: architecture, deployment, controls, asset value, business purpose, organizational policy, historical decisions, and what is changing right now.
The objective isn't to find more things than the attacker. It's to make better security decisions.
When discovery becomes cheap, judgment becomes valuable.
Don't Put a Faster Inspector at the End of the Assembly Line
I've written before about what I think is happening to software development. We're building an increasingly autonomous software factory.
Coding agents are becoming workers. Eventually we'll have increasingly specialized autonomous systems for engineering, testing, operations, security, QA, and other parts of software production. Humans won't disappear, but our relationship with the production process changes.
I think security needs to understand what that means for its role. The wrong response is to build an autonomous software factory and then put an increasingly powerful AI vulnerability scanner at the end of the conveyor belt. That's just automating the old paradigm.
Security should become part of the control system governing the factory itself.
That means observing security-significant changes while they happen, turning institutional knowledge into enforceable controls, and continuously understanding how the system is evolving. It also means allowing machines to perform investigation, correlation, validation, enforcement, remediation, and response where we can establish sufficient confidence and appropriate boundaries. Humans then move up the abstraction stack.
I think about this similarly to the people overseeing highly automated manufacturing floors. Their value isn't that they're personally tightening every bolt faster than the robot. They're responsible for governance, safety, quality, acceptable operating parameters, exceptions, improvement, understanding why the machinery behaved unexpectedly, and deciding when intervention is necessary.
That's a more useful model for the future security engineer than the generic phrase “human in the loop.” If every autonomous security operation requires a human to manually approve it, we've really only moved the bottleneck from the machine to the person. Human oversight remains critical, but increasingly that oversight should govern the system rather than manually perform all of its work.
Otherwise, AppSec Is Going to Drown
This is the part I think our industry should be more uncomfortable discussing.
Imagine that software production continues accelerating. Engineering agents generate and ship more code. Development cycles compress. New services appear faster. Dependencies proliferate. Software supply chains become more complicated.
At the same time, Mythos-class offensive capability becomes cheaper and more broadly available. Attackers find vulnerabilities faster. Exploit development accelerates. The gap between a flaw existing and somebody being capable of exploiting it continues shrinking.
If AppSec's primary response is to find vulnerabilities faster, the math doesn't work particularly well. More scanners and more agents create more findings, which create more triage, more remediation work, and more demands on engineering. Automation can absorb some of that load, but an organization whose fundamental operating model remains reactive will eventually spend most of its capacity plugging holes.
There will always be another finding, another patch, another dependency advisory, and another thing somebody wants security to review immediately. Eventually the team spends all of its time reacting and none of its time defending.
That's where I worry about the future of AppSec itself. A team with no capacity for architectural improvement, proactive risk reduction, institutional learning, or strengthening the development process eventually becomes an increasingly efficient producer and processor of security toil.
At some point the business is entitled to ask an uncomfortable question: why do we have an AppSec team at all?
If AppSec's role collapses into reacting to vulnerabilities that machines can increasingly discover and remediate themselves, concentrating human security expertise around detection, incident response, resilience, and recovery starts to look like a reasonable alternative. I don't think that's where we should end up, but AppSec has to earn the alternative by exploiting the place where it has an extraordinary advantage over an external attacker: before the incident exists.
Respond Immediately. Don't Confuse Response With Purchase.
So what should a CISO do when somebody walks into the room and asks, “Are we Mythos-ready?”
First, don't panic. That doesn't mean do nothing.
CSA's briefing is correct that assumptions underlying security programs are changing. Exploitation timelines are compressing, AI-assisted vulnerability research is becoming more capable, defenders need greater automation, resilience matters more, and security teams cannot expect to manually outwork machines. Those are legitimate strategic issues that deserve attention now.
But urgency should accelerate understanding, not procurement.
Before buying anything, develop a thesis about what Mythos-class capability actually changes for your organization. Determine which assumptions in your AppSec program no longer hold and where you're still operating at human speed. Understand how quickly you can identify and respond to a meaningful flaw, what happens when several serious vulnerabilities appear simultaneously, and which parts of your software-development process are accelerating because of AI.
Then look inward. Where does institutional security knowledge live today? Which security decisions could become automated? Where are humans performing toil that machines should perform? Which advantages do you possess over an attacker that you're currently squandering? And yes, can you perform vulnerability discovery at a level that prevents an attacker from consistently knowing more about your software than you do?
You should absolutely be researching this now. You should be able to explain to your board what Mythos changes, what it doesn't, where your actual exposure lies, and how you intend to adapt.
It is a great time to research. It is a terrible time to make a knee-jerk decision because somebody attached the word “Mythos” to the problem they're selling.
Build Something Better Than Mythos-Ready
Mythos matters. The capability shift it demonstrates matters. The shrinking exploitation window matters. The possibility of dramatically cheaper vulnerability research matters. The implications for incident response, vulnerability management, software supply chains, and security staffing matter. But Mythos isn't the specification for the defensive system we should build. It's evidence that the environment changed.
The defender's objective should be to meaningfully reduce exploitable risk, prevent as much of it as possible from reaching production, minimize the window in which remaining flaws can be exploited, and respond and recover extremely quickly when prevention fails. Sometimes accomplishing that requires the same capabilities attackers possess, and we should absolutely build or acquire them. That's parity, and parity is necessary but it isn’t where we should stop. Again, it is the floor.
We have advantages attackers don't. We have the source before release. We have architectural intent, business context, institutional memory, deployment context, security policy, previous decisions, and knowledge of our own hot spots. Most importantly, we participate in the process of creating the thing the attacker eventually wants to break.
We should use those advantages instead of voluntarily constraining ourselves to the attacker's view of the world. LLMs are extraordinary engines, and they're getting better at a frankly absurd pace (well, in some ways… I’ll save that for another article). But we get to decide what systems we build around them, what information those systems possess, how they reason, what deterministic capabilities complement them, what they remember, what they enforce, and where humans govern them.
That's why I don't think the important question is whether your security organization has access to a model as capable as Mythos. The more interesting question is what kind of security system you can build now that models like Mythos exist. Because you don't need a model more capable than Mythos to build a security system more capable than Mythos. The attacker may eventually get the same model.
You get the entire factory.
