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.

If you look at social media debates about AI, two extreme patterns emerge. Studying extreme patterns is very useful because understanding boundary conditions helps you understand the whole phenomenon — in this case of security in AI adoption (recent extreme example). You can also do all sorts of fun scenario planning with this.

Predictably, security leaders have caught the same fever, and even some technologists did. Let’s catalog them like this:

• Camp 1 (The Meh Camp): This camp spans a spectrum — from the hard cynics (“it’s autocomplete with a marketing budget,” LLMs are stochastic parrots, there is no ‘intelligence’ anywhere in the building) to the more measured “AI as normal technology” crowd, who concede the tech is real, but expect it to diffuse slowly and messily over decades. What unites them: no discontinuous jump, no paradigm rupture, no exponents, no robot overlords. And yes, “the parrot wing” of this camp is alive and well in some very senior security circles.
• Camp 2 (The Deep Believers): AGI is coming by “next Tuesday” — or 2027 at the absolute latest. This camp also spans a spectrum, from the “doomer” accelerationists who foresee inevitable, systemic collapse to the optimistic futurists anticipating a complete, rapid upheaval of the global security landscape. Some hold this timeline with religious fervor while being unable to define “intelligence” if their bonus depended on it. What unites them is the conviction that we are facing an immediate, discontinuous, exponential leap in capability that will render all traditional defensive strategies obsolete overnight. And yes, there are influential security leaders who lean heavily into this camp.

Here is the fun part and the point of this blog: you don’t need to know who’s right. In fact, betting your security program on either camp being right is the actual mistake I want to point out.

Maybe the Parrot camp is right. Maybe the AGI-doomers are spot on. Or maybe the truth is somewhere in the swampy middle. If you find yourself unable to justify a security investment without first winning a philosophy-of-mind debate, you are doing it wrong.

But let’s instead ponder what works in “either / neither / both” cases.

What security advice remains correct today and for the medium term without relying on either camp being right?

One structural note before we start: every section below runs the same play. What the “parrot future” does to you. What the “AGI Tuesday” future does to you. What you do about both — with one control. Watch how many times the answer converges.

That convergence is my argument (with help from Gemini and Claude Fable).

Universal Security Controls for Both Futures

If you’re Camp 1 — whether the parrot wing or the “normal technology” wing — you believe AI is an incremental extension of “classic” ML: it accelerates existing security processes without any dramatic paradigm shift. But even then, you concede it speeds things up — including for attackers, who now discover vulnerabilities and misconfigurations faster and phish with impeccable grammar (nobody, not even the “parrotiest” parrot will argue with this one!). If you’re Camp 2, you may be surprised to see that these same controls apply, just with the volume knob turned to 11 at times.

1. Configuration Hygiene

Boring? Yes. Optional? Definitely not. Cloud misconfigurations and weak baselines remain the #1 way attackers walk in through the front door — no AGI required, thank you very much.

• Parrot future: attackers use AI to find your misconfigurations faster. The parrot doesn’t need to be smart; your S3 bucket is public.
• AGI future: the “superintelligent” attacker also starts with your public S3 bucket, because why use an AI-crafted zero-day when the door is open?

The universal control: treat configuration hygiene as tier-1 defense, with continuous (not quarterly!) posture validation. Hygiene is the rare control that is equally valuable whether AI is a mildly better “grep” or an existential threat (Claude came up with this metaphor, thanks buddy, it almost rhymes). If your AI security roadmap has “agentic red teaming” on it but not “close the open buckets,” you are accessorizing a house with no doors. See good argument here.

2. Threat Detection & Security Monitoring

You do recall I had a title “Chief Logging Evangelist” a few years back (“A few, Anton”? Who are you kidding?” … Anyhow…) Your SOC or D&R team or whatever you call it still needs to log, sense, detect, investigate, etc.

• Parrot future: your normal systems face automated, AI-accelerated attacks — same TTPs, faster tempo, and phishing that finally spells “invoice” correctly. Your triage queue was built for human-speed adversaries; it is about to meet an assembly line.
• AGI future: the AI systems themselves become the thing to watch — inputs, outputs, tool calls, and internal telemetry — because prompt injection, abuse, and quiet exfiltration through an agent leave traces nowhere in your current detection content.

The universal control: log and detect. Your classic estate under machine-accelerated attack, and your AI stack as a first-class telemetry source with its own detections (devil here is in the details, as usual). I admit this smells like an “Easier Said Than Done” competition entry with some chance of getting a 3rd prize. But the fact remains: good logging helps you in either case.

3. Accelerated Vulnerability Management

Vulnerability management — dealing with security-relevant flaws in vendor software and your own code and open source code — must run on a faster clock in 2026. The clock disagreement between the camps is about how much faster, not whether. Think 30%+, 2x, 10x or “we are all gonna die”x :-)

• Parrot future: AI compresses the exploit timeline the boring way — faster recon, faster PoC-to-prod exploit code, “commodity” attackers punching above their weight class. Your 30-day patch SLA quietly became a 30-day “we have a front door open, locks what locks” period.
• AGI future: “Patching is dead! The machines will find zero-days continuously!” Fine. Even granting the premise, the conclusion isn’t “give up” — it’s that mitigation and rewriting becomes the whole game.

