Developed together with Usman Chaudhary @ Google for Public Sector (his post)

Let’s call it what some in the industry are calling it: the vulnerability apocalypse. For years, finding vulnerabilities was slow, expensive, specialized work. LLMs made it cheap — in its first weeks, one frontier model surfaced more than 23,000 issues across a thousand open-source projects, including a 27-year-old flaw in OpenBSD found for under $20,000 in compute. And when finding bugs gets cheap, attackers find more of them — and likely exploit more of them, faster than defenders can patch. This isn’t hypothetical: Google’s threat intelligence team has already reported the first zero-day exploit built with AI, caught being used in the wild. The deluge is real, and it’s here.

Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit…

Since Mythos, AI-powered defenses have emerged just as fast: autonomous agents that find and fix vulnerabilities in source code, tools that rewrite code to eliminate whole classes of bugs, frontier models utilized by defenders.

But here’s what gets lost in the arms race: the fundamentals are more important now than they have ever been. When you can’t out-find or out-patch the machines, what saves you is the boring, durable work done well — knowing your environment, limiting how far a break-in can spread, fixing root causes. AI raises the ceiling on both attack and defense; it doesn’t change what good defense is made of. And defending against AI-speed attacks doesn’t always require AI — sometimes it just requires the fundamentals, done well at scale.

One new note to add. Recent incidents like this made some people state that “basics don’t matter, machines will find a way.” To me it means that basics do matter, but consistency and scale are MUCH more critical. After all, and this is a silly example, no machine can find a buffer overflow if you code in Rust. And, yes, sadly, this means you need to be “near perfect”, but hey good news — with the same machines you can. So this is not a boring “do the basics please” post, this is a reminder that you need to scale them with AI.

Why the urgency is real (and different this time)

Why act now, if you’ve heard “do the fundamentals” for twenty years? Because the gap between discovery and exploitation is effectively gone — according to some sources, high-severity flaws are now exploited within hours, sometimes before a public proof-of-concept exists, and the damage is material, widespread, and accelerating.

A program that assumes days or weeks to respond was built for a world that no longer exists. The fundamentals — visibility, segmentation, process — are what absorb the shock when patching inevitably falls behind. And this holds whether AI capabilities jump or improve gradually: the actions needed today are largely the same.

AI made finding vulnerabilities cheap. The attackers noticed. The answer isn’t panic — it’s the fundamentals done well at scale.

Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It?

Start by reverse-engineering the impossible

Before any playbook, one exercise — because it does more to find your real gaps than any framework will.

Imagine you could patch any vulnerability within 15 minutes of its release, as if by magic. Now work backwards: what would have had to be true? You’d need to know instantly what you run and where it’s exposed. You’d need testing so automated that a fix ships safely in minutes. You’d need no legacy that resists change, and an architecture built to absorb it. You’d need to have already eliminated whole classes of bugs, so there were fewer to patch at all.

You will never hit 15 minutes across the environment — legacy systems guarantee it. But the gap between that fantasy and your reality is the most honest map you will ever get of where your program breaks. Every item in the playbook below is something that this exercise surfaces.

The Playbook: Fundamentals at AI Scale and Speed

Each of these is written as what to do and how to actually get it done — because the advice-to-adoption gap is where most programs die.

The four moves: SEE → DECIDE → CONTAIN → RUN

1. SEE — know your environment, and keep watching

• The play: Map your environment (configuration graph) — what you run, what’s exposed to the internet, and how far one compromise can spread. Then keep watching: observability across your own environment, and threat intelligence for the outside view, so you know the moment a bug in vendor software starts being exploited in the wild.
• The advantage: The graph pays for itself immediately — dead code, unused open-source packages, and forgotten internet-facing servers you can simply remove — and it’s the asset list every other move depends on. Threat intel buys you early warning: you hear a vendor bug is being exploited when it’s announced, not when it hits you, so a compensating control can be in place before an attacker arrives.
• If you skip it: You defend blind — the breach starts at the asset you didn’t know you owned, and you learn about it from someone else.

2. DECIDE — spend your limited capacity where it matters

• The play: Prioritize by real exploitability, not raw severity — a “medium” on an internet-facing service one hop from customer data beats a “critical” on an isolated internal box (recently chains of Lows and Mediums were used in real compromises as well). Run two lanes: your own code you can fix, refactor, or rewrite; vendor code you can’t touch, so that lane is compensating controls and faster detection.
• The advantage: Your finite capacity goes to the few findings that could actually hurt you — and every flaw gets a response you can execute: a fix where you can, a shield where you can’t.
• If you skip it: Busy but not safer — capacity burned on findings no attacker could reach while the one exploitable path stays open, and months of exposure waiting on a vendor patch you could have mitigated in days.

