Claude Mythos and AI exploit development: Should defenders worry? | Nerdy 30, Episode 7

Introduction: Three perspectives on one model

Ben Baker: We’re talking all about Claude Mythos. I’ve got three guests with me today who hold somewhat different views on the topic.

One guest thinks the security use case for Mythos is just scratching the surface, and if it can do this complex work within security, we should honestly be wary of the disruption it can cause outside of security.

Another guest feels like the AI threat is pretty overblown across the board, and many times we can blame our fear on marketing. As a marketer, I’ll try not to be too offended by that.

And the third guest falls somewhere in the middle.

Today we’re guaranteed to have a conversation, but I’m honestly hoping for a little bit of a cage fight. We’ll see where we go here.

What makes Mythos different?

Ben Baker: Greg, you wrote that cybersecurity is the least of the problems Mythos signals. Before we go anywhere else, I want to set the stage. What is Mythos actually doing that registers as different, and why does it matter beyond the vulnerability research use case that’s gotten all the headlines?

Greg Notch: First and foremost, it wasn’t designed for cybersecurity specifically. It was just a new model, and it certainly had a step forward in its capabilities. One of the first things they looked at was its ability to string together complex reverse engineering tasks, produce and string together vulnerabilities, and produce outcomes. That was one of the first things they saw as problematic, which is why they didn’t release it to the public.

I think alongside that, there’s certainly a bit of marketing involved, because there was nothing about it that you couldn’t do with Opus—except it was better at it. Most of those capabilities vulnerability researchers have been doing for some time now with LLMs. So there was a little bit of both sides.

But the real takeaway I had was: Well, if it’s able to do this type of reasoning on esoteric vulnerability finding, what would it do with biological information or other types of information that it could string together? Let’s keep it positive and find new drugs, as opposed to the risk side.

James Shank: For me, Mythos confirms the direction and the velocity of innovation with the models. It’s the next step and the next model to be released. It’s not the last, and it’s not the apex either. It’s showing the directionality of the pursuit.

But to Greg’s point—and I think it’s an incredibly important point—the model wasn’t specific to cybersecurity outcomes or purpose-built for cybersecurity. In terms of its disruptive capabilities, as we start looking to the future for what these LLMs will do in the end, it’s a whole new day. There’s going to be a lot of widespread impacts to not only business operations but just human life, and it’s going to be interesting how we respond to that from a cybersecurity perspective.

Marcus Hutchins: My perspective is I don’t really know what we’re looking at, because I personally have not gotten a chance to try Mythos. I have experience with Opus. I’ve spent some time researching ChatGPT, some open-weight models. But I prefer to talk about what I actually have in front of me—what I can see and what I can touch.

At the end of the day, it’s very easy to say “my new product is the best product that’s ever been made, it’s super intelligent, it can do everything, but you can’t see it because it’s just too good.”

I’m of the opinion: Is there an advancement there? Probably. But how much of an advancement? We don’t really have the data to tell that. A lot of what they published gave us some small slivers of insights, information about how much it cost to find these vulnerabilities, what kind of vulnerabilities they found. But in terms of how this compares to Opus? Not a whole lot of information in the white paper.

The great debate: Does skill still matter?

Ben Baker: Marcus, based on our previous conversation about AI malware, you mentioned that doing real damage still requires quite a bit of expertise, and Mythos may not hand a script kiddie a skeleton key to an environment.

Greg, you’ve mentioned that the bar for patch exploitation is now low enough that we could probably figure it out in an afternoon—though I know I couldn’t do that, you probably could.

James, I think you’re somewhere in the middle there. So who’s right? James, you tell us—is it your friend or is it your boss?

James Shank: Of course, Ben, I’m always right.

My perspective is that the two fundamental things that have changed are velocity and cost. If you look at traditional project management, there’s a triad of scope, time, and money. When you change one of those, you have to change the other two to make up for it, or change one to compensate.

But what’s changed in essence is two of those legs. The scope of what can happen has changed in terms of what people can drive to. But what hasn’t changed is motivations and the way attacks generally play out.