The universal control: vulnerability management inclusive of mitigation planning (segmentation, “virtual” patching, compensating controls, config weakness scanning, etc) becomes more critical under both futures, not less. Most companies cannot break their “patch sound barrier”, AI or no AI. When you can’t fix the flaw, you’d better be able to contain the blast radius. Note the irony: the AGI camp’s own argument makes the boring VM discipline more important. Funny how that works.

4. Data Security & Sensitive Data Discovery

Both camps should care deeply about knowing where their sensitive data lives, but they lose sleep over different nightmares:

• Parrot future: the risk is leakage and compliance. Employees will lovingly paste source code, PHI, and PII into consumer chatbots to “polish an email.” Regulators do not accept “the parrot ate my data” as a defense. Am I overdoing the “parrot thing” here?
• AGI future: the risk shifts to poisoning and exploitation. An agentic system with access to poorly governed data repositories plus one well-crafted prompt injection equals an AI that cheerfully exfiltrates things it should never have touched.

The universal control: build a real-time, accurate inventory of your sensitive data — and yes, AI-automated sensitive data discovery and mapping is finally real (while in 2016, it largely was not, for most organizations). The uncomfortable truth: most organizations spent two decades not doing data security because it was hard and nobody made them. AI just made “we don’t know where our data is” much more painful, whether you are “camp parrot” or “camp AGI.” Heard this advice before? Yes, you did. So? Did you actually try implementing it? Well, now you need to, parrots or not.

5. Shadow AI Governance & Sanctioned Alternatives

Banning public AI tools is the ultimate security theater — right up there with confiscating USB sticks in 2009 or banning Internet connectivity in 1998 (“but why would you need the internet for work?!”). It doesn’t stop usage; it just moves it to personal phones and personal accounts, where you can’t see it, log it, or ever get the data back.

• Parrot future: employees casually feed proprietary code and PII into consumer LLMs, generating incidents and triggering your lawyercats unnecessarily.
• AGI future: well-meaning developers hand API keys and internal data access to unmonitored shadow agents and creating a sprawling, autonomous attack surface that nobody owns. What fun!

The universal control: stop playing firewall whack-a-mole. Get visibility (CASB and DLP are still a thing, yes, really!), then remove the excuse: offer a sanctioned enterprise AI tool with real contractual data protections. People take shortcuts when the official path is a dirt road. Pave it. And if your ban is still in place in 2026, understand that you don’t have a policy — you have a shadow inventory problem you’ve chosen not to measure.

6. Identity & Access for Agents

Here’s the control nobody had on their 2016 bingo card: least privilege for machines that ask nicely. We barely handled NHI (no, we never did, IRL) and now we have “agent identity” with a pillow fight ongoing on “is agent more like an employee or more like a workload”…

• Parrot future: AI tools and integrations quietly accumulate OAuth grants, service accounts, and long-lived API keys — classic non-human identity sprawl, now with extra steps. Regular NHI problem left unsolved would kill you slowly, the agentic one will work faster.
• AGI future: autonomous agents holding broad credentials become the single most attractive target in your enterprise. Compromise the agent, inherit its permissions — and its work ethic. Tricking an agent to do “a rogue action” is becoming more popular every day…

The universal control: treat every agent, and integration as an identity with a lifecycle (!). Scope it, time-limit it, log it, and review it. Your agents currently have more access than your interns and sometimes less judgment. Fix at least one of those ;-)

7. Environmental Reality Testing vs. Marketing Benchmarks

Model capability benchmarks are largely a mirage if they do not match your realities. A high score on a vendor slide means precisely nothing about your production environment, if you are not them.

• Parrot future: blind trust in claimed accuracy yields silent failures, hallucinations in critical workflows, and surprise data leakage — the parrot passed the exam and still can’t do the job. I am not adding “it will peck you to death”, this is where I draw the line…
• AGI future: deploying an agentic system for consequential autonomous tasks without validation invites systemic, unpredictable behavior — an advanced agent breaking things faster than you can file the postmortem.

The universal control: ignore the brochure. Run internal, multi-run reliability testing and AI red-teaming in your environment with your data before any AI system earns operational duties. Trust is earned in your environment, not on the vendor’s leaderboard. Here’s the provocative version: if your AI procurement process accepts benchmark scores as evidence, your procurement process is part of your attack surface.

Moving Beyond the Debate

And, yes, we could keep adding entries (asset management, IR playbook updates for AI incidents; the list of unglamorous-but-necessary goes on). But you’ve seen the pattern ten times now, so let’s name it.

The two camps diverge violently on timelines and on whether a discontinuous “AGI jump” is coming at all — yet they converge on the near-term necessity of architectural control, every single time. Autonomous agents, supply-chain exposure, machine-speed offense: both worldviews agree these risks are real, present, and demand action today.

When two groups who agree on nothing agree on your homework, the homework is probably real. If I hear one more CISO tell me they are “waiting for the dust to settle on AI” before building a security strategy, I’m going to start charging for therapy. The dust isn’t settling. It’s just turning into more data you aren’t logging.