3. CONTAIN — make sure one bug can’t become a breach

• The play: Segmentation splits the environment so a foothold in one place can’t reach the rest. Zero trust and least privilege make every person, service, and AI agent prove each request — and grant only the access it needs. When you can’t patch fast, mitigate: block the exploit path or take the exposed component offline. And when the same bug class keeps returning from the same code, fix the root cause — rewrite memory-unsafe components in a memory-safe language instead of patching the same flaw forever.
• The advantage: One exploited bug stays a contained incident instead of a company-wide breach — and containment keeps working even when patching can’t keep up.
• If you skip it: One bug becomes the whole environment — the first agentic ransomware ran its entire chain through doors these basics would have closed — and unfixed root causes bring the same bug class back every quarter.

4. RUN — make it continuous, and govern what runs it

• The play: Make scanning and fixing continuous and automatic, not quarterly — with the process defined before you accelerate: human-in-the-loop approval before fixes ship, a tested rollback path for when one goes wrong, and every AI agent wrapped in identity, least privilege, and human review from day one.
• The advantage: Machine-speed remediation that’s safe to run — and the whole playbook becomes a daily operating discipline instead of a one-time project.
• If you skip it: Quarterly scans mean months of exposure between runs; automation without approvals and rollback breaks production at machine speed; and an ungoverned agent becomes your newest insider threat.

None of these are new controls. What’s new is the bar. AI changed the speed and scale of the attacks, so the fundamentals have to run faster than they used to and cover everything with no exceptions.

The hard part isn’t technical

Every move above lands on someone else’s roadmap. Many are already on them, some for years. Segmentation changes how infrastructure operates; a continuous fix pipeline changes how developers ship; rewriting memory-unsafe components costs engineering quarters. Expect pushback — not because those teams don’t care about security, but because you’re asking to spend their time against their goals.

Three things buy the political capital: bring evidence, not mandates — the configuration graph and real exploitability data argue better than any policy memo; co-own the fix — show the risk and the trade-off, then let engineering own the how, because a rewrite they choose ships and a rewrite they’re ordered into stalls; and give leadership one number tying the work to risk reduced, so the effort defends itself at budget time.

Mandates breed quiet workarounds. Shared evidence and shared credit create movement.

The frontier agrees:

Anthropic, having surfaced the scale of the problem with Mythos, has focused on the fix: an automated pipeline that investigates, validates, and patches code vulnerabilities — delivered through Claude Code — with human review before anything ships.

Google frames it as AI threat defense: using AI across the whole vulnerability management lifecycle — finding, fixing, detecting, responding — wrapped in a framework and human review. The emphasis is on managing the end-to-end process, not any single tool.

OpenAI focuses on cyber-focused models — such as the GPT-5.6 series (including the Sol model) — which are designed to assist defenders with vulnerability identification, red teaming, and security validation, shifting the approach toward high-reasoning, specialized models capable of handling complex security tasks.

Different bets, same conclusion: none of them claims AI fixes vulnerability management for you — every one wraps the capability in process and human review.

The real reckoning

The vulnerability deluge is real, whatever you call it: AI made finding bugs cheap, and cheap discovery means more exploitation and more damage. But the reckoning isn’t that AI broke defense — it’s that the fundamentals matter more than they ever have. Use AI to find, to fix, and to move faster than you thought possible. But map your environment, limit how far a break-in can spread, fix the root causes, and keep a human on the decisions that matter.

Get the fundamentals right — that was always the strategy; now it’s the only one. Which of these is your program most under-invested in? That’s the conversation worth having…

P.S. This came out a bit too high-level, but this is admittedly for the high level audience…

Further reading and sources:

• “Breaking the Patch Sound Barrier” series
• Security incident disclosure — July 2026 (boring title award winner!)
• Google Secure AI Framework (SAIF)
• Google Threat Intelligence Group on the first AI-developed zero-day observed in the wild (2026).
• CoSAI Shared Responsibility for AI Security
• Anthropic — the post-Mythos code-patching pipeline via Claude Code
• Zero risk isn’t the job: a CISO’s guide to agentic AI
• First Take: OpenAI’s Hugging Face Hack — CISOs Must Focus on Fundamentals and Ignore the Hype (Gartner access required)

Beyond the Vulnerability Apocalypse: Scaling Your Basics and Vulnerability Management was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