If you look at the MITRE ATT&CK framework, AI is not magic. We’re not jumping through and doing things fundamentally different. It’s not going to enable attacks to do things that are completely different than what humans have already been able to do. It changes the velocity that some of that can happen at, maybe. And it changes the scope of what attack techniques get exposed or the vulnerabilities that get exposed might be.

But we’re still—at the end of the day, defense is still solid. What we’re doing from a defense industry perspective is still valid. We just need to make sure we’re enabling our defense teams to integrate AI and these solutions fast enough so we can stay ahead of attackers.

Greg Notch: I think it’s more than just velocity. I tend to think about this stuff in terms of capabilities and scale. If I start with a premise that you still need a very sophisticated attacker to wield high-end exploitation—which is true—but you gave that person 100 times as many exploits, and you gave them an automation framework that allowed them to prosecute attacks at scale…

I’m thinking nation-states, the sharp tip of the spear folks already. You’re now scaling your top talent. The downstream consequences of that are significant.

The second part: if you take it down from the top 1% of the 1%—the lower level of capabilities have been democratized to an extent where your smash-and-grab folks are empowered to do things they weren’t before. It will also drive the marginal cost of an exploit down.

The million-dollar iOS exploits? Maybe I don’t know—I’m going to pick a number—but it’s not a million dollars anymore. Changes to vulnerability economics—I don’t think I fully understand what that would do, but it definitely is going to favor the attacker.

Greg Notch: The third thing: from a MITRE framework perspective, if you think about what novel exploitation does and where the average security program’s ability to detect and prevent is, it’s in the middle—at exploitation time. You’re hoping to catch it at exploitation time.

Things that happen to the left of it are noisy because you’re looking for recon and other things. The progression from exploitation to the attacker’s goals—I agree with James completely—their goals aren’t going to change, and how they get there post-exploitation probably isn’t going to change. But the speed at which they can get from A to B is much faster.

Your opportunity to detect an attacker and thwart their activity just got a lot harder. You’re going to have to either look earlier in the signal—which is noisier—or you’re going to have to hope your ability to keep up with novel exploitation is good, or you’re going to have to be way faster in the post-exploitation phases to catch it.

Zero-day detection: Why behavioral approaches still work

Marcus Hutchins: We have to get to the argument that speed is increasing, because I have not seen evidence to suggest that. But assuming the speed is increasing—not a lot of the actual fundamental underlying techniques have changed.

A zero-day exploit is a new vulnerability in a specific area of a specific product, but the exploit itself is not new. The techniques being used are not new. A lot of people focus on the idea of zero-days as if it’s this brand-new attack.

They’re still messing with memory, they’re malforming packets, they’re hitting file paths that no user should be hitting. They’re doing something that is unusual. As detection engineers or security companies, our goal is to look at what is the normal for this client or this network, and what is outside the norm.

A lot of the things you have to do when exploiting a zero-day is very, very out of the norm. It’s very noisy, it’s very unusual. And I don’t think we necessarily need any crazy new system. I think we just need to be detecting the actual exploit—what is the exploit doing?

Is there heap spraying going on? We can write detections for that. Is it using malformed file formats? We can write detections for that. Then, as James said, the attackers still have to get to their goal, and we know their goals because they’re the same goals they’ve always had.

We can lay detections the whole way from initial entry to the attackers’ goals. I don’t know if we all do, but we should have automated systems in place to detect and shut down attacks. It shouldn’t be a human sitting there manually reviewing logs or manually checking through the process list. There should be automation.

I don’t think the speed actually matters as much as people think. A lot of our detections that already exist can deal with this hypothetical greater speed, this hypothetical faster time to exploitation. I don’t really think there’s this massive need to change the fundamentals around security.

Marcus Hutchins: I think the big problem is a lot of us aren’t doing it right. A lot of companies—their EDR has too many false-positive detections. So rather than reconfigure their EDR to have better detections and a better signal-to-noise ratio, they just farm it out to someone: “Hey, go sift through these detections, tell us which ones are the good ones.”