So the next time someone tells you they can’t build an AI security strategy until the AGI debate settles — smile, nod, and go patch something. The philosophers will still be arguing next Tuesday. Your attackers won’t wait that long.

Summary

• The dichotomy: security leaders split into the “normal technology” camp (from stochastic-parrot cynics to slow-diffusion “pragmatists”) and the “AGI by next Tuesday” believers (and of course less extreme middle too)
• The core thesis: we do not need to settle the philosophical debate. Many of the same fundamental, no-regret controls apply regardless of which future arrives, and the camps’ convergence on near-term controls is itself the strongest evidence those controls matter.
• The no-regret controls:
• Treat configuration hygiene as tier-1 defense — both futures start at your public S3 bucket.
• Monitor both your normal systems under AI attack and the telemetry of your AI systems themselves.
• Accelerate vulnerability management loops, with mitigation planning for the flaws you can’t patch
• Prioritize sensitive data discovery — against leakage (low end) and poisoning/exploitation (high end).
• Replace blanket bans with sanctioned enterprise AI plus visibility.
• Govern non-human identities: least privilege, lifecycle, and logging for every agent and integration.
• Re-engineer threat models and containment for machine-speed intrusions.
• Ignore synthetic vendor benchmarks; mandate local adversarial red-teaming before operational trust.

“AI Normal Tech” vs “AGI by Tuesday”: Security Advice That Survives Either Future 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.

My Anton’s Security Blog (And Podcast!) Quarterly this covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify, now with VIDEO).

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
2. Security Correlation Then and Now: A Sad Truth About SIEM
3. Can We Have “Detection as Code”?
4. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
5. Revisiting the Visibility Triad for 2020 (update for 2025 is here!)
6. Beware: Clown-grade SOCs Still Abound
7. Why is Threat Detection Hard?
8. Top 10 SIEM Log Sources in Real Life?
9. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
10. SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025

Top 5 posts with paper announcements:

1. New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (paper 2 of the series)
2. New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2026 … we are in reviews now!)
3. New Paper: “Future of the SOC: Forces shaping modern security operations”
4. New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
5. New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (the classic 2021 ASO paper!)

3 random fun posts, must-read:

• Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!
• Shadow Agents: A New Era of Shadow AI Risk in the Enterprise
• Anton’s Vibe Coding Experience: A Reflection on Risk Decisions

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

1. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil (our best episode! officially!)
2. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw
3. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
4. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
5. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
6. EP17 Modern Threat Detection at Google
7. EP156 Living Off the Land and Attacking Critical Infrastructure: Mandiant Incident Deep Dive

(also see our NEW 2025 reflections blog about the show)

Now, fun posts by topic.

Security operations / detection & response:

• “Security Correlation Then and Now: A Sad Truth About SIEM”
• “Migrate Off That Old SIEM Already!” (VIDEO, a 2026 update is coming soon!)
• “Measuring the SOC: What Counts and What Doesn’t in 2025?” (Google Cloud Blog)
• “Can We Have “Detection as Code”?”
• “Revisiting the Visibility Triad for 2020” and “SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025”
• “Beware: Clown-grade SOCs Still Abound”
• “Why is Threat Detection Hard?”
• “A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next”
• “Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…”
• “Top 10 SIEM Log Sources in Real Life?” (NEWER VERSION)
• “Debating SIEM in 2023, Part 1”
• “Debating SIEM in 2023, Part 2”
• “Log Centralization: The End Is Nigh?”
• “Living with Multiple SIEMs”
• “Decoupled SIEM: Brilliant or Stupid?”
• “How to Make Threat Detection Better?”
• “SIEM Content, False Positives and Engineering (Or Not) Security”
• “Modern SecOps Masterclass: Now Available on Coursera”

(if you only read one, choose this one!)

Cloud security:

• “Secure cloud. Insecure use. (And what you can do about it)”
• “Using Cloud Securely — The Config Doom Question”
• “Who Does What In Cloud Threat Detection?”
• “How to Solve the Mystery of Cloud Defense in Depth?”
• “Does the World Need Cloud Detection and Response (CDR)?”
• “Use Cloud Securely? What Does This Even Mean?!”
• “How CISOs need to adapt their mental models for cloud security” [GCP blog]
• “Who Does What In Cloud Threat Detection?”
• “Cloud Migration Security Woes”
• “Move to Cloud: A Chance to Finally Transform Security?”

(if you only read one, choose this one!)

How Google Does Security (HGD):

• “How Google Does It: Making threat detection high-quality, scalable, and modern” (Google Cloud blog)
• “How Google Does It: How we secure our own cloud” (Google Cloud blog)
• “How Google Does It: Securing production services, servers, and workloads”
• “How Google Does It: Finding, tracking, and fixing vulnerabilities” (Google Cloud blog)
• “How Google Does It: Collecting and analyzing cloud forensics”
• “How Google Does It: Red teaming at scale” (Google Cloud blog)
• “How Google Does It: Security programs at global scale” (Google Cloud blog)
• “How Google Does It: Securing production services, servers, and workloads”
• “How Google Does It: Collecting and analyzing cloud forensics”
• “How Google Does It: Applying SRE to cybersecurity”
• “How Google Does It: Building an effective AI red team”

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