For 15 years (!), many of us who have touched cloud security have struggled with the shared responsibility model for cloud security. As with many “cyber things,” the theory is simple. Multiple vendors, consulting firms, and industry bodies have published deceptively clear matrices that depict exactly who is doing what for cloud security.

Everyone likes to present trivial cases: for example, the cloud provider is entirely responsible for the physical security of the data center, while the client is responsible for the application they just built and deployed within that cloud provider’s IaaS. In reality, many of the edge cases continue to cause pain to a lot of organizations.

Ok, so none of this is fundamentally new. However, in recent years, similar and more complex - dare I say sinister?- questions have emerged: What does shared responsibility look like for AI security?

Those who haven’t studied this topic in depth might assume there is no difference. Yet, there are fascinating, critical differences between shared responsibility for AI security and traditional cloud security, along with older related challenges like the shared security of outsourcing (that predate cloud).

Add AI with its probabilistic behaviors, untrusted user inputs, and nested vendor dependencies -and that finger-pointing cycle doesn’t just continue, it scales exponentially. When a customer-facing chatbot goes off the rails, the model provider blames your prompt engineering, the platform provider claims infrastructure isolation worked perfectly, and your internal application team swears it’s an upstream model limitation…

Put simply, what are the top 3 differences between shared responsibility for AI vs cloud? In my opinion:

1. A Broader Spectrum of Risk: The range of harms and risks we must consider is much wider. Shared responsibility for AI security frequently touches upon safety, privacy, ethical use, and the unique risk surfaces that emerge specifically in conversations about AI.
2. The Multi-Party Supply Chain: AI security is typically far more multi-party than traditional cloud security. For instance, one company builds the foundational model, another company fine-tunes it, a third party builds a Retrieval-Augmented Generation (RAG) architecture for you, and yet another party builds the consumer-facing application.
3. Non-deterministic Behavior: Unlike traditional cloud infrastructure where secure configurations yield predictable, deterministic outcomes, AI systems are non-deterministic. Because outputs can vary significantly based on user inputs, customers bear increased responsibility for implementing robust guardrails, continuous monitoring, and input/output filtering.

Early attempts to create a logical foundation for AI shared security responsibility produced some answers — and more questions.

In light of this being a tricky problem, here I really want to focus on one thing — a post-incident scenario. While shared responsibility covers numerous use cases (and numerous sources of confusion…), let’s examine a fairly straightforward situation: I am an enterprise end-user company that uses (maybe builds, maybe tunes, etc) AI in some form, then something blows up (digitally, as this is not IoT/ICS security blog). So:

• Who takes a loss vs who is to blame?
• Do I blame the model creator? The application developer? The model hosting platform? Or do I ultimately blame myself?

If you recall, many early challenges with the cloud shared responsibility model began with customers trying to blame the provider, only to discover they were actually at fault in the end. We tried to change this dynamic by introducing a “shared fate” model. While that specific terminology has seemingly fallen out of favor lately, the underlying philosophy remains: providers can probably do more to make AI usage inherently secure.

I was recently involved with a CoSAI (Coalition for Secure AI) working group to develop a paper covering the shared responsibility framework for AI security. As others on the team humorously pointed out, my voice was one of the loudest calling for the paper to be kept simple, crisp, and highly usable. You can judge based on the final result whether we succeeded.

We recently wrapped up and approved Version 1.0 of the CoSAI AI Shared Responsibility Framework (AI SRF) through the Coalition for Secure AI and OASIS Open. The core mission here wasn’t to build more abstract compliance theater, but to solve a practical, glaring operational pain point: Who actually owns what when an AI system fails?

Under the CoSAI framework, accountability traces down the stack with absolute clarity:

• The AI Model Provider (L5) is accountable for the base model’s inherent susceptibility to prompt injection and must document those boundaries explicitly within the model card.
• The Cloud/Platform Provider (L4) is accountable for the blast-radius containment, ensuring infrastructure-level tenant process isolation held firm during the exploitation.
• The Application Developer (L3) is accountable for failing to enforce application-level guardrails, input filtering, and localized data access controls that allowed the chatbot to hit the PII repository in the first place.
• The Deploying Organization (L1/L2) is accountable for the ultimate governance failure: they did not properly classify the data or restrict the chatbot’s system-level access boundaries before pushing it live.

Also, the paper included a phased Implementation Playbook in the document to give security teams a somewhat specific path forward:

1. Phase 1 (Days 1–30): Map your entire AI system inventory and cross-reference vendor contracts against these five layers to highlight immediate responsibility gaps.
2. Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
3. Phase 3 (12 Months): Run layer-specific tabletop simulations to stress-test your incident response playbooks before an actual threat actor tests them for you.