If you do have an AI operating faster, that becomes a problem. But that is not a problem of the AI going too fast for our detections—it’s that we weren’t refining the detections well enough, so there was such a high signal-to-noise that some human was having to sift through that.

The patching window problem

Greg Notch: I did want to point out one thing about the fundamentals. One of the fundamentals is patching, but now patching is a risk because the second Microsoft ships Patch Tuesday, even I can figure out how to build a zero-day—or one-day—from Patch Tuesday. Diffing DLLs with an LLM is not really all that challenging.

That worries me a little bit because if you talk to any big enterprise: How fast can you patch all your Windows servers? That time is not measured in hours or days. Sometimes it’s weeks or months, or years. Or they can’t, because some video driver needs to stay in place.

You are now existing inside the patching loop of these enterprises. I’ve got a theory of constraints here that maybe aren’t as low to the ground as the exploitation itself.

Marcus Hutchins: Prior to AI, the average time for a lot of the actually useful exploits was a day. Exploit developers were able to turn that stuff around on a dime. Obviously, we didn’t see that because most of that stuff was being sold to nation-states.

Criminals have no desire for exploits because, as Greg has pointed out multiple times and is 100% correct, criminals don’t need it. They can get you to give them your password. So they don’t have the resources to spend time doing patch diffing or finding zero-days.

We’re still in that mechanic where the patch-diffing time was not that slow pre-AI, and we never really saw much materialize out of that because they never needed the exploits.

We’re sort of stuck in this phase where we won’t really see any change from it until criminals decide there is some economic incentive to either use zero-days or n-days. But I don’t think that’s coming anytime soon. I don’t think we’re fixing identity anytime soon. I don’t think we’re fixing malware anytime soon.

We might see some changes in sort of lower-end nation-states who maybe didn’t have the money to purchase high-end zero-days. But I don’t really foresee a massive change in the criminal landscape.

Initial access: Where defenders actually catch attacks

James Shank: I don’t think there’s anything inherent about zero-days that guarantees signal gets generated. I understand the perspective that they’re noisy, they’re doing something different, but that doesn’t always lead to signal being generated.

One concern if a future outcome is more zero-days are generated: whether that creates a more detectable or less detectable initial entry vector. But as you mentioned, any broad detection strategy should cover several elements of the MITRE ATT&CK framework and different stages of attack, so there would still be signal elsewhere.

Going back to our Annual Threat Report from last year, one of the things we noticed is we tend to catch a lot of attacks in initial access. That is where a lot of attention has been shifted in the past maybe five to seven years, as attackers and defenders have shifted to look at identity-based attacks. There’s a lot of layering of focus on initial access.

This does—if there is an increase in the number of zero-day exploits available to attackers—that could introduce a change in the relative mismatch of the strategy for defenders over the most recent years and where attacks might be moving in the future.

Greg Notch: We still haven’t seen people shift off of identity because, frankly, it’s still easier. Why pull out something that’s more advanced and frankly more likely to fail than something that is the tried-and-true: I got you to tell me your password and click okay to the MFA push, and away we go in our Batmobile.

I want to respond to one thing Marcus said because it was interesting. I agree that you could probably on two hands list the classes of things that an exploit does—a variety of memory corruption, a variety of call flow graph manipulations, all of the things that happen with manipulative processes into doing things.

I have not yet seen consistent behavior-of-attack-class monitoring. A lot of the EDR and a lot that I have seen and am aware of—please correct me if I’m wrong—we’ve kind of failed as an industry at behavioral stuff because it’s always hard and it always ends up noisy.

Maybe this will be the moment we actually get that right, but we’re still on—I think a lot of the detections, at least at the EDR and sometimes at the MDR level, are still very narrow to a very specific exploit rather than: “Hey, I saw heap corruption, it’s go time.”

Marcus Hutchins: You’re absolutely correct that the detections are not there, but there is a reason for that. We haven’t seen widespread zero-day use up until very recently. It started getting a little bit more common with specifically China-backed nation-state actors aggressively using zero-days. But before that it was mostly: Install the patch. This is an n-day, there is a patch—install the patch.