• “Implementing Secure AI Framework Controls in Google Cloud”
• “Office of the CISO 2025 Year in Review: 3 Key AI Security & Governance Themes”
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise”
• ”Our Security of AI Papers and Blogs Explained” (2024)
• “Securing AI Supply Chain: Like Software, Only Not” (Google Cloud blog)
• “Spotlighting ‘shadow AI’: How to protect against risky AI practices” (Google Cloud blog)
• “Shadow AI Strikes Back: Enterprise AI Absent Oversight in the Age of Gen AI”
• “Cloud CISO Perspectives: How Google secures AI Agents”
• “New Paper: “Securing AI: Similar or Different?“
• “The Prompt: What to think about when you’re thinking about securing AI” (Google Cloud blog)
• “Gen AI governance: 10 tips to level up your AI program” (Google Cloud blog)
• “AI Adoption: Learning from the Cloud’s Early Days” (Google Community blog)
• “How Google secures AI Agents” (Google Cloud blog)
• “Demystifying AI Security: New Paper on Real-World SAIF Applications”
• “To securely build AI on Google Cloud, follow these best practices” (Google Cloud blog)
• “Oops! 5 serious gen AI security mistakes to avoid” (Google Cloud blog)
• “3 new ways to use AI as your security sidekick” (Google Cloud blog)
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise” (Google Cloud Community blog)

(if you only read one, choose this one!)

Fun presentations shared (nothing much new here ):

• SecureWorld 2025 Keynote Déjà Vu All Over Again: Learning from Cloud’s Early Misadventures to Secure AI (2025)
• Detection Engineering Maturity — Helping SIEMs Find Their Adulting Skills (2024)
• Future of SOC: More Security, Less Operations (2024)
• SOC Meets Cloud: What Breaks, What Changes, What to Do? (2023)
• Meet the Ghost of SecOps Future (2023)
• The Future of Log Centralization for SIEMs and DFIR — Is the End Nigh? (2023)
• 20 Years of SIEM (2022)

Enjoy!

Previous posts in this series:

• Anton’s Security Blog Quarterly Q4 2025
• Anton’s Security Blog Quarterly Q3 2025
• Anton’s Security Blog Quarterly Q2 2025
• Anton’s Security Blog Quarterly Q1 2025
• Anton’s Security Blog Quarterly Q4 2024
• Anton’s Security Blog Quarterly Q3 2024
• Anton’s Security Blog Quarterly Q2 2024
• Anton’s Security Blog Quarterly Q1 2024 Lite
• Anton’s Security Blog Quarterly Q3 2023
• Anton’s Security Blog Quarterly Q2 2023
• Anton’s Security Blog Quarterly Q1 2023
• Anton’s Security Blog Quarterly Q4 2022
• Anton’s Security Blog Quarterly Q3 2022
• Anton’s Security Blog Quarterly Q2 2022
• Anton’s Security Blog Quarterly Q1 2022
• Anton’s Security Blog Quarterly Q4 2021
• Anton’s Security Blog Quarterly Q3 2021
• Anton’s Security Blog Quarterly Q2 2021
• Anton’s Security Blog Quarterly Q1 2021
• Anton’s Security Blog Quarterly Q3.5 2020

Anton’s Security Blog Quarterly Q1 2026 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Look, I’m not a developer, and the last time I truly “wrote code” was probably a good number of years ago (and it was probably Perl so you may hate me). I am also not an appsec expert (as I often remind people).

Below I am describing my experience “vibe coding” an application. Before I go into the details of my lessons — and before this turns into a complete psychotherapy session — I want to briefly describe what the application is supposed to do.

We have a podcast (Cloud Security Podcast by Google), and I often feel that old episodes containing useful information aren’t being listened to and the insights from them go to waste. At the same time, for many organizations today, the answer to their current security problems may well have been discussed and solved in 2021. This may be strange to some, but for many organizations, the future is in the past. Somebody else’s past!

So I wanted “a machine” that turns old episodes into role-specific insights, without too much work by a human (me). This blog is a reflection on how things went.

First, my app is using public data — namely podcast transcripts and audio — to create other public data (social media posts). Since the inputs and outputs are public, this certainly made me at peace with vibe coding. Naturally, I needed to understand how the app would be coded, where it would live and what I should do to make it manifest in the real world. So I asked Gemini, and it suggested I use AI Studio by Google, and I did (non-critically) exactly that.

When I started creating the app, the question of storage immediately came up. Jumping a little bit ahead, you will see that authentication / credentials and storage were two security themes I reflected on the most.

You want to read a file from storage, but what storage? More importantly, whose storage? At this point, I had my first brush with anxiety of the “vibe process.” I didn’t want to just vibe code without a full understanding of the data access machinery. I immediately said, “No, I don’t want to store data in my Google Drive using my credentials.” I just didn’t trust it.

