I recently hosted a webinar for EngineeringX on a topic that's been weighing on me for quite a while now: what happens when AI can find vulnerabilities faster than we can patch them?

This isn't hypothetical. Anthropic recently disclosed Mythos, an AI model that can outperform any individual or group of hackers at discovering vulnerabilities. Their response, Project Glasswing, involved privately notifying major internet infrastructure companies about what Mythos had found and giving them time to patch. The point wasn't that Mythos itself would be weaponized, it was that other entities will soon have models just as capable. The threat isn't here in full force today, but we've already seen attacks that look AI-driven. Tomorrow is a different story.

So what do we actually do about it?

Stop Pointing at the Security Team

Most of the recommendations out there focus on security teams. I think that's wrong.

I've been a CISO. I've run security operations. And I'm telling you: security can't solve this alone. Engineers and developers are better positioned to fix these problems systematically. The habit of dumping vulnerability tickets onto engineering as extra work on top of an existing sprint doesn't scale, and it's not going to hold up against AI-accelerated attacks.

I break my recommendations into three tiers: what the company needs to do, what engineering needs to do, and what security should actually focus on.

What the Company Needs to Do

Pre-position your incident respons. Communications, escalation paths, and messaging should be pre-approved and ready to fire the moment a problem hits. No waiting for legal or the CEO to sign off in the middle of a crisis.

I learned this one the hard way. At a previous company, a legal team blocked me from notifying the government about a major incident for nearly ten hours. They argued I wasn't authorised. Had we run a tabletop exercise together beforehand, they would have known that notification was a requirement and could have helped shape the message instead of stonewalling it. Ten hours. During an active incident.

Know your dependencies and your dependents. Every vendor, open-source library, and downstream consumer of your services should have a contact path established before something goes wrong. Who do you call? Who calls you? Figure that out now.

reat preparation like a product feature. Security work shouldn't be bolted onto sprints as an afterthought. Plan it alongside features. Your savvy customers, the ones who actually care about reliability and safety, will see that investment as a positive signal, not a delay.

What Engineering Needs to Do

Shorten your patch and change cycles. If you take one thing from this entire piece, take this. How quickly can you make changes safely and securely? That's the single most important metric. You can't predict exactly how you'll be attacked, but if you can respond fast, you're fundamentally more resilient. And that same capability accelerates feature delivery, experimentation, and everything else you care about.

Find bugs before you ship. SAST, SCA, automated pen testing, memory-safe languages, secure pipelines. These should be engineering-owned, not handed off from security as someone else's problem.

Build with breach assumed. Go beyond zero trust. Assume malicious actors are already inside your perimeter today. Isolate services by identity. Make tokens short-lived, single-purpose, and tied to one identity. I get asked "which tokens?" The answer is basically all of them, but start with the risky ones. The same token should never be able to create an account, elevate privileges, and modify the codebase.

Establish a surge capability. Have a pre-identified team with pre-approved authority, budget, and SOPs ready to take command during severe incidents. When something truly dangerous happens, normal leadership chains hand over to them. You'll want training and post-action reviews, obviously. But having this established upfront means you're not figuring out who's in charge while everything is on fire.

Reduce what you expose. Audit your codebase, cut unnecessary dependencies, and shrink your attack surface. I asked the webinar audience: how many of your dependencies could you name right now? How many do you actually need? If a Log4j-scale event hits, knowing what's exposed versus what's internal lets you prioritise, or skip patching entirely where it's safe to.

What Security Should Actually Focus On

Rather than piling on more responsibilities, security teams should be ruthlessly automating the manual work that slows them down.

Put AI in front of your alert queue, and test it. I know people are nervous about this. It reminds me of self-driving cars. We overestimate human analysts and underestimate AI because when AI gets it wrong, it makes headlines. The actual numbers tell a different story. The key is understanding how and when the model gets it wrong so you can account for it, rather than worrying about hypothetical edge cases you'd also miss with a human.

Automate incident bookkeeping. Status updates, ticket management, stakeholder comms. Let AI handle the stuff that eats analyst time but doesn't require judgment. And if you've ever worked in an SRE or security operations centre, you know the most damaging thing that can happen during an incident is a senior leader walking into the room and asking for updates every five minutes. Automate those updates. Keep them informed. Keep them out of the room.

Close the loop on false positives. Don't just mute noisy alerts. Investigate why they're false, and fix the root cause. Sometimes it's a misconfigured tool. Sometimes it's a design flaw disguised as intended behavior. I've seen authentication systems that would happily confirm whether a username existed without rate limiting, because someone wanted a friendly user experience. That's not a false positive. That's a design problem.

The Honest Bit

Someone in the webinar asked whether AI will ever tip the advantage toward defenders. I didn't sugarcoat it: probably not. Attackers will always have the edge because it's easier to break than to build. Ask any two-year-old. Defenders play by rules. Attackers don't.

But that's not a reason to do nothing. It's a reason to stop treating security as someone else's problem and start building systems that are resilient by design: simpler, faster to change, and harder to exploit.

The fire drill is coming. The question is whether you've already practiced for it.

Full webinar: here