There wasn’t a whole lot of work done in exploit mitigation. There are some tools that have great exploit mitigation that I’m aware of, but a lot of the middle-of-the-road, run-of-the-mill EDR products—you are right, they don’t have good exploit mitigation tools.

But that isn’t because we can’t make them. It’s that there hasn’t really been much of a reason. If you’re getting hit by zero-days, something’s wrong—the chances are you’re being hit by a very targeted attack, and they’re going to get in regardless.

That’s a lot different from: Okay, people are just spraying zero-days everywhere. Then we do need to start worrying about widespread zero-day detection.

But the actual mechanics of the zero-day aren’t really that novel. Your standard memory corruption on any modern system—you’ve got to get past things like heap fragmentation, heap bucketing, control flow guard. A lot of the ways you get past those mitigations are very, very noisy.

If you’ve ever seen the backside of a heap spray, it’s basically just spamming kernel allocations, filling up the entire system’s memory in the hope of allocating a very specific address. That is something that is very, very detectable.

Have we made good detections for it yet? I don’t think we have. But we can write tools to be like, “Oh look, someone is spamming allocations on the system, I wonder what that’s for.” Or “Oh look, someone has sent the same weird request that doesn’t match any of the normal requests 100 times.”

The gap is where we could be versus where we are. My argument is it doesn’t take a whole lot to get to where we need to be—it just needs the motivation, which we didn’t have until now.

Motivation and economics: The cascading effect

James Shank: That’s a prudent point. But bringing it all together, that motivation element is on both sides—the defenders and the attackers.

As Greg mentioned, attackers haven’t had to innovate because they’ve had quite a lot of success. One of the things Ben knows about me is I’m constantly advocating for focus on the fundamentals because those are the things that are going to impact your security outcomes more than anything else. That’s because attackers are having plenty of success without innovation.

To Marcus’s point, the defendability or the detectability or the ability to stop certain types of attacks might not be technically hard. But also, the security fundamentals in general are not generally technically hard. They might be expensive, they might take some time to roll out, but the solutions are there.

Where things lag behind is implementation. But implementation oftentimes lags behind because the justification isn’t there, because the attacks are not there, because the attacks don’t need to be there. So there’s this cascading set of reasons why, as you go down this trail.

But what is changing now is the effort, the time, and the cost of putting together different types of attack techniques and possibly chaining attacks together. That might change how that cascading set of justifications balances out on both the attacker side as well as the defender side.

I would argue that it will change because it’s not using the same premises. Generally speaking, human time is a very large operational expense, so committing to long-standing research to accomplish something requires high justification. If you reduce that now to “it doesn’t matter anymore because you’re just having computers churn through a problem”—that changes enough of the entire balance of the equation that that’s upsetting the apple cart a little bit.

Greg Notch: I completely agree with James. I tend to try to put on an economic lens sometimes when I think about these problems, especially when I put my CISO hat on. I’m like, “Yeah, I could solve all these problems, but I only have so many things I can do with the team I have. Or I’ve got to make asks of the rest of the org—whether that’s directly from their time, or I’m going to inconvenience them in some way to put these controls in place.”

CISOs are constantly having to trade that off: Is this the hill I want to die on? Do I want to put another endpoint agent on, or am I going to restrict behavior in some way that makes it difficult?

When I think about the economics of both sides—how a defender applies its resources versus how an attacker applies theirs—fundamental shifts on either side cause a reaction on the other side.

If we somehow waved a wand and fixed all of the crazy identity problems we have—we got everyone to implement OAuth 2.0, everybody had a YubiKey, there was no way to log into anything except with a hardened cert based on your retina—you remove all the attack classes of identity, and attacker behavior would move on its own just because you made it harder.

We saw this when exploitation basically took a backseat to identity when SaaS and the cloud happened. Before that, people would pop zero-days. Now you don’t care because you can just get someone to let you in.

I think those ships will come again, mainly because if something starts to cost a lot or something else becomes very cheap, then both sides have to adapt to the new landscape.