In fact, I didn’t trust the app with any credentials for anything — work or personal — at all! Given that I have public data, I decided to store it in a public web folder. AI Studio suggested ways to store data that people might not fully understand, and this is my other reflection: If I’m not a developer, and I don’t know the machinery behind the app, how do I decide? These decisions are risk decisions and “a citizen vibe coder” is very much not equipped to make them. Well, I sure wasn’t.

So what are the security implications of the decisions a developer makes — sometimes guided by AI and sometimes on their own? Can I truly follow an AI recommendation that I don’t understand? Should I follow it? If you don’t understand what happens, I can assure you, you certainly do not understand the risks!

As a result, I did not trust the app with any credentials or authenticated access. Of course, a solution may have been to use throwaway storage with throwaway credentials, but I think I do not need this in my life... Anyhow, many actions that you take during vibe coding, whether suggested by AI or not, have security implications.

In addition, the app interacts with the environment. If the app is being built in a corporate environment, it interacts with corporate security “rules and tools”, and some things you may want to do wouldn’t work. I’m not going into details, but I had a couple of examples of that. If you vibe code at work and you are doing it through, let’s say, shadow AI, there will be things your AI (and you) would want to do, but your employer security would not allow. And often with good reasons too! So you ask AI for more ways and hope it won’t say “just disable the firewall.”

The next conundrum, apart from storage, was output quality. What about quality and those hallucinatory mistakes? Now, I know my app uses an LLM to condense a summary of the podcast transcript into brief insights for social media. And before my app runs, another LLM turns MP3 into text. And it also uses an LLM to make the visual summaries. So, the question is: who handles the mistakes, and how?

For example, I tried to use a certain “well known” model to create a visual summary. Of course, the visual summary was incredibly accurate in most cases, but sometimes “mistakes were made” and words were corrupted (“verifigement” happened to me in one case). If an LLM powered tool can do something, it does not mean it will do it equally well every time (unless you build validators AND the things that you need to do can in fact be validated). So validate!

Further, I read somewhere that the process for dealing with AI mistakes is different from the process for dealing with human mistakes. I am sure I could write another module for the app to check if an image has correct text or add another validation technique, but it is interesting that I faced this very quickly.

Thus I have to deal with “AI-style mistakes”, and I cannot solve them by having a human review everything. I can tell you right away, even from my small project, that having a human review is a non-starter. It’s theoretically correct, but practically won’t happen. It absolutely will not happen if you take the koolaid and transform your business process to be “AI native.” Having humans review boring tasks like checking image text is completely insane. That’s not going to fly. HITL is DOA (for these tasks).

So: storage, credentials, trust, and quality all came up. Another decision arose when I needed to store intermediate results of my insight generation. Again, trust issues surfaced because data storage. AI Studio suggested choices, I asked AI about pros/cons, and made the decision. Again all these decisions are risk decisions.

Finally, certain mistakes come up all the time, repeatedly, and I have to tell AI Studio to write things multiple times because it doesn’t always “get” it (example: my podcast episode URLs). This is another lesson: sometimes it takes multiple prompts, and constant reminders (say to validate the links)

All in all, I’ll continue to experiment — got more ideas that I want. Here are some outputs of my app…

• On X: example example example
• On LinkedIn: example example

Now the explicit lessons for those who need this crisp and actionable:

1. You Make Implied Security Decisions with Every Prompt

When you “vibe code,” you aren’t just describing features; you are making risk and security decisions. If you ask an AI to “save this data,” and you don’t specify how or where, the AI may choose the path of least resistance — usually a public bucket or a local file with cleartext credentials. In the world of AI-generated code, silence is a security decision.

2. Credentials and Storage: The Boring Stuff is Still the Hard Stuff

Storage and credentials were the key themes for me. This is the great irony of modern development: AI can write a complex LLM orchestration layer in seconds, but it may struggle to help a novice set up a secure, encrypted secrets manager. The “plumbing” of security remains the primary friction point.

3. AI Mistakes Require a New Response Model

Traditional QA seems designed for deterministic human error. AI “style mistakes” (like corrupted words in a visual summary) are stochastic and weird. And common! Human review is a “non-starter” for these tasks. Security and quality validation for AI-generated content must itself be automated (AI-on-AI validation) because humans simply won’t do the “deathly boring” work of checking verbatim accuracy at scale. Turtles all the way down can happen to you.

4. Corporate Guardrails vs. AI Ambition

The AI you vibe code with may not know your corporate policy. It will suggest “awesome” features that would immediately trigger a compliance violation. A few times while vibe coding, I heard a subtle lawyercat meowing in the air duct… When vibe coding in a corporate environment, you quickly hit the wall where “what the AI wants to do” meets “what security allows.” This reinforces the need for platform-level guardrails rather than just merely developer education.

5. Public Data is the Only “Safe” Vibe

My “peace of mind” came from the fact that your inputs and outputs were already public. To me, this is the only way to vibe code safely without a full understanding of the underlying security stack. The moment you move from “public podcast audio” to “proprietary customer data,” the risk model shifts from “fun experiment” to “data breach.”

Anyhow, this was my mildly-AI-assisted stream of vibe consciousness.

Enjoy the show! Now with video!