Fun quotes:

• “Ambiguous ownership is a growing liability for Al system deployments.” [A.C. — filed under ‘no shit, Sherlock’]
• “Without explicitly assigned owners for detection, containment, and remediation, teams default to the finger-pointing cycle” [A.C. — this will get worse, then MUCH worse, then eventually better…]
• “The framework turns ‘whose fault is this?’ into ‘which layer’s controls failed, and who owns remediation for each?’” [A.C. — this is beautifully, I probably wrote this :-)]
• “There should be exactly one accountable party per component to prevent overlaps.” [A.C. — ideal world called, it wants its problem back! Real world picked up and said ‘get lost’]
• “Clear accountability eliminates finger-pointing during incidents” [A.C. — clear evidence that Captain Obvious is alive!]

More seriously, read the paper!

In the end, I hope this work enlightens people on just how complex this problem truly is. This paper is definitely not a silver bullet that solves everything overnight; we have years of discussions and evolving challenges ahead of us down this path. However, I think this paper serves as an excellent first step. Please make sure to check out the resources listed at the end of the paper as well (a lot of gems there!)

Related blogs:

• Who’s Responsible When AI Goes Wrong? A New Framework Aims to Answer That Question
• Where Does Shared Responsibility Model for Security Breaks in the Real World?
• No Snow, No Flakes: Pondering Cloud Security Shared Responsibility, Again!
• EP203 Cloud Shared Responsibility: Beyond the Blame Game with Rich Mogull
• EP145 Cloud Security: Shared Responsibility, Shared Fate, Shared Faith?
• Who Does What In Cloud Threat Detection?
• The Cloud Shared Irresponsibilities Model

From Cloud to Chaos: Defining Shared Responsibility for AI Security was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

This blog is perhaps a little bit more like an ad, so if you don’t want to check the ads, consider not reading it.

But this year at RSA 2026, I’m speaking on three topics: securing AI, using AI for SOC, and sharing lessons about how Google applies AI and other technologies to D&R.

Here are these 3 fun things!

First, I’m doing a presentation on governing shadow AI agents. Believe it or not, this presentation was created mostly before OpenClaw became a thing (but updated for it!). So you may be surprised how well the content aged (think wine!) Attend this if you are struggling with shadow AI, specifically shadow agents at work.

Shadow Agents: A Pragmatist’s Guide to Governing Unsanctioned AI — [STR-W08]

• Wednesday, Mar 25 1:15 PM — 2:05 PM PDT

It is not the APT! The new threat is the “shadow AI agents” employees already use for work, leaking data and making decisions. Banning them is a losing game. This session will offer a better way: turn this organic behavior into a catalyst for secure progress. Learn to discover, assess, and channel unsanctioned agents into a formal strategy that empowers a team rather than force it underground.

The second is probably the most detailed discussion about how we use AI for detection and response at Google. You probably read our blogs and listen to our talks (especially this), but this time we are revealing a lot more interesting details about the machinery and also how we arrived at the state we’re in. I promise you this will be fun! And detailed too.

This Is How We Do It: Building AI Agents for Cybersecurity and Defense — [PART3-M07]

• Monday, Mar 23 2:20 PM — 3:10 PM PDT

Presenters will share the playbook for building and scaling AI agents in cybersecurity. Attendees will learn four core lessons: Building trust with the team, prioritizing real problems, measuring value, and establishing solid governance foundations for the agentic SOC.

Finally, the third isn’t a presentation but a discussion that would help you understand the real state of AI in security operations / SOC. This would not be about the slides, but about sharing lessons on what works and what doesn’t.

AI in SecOps: Sharing Lessons Learned for Adoption Maturity — [CXN-R05]

• Thursday, Mar 26 12:20 PM — 1:10 PM PDT

Attendees in this peer-led discussion will share stories from the AI-powered SOC trenches. Explore real adoption journeys from manual processes to autonomous agents. Share practical use cases on analyst retraining, workflow auditing, malware analysis, remediation automation, RAG pipelines and more. Trade notes on what’s working, what’s breaking, trust gaps, AI hallucinations, and career redesign.

All in all, join me for securing AI and Shadow Agents, learning from Google about detection and response, and comparing the state of practice of AI in the SOC.

See you there!

P.S. Yes, we will also be podcasting from the show.

Related:

RSA 2025: AI’s Promise vs. Security’s Past — A Reality Check”

My Really Fun RSA 2026 Presentations! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.