What defenders should focus on right now

Ben Baker: What should security teams be thinking about right now? Marcus, is it the basics?

Marcus Hutchins: It’s the basics. From looking through our internal logs, the amount of attacks that are either identity-based or someone has clicked on a phishing link or some similar attack—it’s got to be like 99%.

Greg Notch: I agree, it’s basics, but faster. It’s going to come faster and harder. The main distance between what Marcus thinks and what I think is: I think the democratization is the problem.

If you’re thinking about the same attackers, you’re right. But if you’re thinking about how there were all of the people a tier below the attackers you’re already seeing who didn’t have these capabilities—now new players are going to enter the game. Players that weren’t as sophisticated are going to now have different capabilities.

But the answer remains the same: Make sure you have good coverage, you have good detection engineering. Just realize the tempo is going to increase.

James Shank: I agree fully with both what Greg and Marcus said, but I wanted to offer a different perspective. I think the way to think through this is to think about the business dynamics, not the security dynamics.

Defense and offense, defenders and attackers—they’re both running businesses. They’re both motivated by some purpose, and that’s going to inevitably drive the changes in the attacker-defender dynamics.

To Greg’s point, in his role as CISO, he’s always triaging priorities and figuring out where to apply focus. Adoption and implementation is always a costly thing.

Just to highlight really quick: IPv6 was specified in December 1995. Just a few days ago, Google announced it finally crossed the 50% threshold for traffic to Google services. That’s 30.5 years.

The truth is that’s the speed of these things. Necessity is the mother of invention. There has to be a driver that causes some business outcome that either advantages or drives the attackers to change or drives the defenders to change. And that doesn’t change—LLMs are not changing that.

Defenders have the advantage (if they use it)

James Shank: A lot of the conversation has overly focused on how these LLMs and models advantage attackers. That’s fundamentally wrong. They advantage defenders more than attackers.

The difference is attackers don’t necessarily have to be concerned about liability. They don’t have to be concerned about GRC and compliance and laws and contracts. Those are all business functions that are absolutely necessary.

The success for defenders is going to be working together with those teams to get LLMs enabled in the places they need them and these models enabled in the places they need them to help the defenders defend. That’s where success comes.

But if you think about it from basic attack dynamics: Defenders start with knowledge of their environment. They start with access to everything they need. They start with all the context they need, except for potentially the motivations of the attackers and possibly some zero-day exploits or capabilities that the attackers might have. That’s the only thing they’re missing.

The rest of it is things that attackers need to discover as they’re carrying out their attack or doing reconnaissance. Those things are where the benefit lies for defenders.

Leveraging those, combining the same techniques, and playing through playbooks of understanding how attacks can be carried out against your environment, as well as how to align your defenses to shore up the places where you’re weak—we can do this. We have the advantage. We have the information at our fingertips.

I would challenge us all to understand: The only way these advantage attackers over defenders is by defender inaction.

Mythos for defenders: What early users are seeing

Ben Baker: Have we heard anything from companies around the success of deploying Mythos for defense purposes—not necessarily pointing out vulnerabilities, but actually creating patches?

James Shank: I’ve heard from friends at various companies involved in those projects that they’ve been doing this for a long time now. Mythos was just another model introduced into their arsenal of models that they’re running against their code bases.

But that’s relative—all of the 40 companies that were chosen are relatively mature companies. I know that’s happening at that layer. I don’t know that it’s happening at some of the smaller companies, the drivers writing drivers for small appliances or small hardware vendors. That’s where I think there’s going to be some interesting things that might come out.

What they’re finding—and what I’ve heard—is that there’s a lot of marketing involved in the whole way Mythos has been released. That’s legitimate, it’s useful. But the undercurrent is that it hasn’t generated, to my knowledge, an onslaught of new vulnerabilities and new discoveries when they’re running it against their code bases for those that already have CI/CD pipelines constantly battered by multiple different existing models.

So it’s an iterative change. It is the next step. It’s not the apex, and it is confirmation of trajectory, but it’s not like, “Oh crap, now we’ve got this huge problem.”