Anton’s Vibe Coding Experience: A Reflection on Risk Decisions was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is my completely informal, uncertified, unreviewed and otherwise completely unofficial blog inspired by my reading of our next Cloud Threat Horizons Report, #13 (full version, no info to enter!) that we just released (the official blog for #1 report, my unofficial blogs for #2, #3, #4, #5, #6, #7, #8, #9, #10, #11 and #12).

My favorite quotes from the report follow below:

• [in Google Cloud] “software exploitation overtook credentials as the primary initial access vector for the first time.” and “Threat actors exploited third-party software-based entry (44.5%) more frequently than weak credentials.” [A.C. — some of you may say this is because AI is making more zero days, but a dozen more mundane answers may be correct instead]

• “While threat actors continued to use brute-force attacks against weak credentials, the increase in RCE represents a pivot toward more automated exploitation of unpatched application-layer vulnerabilities.” [A.C. — to some extent “creds or vulns” debate is rather pointless as the real answer is “both”, and it varies by environment too, see below]
• “Threat actors continued to transition from traditional phishing to voice-based social engineering (vishing), and credential harvesting from third-party SaaS tokens to facilitate large-scale, silent data exfiltration.” [A.C. — again, this means “AND” not “OR” because classic phishing still works well in many cases, but yes “credential harvesting from third-party SaaS” has become very fruitful too]
• [overall] Still “Identity compromise underpinned 83% of compromises. [A.C. — so, yes, “creds” still beat “vulns” on many environments]

• “High-volume data theft operations — executed through compromised but legitimate access channels — remained the primary goal for threat actors, with our metrics showing they targeted data in 73% of cloud-related incidents.” [A.C. — again, not new, but very useful data confirming the running trend. Beware!]
• “The window between vulnerability disclosure and mass exploitation collapsed by an order of magnitude, from weeks to days.” [A.C. — again, some of you may see the invisible robot hand of an AI here, but, as usual, the reality is more complicated…]
• “Trend analysis from 2008–2025 indicates cloud services will soon surpass email as the primary data exfiltration pathway.” [A.C. — $32B reasons to finally get serious about it across all clouds?]
• “45% of intrusions resulted in data theft without immediate extortion attempts at the time of the engagement, and these were often characterized by prolonged dwell times and stealthy persistence.”
• “The traditional incident response model is no longer viable when dealing with containerized workloads and serverless architectures where data can vanish in seconds.” [A.C. — a very useful reminder here! Cloud is cloudy! Don’t be that guy who thinks that cloud is a rented colo. Cloud is not JUST somebody else’s computer.]
• “Threat actors used large language models (LLM) to automate credential harvesting and transition from a developer’s local environment to full cloud administration access.” [A.C. — this really should not be news for anybody in 2026, but if it is, HERE IS SOME NEWS: BAD GUYS USE AI!]
• Thus “Prevent LLM exploitation as an extension of living-off-the-land (LOTL) by treating LLM activity with the same scrutiny as administrative command-line tools.” [A.C. — or, as I say, “with AI agents, every prompt injection is an RCE”]

Now, go and read the CTHR 13 report!

Related posts:

• Google Cloud Security Threat Horizons Report #12 Is Out!
• EP112 Threat Horizons — How Google Does Threat Intelligence podcast
• Google Cloud Security Threat Horizons Report #11 Is Out!
• Google Cloud Security Threat Horizons Report #10 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #9 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #8 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #7 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #6 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #5 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #4 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #3 Is Out!
• Google Cybersecurity Action Team Threat Horizons Report #2 Is Out!
• Illicit coin mining, ransomware, APTs target cloud users in first Google
• Cybersecurity Action Team Threat Horizons report

Google Cloud Security Threat Horizons Report #13 (H1 2026) Is Out! 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.

It’s not every day you get to reflect on a journey that started as an odd “googley” startup and culminates in a shiny Leaders placement on a Gartner Magic Quadrant for SIEM 2025 (MQ).

When I joined Chronicle in the summer of 2019 — a name now rolled into the broader Google SecOps product (with SOAR by Siemplify and threat intel by Mandiant) — it was very much a startup. Yes, we were part of Alphabet, but the spirit, the frantic energy, the drive — it was a startup to its core.

And here’s the kicker (and a side rant!): I’m fundamentally allergic to large companies. Those who know me have heard me utter this countless times. So, in a matter of weeks after joining a small company, I found myself working for a very large one indeed.

To me, that pivot, that blending of startup momentum and big company scale, is, in many ways, the secret sauce behind our success today. It turns out, you need both the wild ambition of a young vendor and the solid foundation of a massive enterprise to truly move the needle (and the dots on the MQ … but these usually reflect customer realities).

The MQ and the Price of Poker

Now, as a reformed analyst who spent eight years in the Gartner trenches, I’ll clear up a misconception right away: the Magic Quadrant placement has precisely zero to do with how much a vendor pays Gartner. Trust me, there are vendors in highly visible SIEM MQ positions who’ve probably never sent Gartner a dime over the years.

Conversely, there are large organizations that have paid a fortune and have been completely excluded from the report. The MQ placement reflects customer traction and market reality (usually — there are sad yet very rare exceptions to this, and I will NOT talk about them; there is not enough whiskey in the world to make me). MQ placement is a measure of genuine success, not a destination achieved by writing a big check.