Greg Notch: That matches what I’ve heard from various folks. People running it are like, “Yep, it’s finding more stuff, but we already had the scaffolding to work with these tools.”

There’s a fun view that a lot of my friends and I share: This is as crappy as this is ever going to be. Right now we have the worst models we’re ever going to have. No one can predict the slope of the curve or when it levels off, but right now we’re in that moment.

We will see—AppSec is going to be a very interesting space for the next little while. We are going to see these tools get democratized down outside of the top 40 companies in the world that already had world-class AppSec programs. That’ll be interesting.

But yes, people are using them on the defensive side. They are using them to audit their own code, they are using them to produce patches. It’s just early days.

What network engineers should be thinking about

Question from the audience: While security teams deal with preparing for this new category of threat, is there anything network engineering teams should be doing?

James Shank: One of the things I would say is network engineering and network security teams should be looking at observability. To what degree are they enabled to see things going on in their network? How are they looking at what’s going on in terms of anomalous traffic flows, DNS queries, certificates, URLs accessed, application firewalls, or WAFs?

The question to look at is: How can you use LLMs to bolster up your detections and your ability to analyze what is normal in your network versus what is abnormal, and spot those anomalies?

Now, that might not always be an LLM doing that, but we need to start doing that with machine models, period. That’s the most important thing—it has to be machines making decisions because the velocity is changing.

Greg Notch: The normal is going to change a bit when you baseline your network. If you think about legitimate user behavior with agent teams and what an average user is going to do inside your network—that’s going to change.

If there’s one thing a network engineer can be doing, make sure you’re gaining a new and evolving understanding of what the traffic on your network looks like, both normal and abnormal. You’re looking for a much more of a needle in a haystack when you have people running legitimate agent teams connecting to LLM services, as well as looking for attacker behavior inside your network that may or may not also be leveraging these services.

Frequently asked questions about Claude Mythos and AI exploit development

What is Claude Mythos and how does it differ from other AI models?

Mythos is an AI model developed by Anthropic that demonstrates advanced capabilities in stringing together complex reverse engineering tasks and automating exploit development pipelines. Unlike general-purpose models, Mythos showed particular strength in vulnerability research. However, it wasn’t released publicly due to safety concerns. The key difference from other models is the sophistication of reasoning it can apply to technical security tasks, though it still requires expert operators to be effective.

Will Mythos-like models make zero-day exploits cheaper and more accessible?

Possibly for lower-tier nation-states who previously couldn’t afford high-end zero-day exploits. However, cybercriminals are unlikely to gain access because they lack the funding, compute power, and expertise to build or operate these systems effectively. The bigger concern is the marginal cost of exploits decreasing for sophisticated actors who already had capabilities, potentially shifting exploit economics and making previously expensive techniques more accessible.

Does Mythos change the patching window problem?

It potentially exacerbates it. Historically, skilled exploit developers could create n-day exploits (exploiting patched vulnerabilities) within about a day of Patch Tuesday by diffing DLLs. If AI makes this process faster or more accessible, the window between patch release and active exploitation narrows. Since many enterprises take weeks, months, or even years to patch systems, they’re increasingly vulnerable during this expanded risk window.

Can defenders detect zero-day exploits even if they don’t know the specific vulnerability?

Yes, through behavioral detection. Zero-day exploits still exhibit unusual, noisy behaviors: heap spraying, malformed packets, accessing unexpected file paths, abnormal memory allocation patterns, and control flow manipulation. While defenders may not have signatures for the specific vulnerability, they can detect the exploit techniques being used. The challenge is that many organizations haven’t implemented robust behavioral detection because zero-days were historically rare enough not to justify the investment.

How does Mythos advantage defenders versus attackers?

Defenders have inherent advantages: complete knowledge of their environment, access to all systems and logs, full context about normal operations, and legitimate access to test security controls. Attackers must discover all of this through reconnaissance. Mythos-like tools help defenders audit code, find vulnerabilities before attackers, produce patches faster, and test defenses comprehensively. The limitation is business constraints—GRC, compliance, contracts, liability—that don’t constrain attackers.

What should organizations prioritize given AI’s impact on exploit development?

Focus on fundamentals: comprehensive logging and monitoring for behavioral anomaly detection, rapid patching processes (aim for days not weeks), defense in depth so exploitation alone doesn’t lead to compromise, network segmentation and least privilege to limit blast radius, and threat hunting to find exploitation attempts that don’t trigger alerts. The answer hasn’t changed—it’s still the basics, but potentially needing to be implemented faster and more thoroughly.

Is the security community overreacting to Mythos?

Opinions differ among practitioners. Marcus Hutchins notes we haven’t seen evidence of actual impact yet and prefers to evaluate based on observable reality rather than marketing materials. Greg Notch sees broader implications beyond cybersecurity and is concerned about democratization of capabilities. James Shank views it as confirmation of trajectory and changing economics. The consensus: It’s a meaningful advancement but not the apocalyptic threat some headlines suggest.

Key takeaways

The debate about Claude Mythos reveals important nuances about AI in cybersecurity:

Context matters more than capabilities: Mythos wasn’t designed specifically for cybersecurity, which suggests its real significance may lie in broader applications. The security implications might be just scratching the surface of its disruptive potential.

Economics drive behavior on both sides: Attackers and defenders are both running businesses with budgets, priorities, and justifications. Changes in exploit economics (cost, time, skill required) will drive behavioral changes on both sides—not because the technology changed, but because the business case changed.

Velocity and cost changed, not fundamentals: What’s shifting is how quickly and cheaply certain tasks can be accomplished, not what those tasks fundamentally are or how to defend against them. MITRE ATT&CK still applies. Attack goals haven’t changed. Defense strategies remain valid.

Democratization is the wildcard: The question isn’t whether top-tier nation-state actors get slightly better tools—it’s whether capabilities previously limited to the top 1% become accessible to the next tier down. That shift in who can do what creates the most uncertainty.

Zero-days are noisy when you look for them: Exploitation techniques—heap spraying, malformed packets, abnormal memory operations—are inherently unusual and detectable through behavioral monitoring. The gap isn’t capability, it’s motivation and implementation. Defenders haven’t invested heavily in exploit detection because zero-days were rare enough not to justify it.

Patching windows are now a bigger vulnerability: If n-day exploitation becomes faster or more accessible, the time between patch release and widespread patching becomes a more significant risk period. Enterprises that measure patching in weeks or months rather than days face increased exposure.

Defenders have structural advantages: Complete environment knowledge, legitimate access, full context, and the ability to implement controls before attacks occur all favor defenders. The challenge is business constraints (GRC, compliance, budgets) that limit how quickly defenders can act. Attackers don’t face these constraints.

Implementation lags behind capability on both sides: Attackers haven’t needed to innovate because identity attacks work fine. Defenders haven’t implemented robust exploit detection because it wasn’t necessary. If economics shift enough to make exploitation more attractive to attackers, defenders will need to accelerate implementation of behavioral detection and faster patching processes.

Machine-based decisions become necessary: As velocity increases—whether from AI-assisted attacks or just legitimate business operations involving AI agents—human-in-the-loop decision-making at every step becomes impractical. Network engineering and security teams need to leverage machine learning and automation for anomaly detection and baseline understanding.

Stay vigilant but don’t panic: The sky isn’t falling. Focus on fundamentals, monitor developments, implement defenses faster where justified, but don’t abandon proven security strategies chasing hypothetical AI threats. The basics executed well still provide strong protection.

Ben Baker’s final note: Don’t fall for the headlines. The sky isn’t falling. Follow the fundamentals and stay vigilant. We can do this—we have the advantage, we have the information at our fingertips. The only way these advantage attackers over defenders is by defender inaction.

This transcript has been edited and condensed for clarity and readability.

For more insights on AI in cybersecurity and practical security guidance, subscribe to Expel’s blog and watch the Nerdy 30 series on YouTube. To learn how Expel’s AI & automation engine and MDR services help organizations defend against evolving threats, schedule a demo today.