The Evolution of SIEM: Where Did the Brothers Go?

Reflecting on the last few years in SIEM (not 20 years!) and looking at the current MQ, a few things that were once controversial are now conventional wisdom:

1. SIEM must be SaaS and Cloud-Native. I’m old enough to remember when the idea of trusting your security data to the cloud was an existential debate. Today, with the relentless attack surface expansion, perhaps more people are realizing that the biggest risk is actually running a vulnerable, constantly-compromised on-prem SIEM stack. Data gravity shifted.
2. SIEM and SOAR are fully merged. They are, in essence, two inseparable brothers forming the core of modern SIEM — detection and response. SIEM is really SIEM/SOAR in 2025. Standalone SOAR vendors do exist and some “AI SOC” vendors are really “SOAR 3.0”, but these are — IMHO — outliers compared to the mainstream SIEM.
3. The UEBA brother got absorbed, but … Remember the mid-2010s, when User and Entity Behavior Analytics (UEBA) was the new shiny toy, all driven by cool machine learning? While it was an equal brother to SOAR for a moment, it has now largely been absorbed into the detection stack of the main SIEM product. Machine learning’s importance for basic threat detection has subtly decreased (odd…isn’t it?). UEBA has become a single, albeit important, feature within the engine, not a standalone platform.
4. Some XDR vendors graduated to real SIEM. EDR-centric SIEM vendors (XDR, if you have to go there), have landed. IMHO, these guys will do some heavy damage in the market in the next 1–2 years.

The Most Powerful Force in the Universe: IT Inertia

When I left Gartner, I famously outlined one key lesson from my analyst time: IT inertia is the most powerful force in the universe.

When you look at the MQ, you might see what looks like “same old, same old,” with certain large, established vendors still floating around. This is NOT about who pays, really! You might not believe it, but this placement absolutely reflects enterprise reality. Large vendors don’t die immediately.

Case in point: it took one particularly prominent legacy SIEM vendor (OK, I will name this one as it is finally dead for real, ArcSight) almost ten years to truly disappear from the minds of practitioners. Most companies were abandoning that technology around 2017–2018), but the vendor only truly died off in the market narrative in 2025. The installed base hangs on, dragging the demise out over a decade.

AI, Agents, and the Missing Tsunami

Finally, a quick note on the current darling: Generative AI and AI Agents.

While some vendors (and observers) expected a massive, dramatic impact from Generative AI on this year’s MQ, it simply hasn’t materialized — yet. As other Gartner papers will tell you, AI does not drive SIEM purchasing behavior today.

Why? Gartner’s assessment is based on customer reports. Vendors can yell all they want about how AI is dramatically impacting their customers, but until those customers report observable, dramatic improvements and efficiencies to Gartner, the impact is considered non-existent in the MQ reality.

The AI tsunami is coming, but for now, the market is still focused on the fundamentals: cloud-native scale, effective detection, and fast/good (AND, not OR) response. Getting those right is what puts you in the Leaders Quadrant. The rest is just noise…

Other SIEM MQ 2025 comments can be found here (more to be added as they surface…)

P.S. The “reformed” analyst reference comes from Tim and our Cloud Security Podcast by Google

SIEM, Startups, and the Myth (Reality?) of IT Inertia: A Reformed Analyst Reflects on SIEM MQ 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Amazingly, Medium has fixed the stats so my blog / podcast quarterly is back to life. As before, this covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify).

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
2. Security Correlation Then and Now: A Sad Truth About SIEM
3. Can We Have “Detection as Code”?
4. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
5. Revisiting the Visibility Triad for 2020 (update for 2025 is here!!!)
6. Beware: Clown-grade SOCs Still Abound
7. Why is Threat Detection Hard?
8. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
9. Top 10 SIEM Log Sources in Real Life? (updated 2024 version)
10. Anton and The Great XDR Debate, Part 1

Top 5 posts with paper announcements:

• New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (paper 2 of the series)
• New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2025 … we are researching now!)
• New Paper: “Future of the SOC: Forces shaping modern security operations”
• New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
• New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (the classic 2021 ASO paper!)
• New Paper: “Future of SOC: Transform the ‘How’” (Paper 5)
• New Paper: “Securing AI: Similar or Different?“
• “New Office of the CISO Paper: Organizing Security for Digital Transformation” (paper)
• “10 ways to make cyber-physical systems more resilient” (paper)

NEW: recent 3 fun posts, must-read:

• A Brief Guide for Dealing with ‘Humanless SOC’ Idiots
• “Maverick” — Scorched Earth SIEM Migration FTW!
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise”

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

1. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil (our best episode! officially!)
2. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
3. EP8 Zero Trust: Fast Forward from 2010 to 2021
4. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
5. EP17 Modern Threat Detection at Google
6. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
7. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw

Now, fun posts by topic.

Security operations / detection & response:

• “Security Correlation Then and Now: A Sad Truth About SIEM”
• “Migrate Off That Old SIEM Already!” (VIDEO!)
• “Measuring the SOC: What Counts and What Doesn’t in 2025?” (Google Cloud Blog)
• “Can We Have “Detection as Code”?”
• “Revisiting the Visibility Triad for 2020” and “SOC Visibility Triad is Now A Quad — SOC Visibility Quad 2025”
• “Beware: Clown-grade SOCs Still Abound”
• “Why is Threat Detection Hard?”
• “A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next”
• “Stop Trying to Take Humans Out of SOC … Except … Wait… Wait… Wait…”
• “Top 10 SIEM Log Sources in Real Life?” (NEWER VERSION)
• “Debating SIEM in 2023, Part 1”
• “Debating SIEM in 2023, Part 2”
• “Log Centralization: The End Is Nigh?”
• “Living with Multiple SIEMs”
• “Decoupled SIEM: Brilliant or Stupid?”
• “How to Make Threat Detection Better?”
• “SIEM Content, False Positives and Engineering (Or Not) Security”
• “Modern SecOps Masterclass: Now Available on Coursera”

(if you only read one, choose this one!)

Cloud security:

• “Secure cloud. Insecure use. (And what you can do about it)”
• “Using Cloud Securely — The Config Doom Question”
• “Who Does What In Cloud Threat Detection?”
• “How to Solve the Mystery of Cloud Defense in Depth?”
• “Does the World Need Cloud Detection and Response (CDR)?”
• “Use Cloud Securely? What Does This Even Mean?!”
• “How CISOs need to adapt their mental models for cloud security” [GCP blog]
• “Who Does What In Cloud Threat Detection?”
• “Cloud Migration Security Woes”
• “Move to Cloud: A Chance to Finally Transform Security?”
• “It’s a multicloud jungle out there. Here’s how your security can survive“

(if you only read one, choose this one!)

How Google Does Security (HGD):

• “How Google Does It: Making threat detection high-quality, scalable, and modern” (Google Cloud blog)
• “How Google Does It: How we secure our own cloud” (Google Cloud blog)
• “How Google Does It: Finding, tracking, and fixing vulnerabilities” (Google Cloud blog)
• “How Google Does It: Red teaming at scale” (Google Cloud blog)
• “How Google Does It: Security programs at global scale” (Google Cloud blog)

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

• ”Our Security of AI Papers and Blogs Explained” [this has a whole lot of AI security fun links that you so want to click!]
• “Securing AI Supply Chain: Like Software, Only Not” (Google Cloud blog)
• “Spotlighting ‘shadow AI’: How to protect against risky AI practices” (Google Cloud blog)
• “Shadow AI Strikes Back: Enterprise AI Absent Oversight in the Age of Gen AI”
• “No Deep AI Security Secrets In This Post!”
• “New Paper: “Securing AI: Similar or Different?“
• “The Prompt: What to think about when you’re thinking about securing AI” (Google Cloud blog)
• “Gen AI governance: 10 tips to level up your AI program” (Google Cloud blog)
• “AI Adoption: Learning from the Cloud’s Early Days” (Google Community blog)
• “How Google secures AI Agents” (Google Cloud blog)
• “Demystifying AI Security: New Paper on Real-World SAIF Applications”
• “To securely build AI on Google Cloud, follow these best practices” (Google Cloud blog)
• “Oops! 5 serious gen AI security mistakes to avoid” (Google Cloud blog)
• “3 new ways to use AI as your security sidekick” (Google Cloud blog)
• “Shadow Agents: A New Era of Shadow AI Risk in the Enterprise” (Google Cloud Community blog)

(if you only read one, choose this one!)

NEW: fun presentations shared:

• Detection Engineering Maturity — Helping SIEMs Find Their Adulting Skills (2024)
• Future of SOC: More Security, Less Operations (2024)
• SOC Meets Cloud: What Breaks, What Changes, What to Do? (2023)
• Meet the Ghost of SecOps Future (2023)
• The Future of Log Centralization for SIEMs and DFIR — Is the End Nigh? (2023)
• 20 Years of SIEM (2022)

Enjoy!

Previous posts in this series:

• Anton’s Security Blog Quarterly Q2 2025
• Anton’s Security Blog Quarterly Q1 2025
• Anton’s Security Blog Quarterly Q4 2024
• Anton’s Security Blog Quarterly Q3 2024
• Anton’s Security Blog Quarterly Q2 2024
• Anton’s Security Blog Quarterly Q1 2024 Lite
• Anton’s Security Blog Quarterly Q3 2023
• Anton’s Security Blog Quarterly Q2 2023
• Anton’s Security Blog Quarterly Q1 2023
• Anton’s Security Blog Quarterly Q4 2022
• Anton’s Security Blog Quarterly Q3 2022
• Anton’s Security Blog Quarterly Q2 2022
• Anton’s Security Blog Quarterly Q1 2022
• Anton’s Security Blog Quarterly Q4 2021
• Anton’s Security Blog Quarterly Q3 2021
• Anton’s Security Blog Quarterly Q2 2021
• Anton’s Security Blog Quarterly Q1 2021
• Anton’s Security Blog Quarterly Q3.5 2020

Anton’s Security Blog Quarterly Q3 2025 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.