Dr Anton Chuvakin Blog (Original)

Can AI Let You Jump SOC Maturity Levels? (Spoiler: Only the Boring Half)

anton@chuvakin.org (Anton Chuvakin) — Fri, 18 Sep 2026 15:31:58 -0700

Back in my analyst days, I built maturity models for a SOC (2018), a SIEM (2018), vulnerability management (2017) and threat intel (201?). Later, just for fun, I cooked up a simple SOAR adoption maturity model (2022). All of them were vaguely CMM-shaped: you start ad hoc, you get defined, you get measured, you get optimizing, magic! The ordering was not decorative. Each level existed because the one below it produced something the next level needed. Largely, you cannot jump levels, and if you do jump, you land in clown realm.

this is how Gemini imagines this blog

2026, now the pitch has changed. With AI (agentic, of course!), the story goes, a low maturity SOC can leap to maturity Level 3 or 4 “because AI”. No slog through the “defined process” desert, no “organic” growth through stages. Buy the agents, skip the years!

If you attended my RSA 2026 peer session, you saw the buyer-side version of this: “AI in a SOC sounds great, we will just wait for our SIEM/SOAR vendor or MDR to give it to us.” Same assumption, that the new version of the tool carries the maturity boost with it. Sadly, in reality AI can generate the paperwork of a mature SOC in an afternoon. It cannot give you the institutional memory to know what your own systems actually do.

Ten years ago, in “Jumping Security Maturity Fail”, I endorsed a reader’s line that you can jump technologies, but you can’t jump maturity. I’d like to re-examine that in the age of agents. Because some of it has changed. Just not the part vendors are selling. Think of this as “Jumping Security Maturity Fail, Part 2. 10 Years Later.”

Where this post sits

This is a bridge between two things I’ve been writing about. On one side, the AI-ready SOC pillars and how to plan the journey to them. On the other, the “Stop Building a 2003 SOC with AI” series (Part 2, Part 3), which argues the target SOC in 2026 should look nothing like the 2003 one (more on “SOC 2026” from scratch in a few days…)

The question in between: if the destination has changed, does the path still have mandatory stops? That is what “jumping maturity” is really asking.

The claim, restated so it can be tested

“AI lets you skip maturity stages” quietly conflates two different things:

Stage outputs — the artifacts a mature SOC has: playbooks, parsers, detections, runbooks, dashboards, workflows for various humans, skill profiles for humans to hire, etc
Stage prerequisites — the organizational state a mature SOC is in: it knows its environment, owns its processes, trusts its data, has a working feedback loop.

AI can generate the outputs of Level 3 for a Level 1 SOC in an afternoon. You can always say “add automation”, “make this playbook better faster”, “more AI…add even more AI…MOAR AAAIII!!!”

Still, it cannot generate the organizational prerequisites, because those are not documents. They are things an organization has learned about itself by operating. Once you split the journey along that line, the “jump” question mostly answers itself.

Typical SOC Maturity Journey (Woefully Oversimplified)

Level 1 — Ad hoc. Some logs, some alerts, heroics. “Nobody knows what server4 does, but Joanna might, let’s call her.”
Level 2 — Defined. SIEM with intentional use cases (hopefully, output-driven, not “what data do we have? Let’s shove it in!”), documented triage and (some) IR runbooks, named owners (for some things, some are even the right owners…), basic metrics.
Level 3 — Managed. SOAR playbooks beyond “baby’s first phishing playbook”, some threat-informed detection, log source health monitoring (logs volume drop? alert!), MTTx that is tracked and acted on (sometimes).
Level 4–5 — Optimizing. Detection engineering as a discipline (the DE series), a continuous detection / continuous response loop, hunting that feeds detection, an improvement culture. This sets you on a path to ASO end state.

So, let’s get “an AI jumprope” and start jumping!

Part A: What AI genuinely lets you jump

These are the labor-intensive artifacts of each level — the things that took quarters to write, not the things that took years to learn.

Runbook and playbook authoring. Fifty credible playbooks, one afternoon. The writing effort that used to gate Level 2→3 is gone. This one you can jump. There are caveats, like that some of the playbooks will suck, but for many teams fixing a 80% playbook is not 20% faster than making one from scratch, but essentially 5X faster… SOC process docs, playbooks, etc is where jumping is legit.
Parsers and normalization. Onboarding long-tail log sources was a classic Level 2 grind. Largely shortcut-able now (with lots of caveats; for tricky log sources the “fully machined” parser will suck). You can jump here, but you may trip and fall.
Baseline detection content. “Reasonable coverage of common threats that matter to you” no longer requires a detection engineering team to bootstrap. You can “machine” some custom detection quick, and some will even work. Keep in mind, here you can jump but not very far: you won’t arrive on “full auto” process for turning intel into detections that work well for you.
Tier 1 triage as a stage. Here is the one real skip: the stage where you staff a Tier 1 can be omitted entirely if enrichment and investigation are agentic from day one. You shouldn’t build the 2003 shape at all — triage must die. This is kinda a side-jump from “classic SOC” to modern D&R function, SOCless (if you wish); some aspect thereof. This won’t make you Google or Netflix if you can barely spell “MDR.”
Documenting existing processes. AI can watch tickets and chat and reverse-engineer what people actually do. This shortcuts the “write down what we do” part of Level 2. It does not shortcut the “decide what we should do” part. This is magical!
Metrics plumbing. Dashboards, reporting, the presentation layer of Level 3. (Which metrics matter is a separate, non-jumpable question — see the ASO metrics piece.)
Cross-SOC knowledge transfer. Mature-SOC practice encoded in models and skills means you don’t reinvent detection hygiene from scratch. This jump can get your from “almost nothing” to “pretty damn good” , and it probably won’t suck. Jump away!
Ordering between tracks. The SOAR model already noted that dimensions get mixed up across organizations but each dimension matures in order. AI makes this more true: you can advance the data, detection and response tracks in parallel rather than serially.

So yes — AI compresses the time within a stage, and lets you run some stages in parallel. It also allows some real jumps (yay, those marketing people didn’t lie… this time). That is real, and it is not nothing.

However…

Part B: What must be followed in sequence, AI or not

These are states the organization has to reach. No artifact substitutes for them. Worse, AI amplifies whatever state you are in — mature or clown-grade. If you have read the AI-ready SOC pillars, you will notice this list is the pillars in disguise. That is not a coincidence; readiness and maturity are the same thing viewed from two angles.

Environmental knowledge. Asset context, identity context, ownership. AI cannot tell you what server4 does; it can only ask Joanna faster. If your teams don’t know who owns what, neither will your agents (pillar #2). This is the single hardest prerequisite and it precedes everything else. Part 3 of the 2003 SOC series is essentially a whole post on why local context is the thing agents can’t bring with them. Yes, some fun startups are working on this, so maybe my 2027 assessment will change!
Data foundations before analytics. Collect → trust → detect → automate, in that order (pillar #1, still my favorite). An agent investigating over gappy, untrusted telemetry produces confident nonsense at scale. Low awareness of removed or failed log sources was already a top failure mode in Detection Engineering and SOC Scalability Challenges in 2023; with agents on top it gets worse, not better. And federated SIEM does not exempt you: federation is a topology choice, not a data-quality shortcut.
Process definition before process automation. SOAR proved this and agentic AI is re-proving it. Automating an undefined process gives you an undefined process that runs faster, crazier, with more stochastic chaos (fun!). And, yes, an AI-drafted playbook still needs a human who can say “no, that’s not how we do containment here” — which requires someone who knows how you do containment… Also, here agents may enable speed-up, but not truly a jump over this stage.
Trust calibration. “AI suggests” → “AI acts with approval” → “AI acts, humans audit.” This is inherently sequential because trust is earned from an observed track record in your environment. Vendors cannot ship trust! This is our ASO’s CD/CR applied to the agent itself, and it is also why the “humanless SOC” crowd keeps soiling their pants: they skip the calibration stage and call it a feature.
Ownership and accountability. Someone owns detection quality; someone owns response outcomes. Low maturity SOCs lack this. AI does not create owners. Here you jump — you die.
Feedback loops. The actual magic of ASO sparkles here: incidents feed tuning, false positives feed detection, hunting feeds detection. AI can run the loop faster, but the loop must exist and be wired to real outcomes. In the Deloitte/Google “consistency and creativity” paper we argued you build consistency through the lower levels first, then let creativity loose inside processes that already exist. Substitute “agents” for “creativity” and it reads as if written for 2026.
Organizational stamina. Budget, executive sponsorship, staff retention, tolerance for change, “change budget. Every failed SOAR program died here, not on technology. The ghost of SOAR comes back with vengeance here. Agents do not fix this one. At all.

Wait — didn’t I say you can’t cross a chasm in two small jumps?

Yes I did. In Baby ASO and its sequel I argued that incremental improvement of a “1980s-NOC-DNA” SOC mostly fails, that the fix is radical, and that simply buying modern tools changes nothing if people and process stay put. In, our Deloitte/Google “Evolution or Optimization”, we made the same point with a decision matrix.

So am I now saying “go slow, climb every rung”? Who wants this in 2026?

No. These are two different questions, and conflating them is exactly how “AI lets you jump maturity” gets sold.

Which ladder? Transformation (ASO, engineering-led D&R, the 2003-SOC-must-die argument) is about changing the shape of the SOC. It is a different ladder, not a shortcut up the old one. You absolutely should choose the new ladder, and you should do it in one decisive move rather than two timid ones. Transformation is not incremental.
Can you skip rungs? Whichever ladder you pick, the learning-cost prerequisites in Part B are the rungs. The new ladder has fewer rungs (no Tier 1 stage, no swivel-chair triage stage), which is the genuine good news. But the rungs it keeps — know your environment, trust your data, own your processes, earn trust in automation — are the same ones, and they are still climbed in order. Remember our “AI in security can be magical, but it isn’t magic; It’s a marathon of focused engineering”? This is true!

Put differently: “cross the chasm in one jump” means commit to the transformation and dump the incrementalism/optimizing what you have. This works IRL.

It does not mean the far side of the chasm has no ground rules. AI shortens the new ladder — it does not let you levitate over any chasm obstacle.

The AI-specific failure mode: skipped stages become invisible

The old cargo-cult SOC — a 1-out-of-5 low maturity SOC copying “ninja moves” from a 6-out-of-5, as I described in Clown-grade SOCs — at least failed visibly, funnily and embarrassingly. Get the popcorn! Hunting before you do logging was obviously silly.

The new one is worse. AI papers over the gap with slop. You cannot cross the chasm if you put some slop over it. Agents produce plausible investigations, tickets close, MTTR looks wonderful, and nobody notices that the environment context was hallucinated and the “containment” hit the wrong host. Skipped maturity used to fail loudly. Now it fails quietly.

A usable test: jump vs. borrow

For any element of any stage, ask one question: does this exist because someone had to spend time, or because someone had to learn something about us?

Time-cost elements are jumpable. AI does them.
Learning-cost elements are not. AI can make you learn faster, but you still have to learn.

Corollary for vendor conversations, in the spirit of the RSA 2026 “show me the numbers” advice: when someone claims a stage skip, ask which bucket their claim falls in.

Most “1→3 with AI” pitches are quietly selling the artifacts of Level 3 to a Level 1 organization, and then blaming “process gaps” or vaguely point at “customer immaturity” (right?) when it fails.

So, can you jump?

You can jump the artifacts. You can run tracks in parallel and get through each level in months instead of years. You can — and, perhaps, should — pick the transformation ladder instead of the optimization one. That is a genuinely better deal than the one we had in 2016.

But you cannot jump knowing your environment, owning your processes, trusting your data, or earning trust in your automation. Those are the maturity. The rest was always just the paperwork…

Jumping Security Maturity Fail (2016) — the original “can’t jump maturity” argument
A Simple SOAR Adoption Maturity Model (2022)
Beware: Clown-grade SOCs Still Abound (2019)
Autonomic Security Operations — 10X Transformation of the SOC (2021) and ASO principles
Baby ASO (2024) and The Return of the Baby ASO: Why SOCs Still Suck? (2025)
Future of the SOC papers: Process Consistency and Creativity (3), Evolution or Optimization (4), Transform the How (5)
WTH is Modern SOC, Part 1 (2023)
Simple to Ask: Is Your SOC AI Ready? (2025) and Beyond “Is Your SOC AI Ready?” Plan the Journey! (2026)
Stop Building a 2003 SOC with AI: Part 1, Part 2, Part 3 (2026)
A Brief Guide for Dealing with “Humanless SOC” Idiots (2025)
Detection Engineering and SOC Scalability Challenges (Part 2) (2023, with Amine Besson)
The Ancient Art of SIEM: Why 2003 Problems Look So Familiar in 2026 (2026)
RSA 2026: Agentic Future, Analog Fundamentals (2026)

Can AI Let You Jump SOC Maturity Levels? (Spoiler: Only the Boring Half) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

Survival of the Basics: Which Security Fundamentals Were Secretly Relying on Lazy Attackers?

anton@chuvakin.org (Anton Chuvakin) — Tue, 8 Sep 2026 14:48:17 -0700

A few weeks ago I asked on X and LinkedIn a deceptively simple question: which “security basics” matter more against AI-armed attackers, and which ones don’t matter anymore?

What Gemini think of this blog

[before you freak out about ‘…but Anton, we don’t even have a consensus definition of “security basics’, read on — I gracefully sidestep this critical issue :-)]

I got about 60 answers. Most of them converged on the same reasonable, practitioner-approved, completely unsurprising consensus: the basics aren’t dead, AI just punishes sloppy execution faster. This is true. It has also been true of every attack trend since 1998 (hi Satan! hi Metasploit! hi fuzzing!). If that were the whole story, this post would end here.

But one reply challenged the premise, and it turned out to be the most useful comment in the thread: what can an “AI attacker” actually do that a skilled human attacker couldn’t?

The honest answer today is: nothing.

Still, this has implications related to scale, speed, coverage and a whole lot of other things. Sometimes changing the speed on the attack side should NOT lead to “well, defense should also run faster” arguments. We should “do different”, not run “almost as fast” as the attacker. Let’s think about it!

The scarce resource was never technology. It was attention.

This is also the “secret” why “luck-based” security works for some organizations. Even if they have glaring holes, DMZ CVSS 10s unpatched since 2016, Windows 2003, Red Hat Linux 9 and PHP (oh god, so much PHP!) they may still be in business, and doing sort of OK. That is why I always say that people with 10K unpatched HIGHs do NOT fear Mythos-induced “vuln-apoc” of having 300K unpatched HIGHs. The lift won’t change risk for them (IMHO) So let’s say 30x more vulnerabilities leads to … I dunno … 3% more risk?

Anyhow, for the entire history of this field, the single scarcest resource on the offensive side was skilled (defined broadly, perhaps semi-skilled too) attacker hours. There were never enough competent humans to exploit every reachable vulnerability at every company, craft a convincing lure for every employee, abuse every public S3 bucket and work through every organization’s attack surface.

The attackers did what any rational actor does with a scarce resource: they allocated it. They went after the easiest targets, the juiciest ones, or the ones that happened to be in front of them.

Here is the uncomfortable part. Perhaps you think it is obvious? A surprising share of what we call “security basics” were never really about stopping attackers. They were about not being worth the effort at the moment:

Patch cadence was about closing the window before someone got around to you. Not before someone could, before someone would (This is a profound idea, IMHO. Thanks Claude Fable 5.1!)
Phishing awareness training worked, to the extent it ever did, because mass phishing was sloppy. Crafting a good lure was expensive, so most lures were bad, so “spot the typo” was a real signal.
“We’re not a target” was a risk-acceptance strategy that only made sense if the attacker was choosing targets. Again, “luck based security” was very much a thing.
Coverage metrics like “80% of assets patched within SLA of 30 days” implicitly assumed the remaining 20% was hiding in a pile the attacker wouldn’t bother to sift through. IT sure couldn’t ;-)

None of these controls fail because attackers got smarter. They fail because attacker labor became elastic. When the marginal cost of one more exploitation attempt, one more tailored lure, one more recon pass drops toward zero, there is no such thing as low-hanging fruit anymore. All the fruit gets picked. Ok, this is new! This is fun!

Still, we have seen a similar movie before, and I was there for the first showing. Network scanners in the late 1990s and Shodan in the 2010s did not invent new vulnerabilities. They removed obscurity from the discovery phase and forced everyone to admit that “nobody knows about that server” was not a control.

In my view, AI is doing the same thing one layer deeper: removing scarcity from the exploitation and social-engineering phases.

Whatever you believe about the exact numbers in the recent frontier-model evaluations (end-to-end corporate takeover chains, three-figure attack costs, and so on), the direction is not in dispute. The attacker is no longer rate-limited by their headcount and “attention count.”

The sorting rule

This gives us something better than a list. It gives us a rule.

A [security] basic survives if it works by physics or math. A basic dies if its risk reduction was proportional to attacker effort.

No wire, no access. Network isolation does not care whether the probe came from a bored teenager or an agent running 1,000 recon passes a second. Hey Cisco ;-)
No binary, no execution. Application allowlisting does not care how the entry point was found.
No phishable auth factor, no phish. FIDO2 does not care how convincing the lure is, or whether it arrived as a flawless email or a cloned voice. No chip — no access.
No software, nothing to patch. You cannot exploit what has been removed.

In the “1990s speak”, AI cannot scan your ports, if you don’t have ports. Get rid of the TCP/IP stack while you are at it :-) Conversely, anything that reduces risk by making you slightly harder to attack than the next guy is on the wrong side of this line. So your zero-day laden security tool that runs “input filtering” is shot in the butt…

The matrix: AI resilience × modern feasibility

Back in my Gartner days, we wrote a paper on IT hygiene and which controls actually constitute a foundation. Oh those endless debates on whether NIDS is a basic control in 2016…. I recall you so fondly!

The list below is a first pass at re-running a similar exercise with two axes:

Does it hold against a tireless attacker, and
Can anyone actually deploy it in a modern environment?

BTW, the second axis matters more than people think. A control that is AI-proof, but undeployable is not a security basic. It is a wish at best…

Master table

From this, three things that are emerging as basics, done by a few now and needing to become universal:

Identity verification for humans at hiring and high-risk moments. In-person or equivalent anti-deepfake process for video hiring. This sounded paranoid in 2023. This sounds routine in 2026.
Anything that cuts off network access still works well. If you can gracefully limit connectivity, no attacker — with AI or without — can touch it. This of course wins some degree of Easier Said Than Done prize… but it is still real.
Identity and inventory for non-humans. If you cannot enumerate your agents and service identities, “intent enforcement” is a slide, not a control. Agent security (however defined) cannot be solved unless we solve agent identity.
AI-driven code and data discovery. If your data classification project has been “in progress” since 2019 (or:1989?), the attacker’s is not. So, here you do need to run faster than the attacker, yes.

The patching dilemma, properly stated

Now back to patching. According to many, patching is the ultimate “security basic,” so it deserves its own math. BTW, others say that it is neither security nor basic… Review these first, perhaps.

Under a human attacker, patch coverage was roughly linear. Going from 30% to 80% of assets patched within SLA removed 50 “points of exposure”, because the attacker was not going to find and exploit every one of the remaining gaps. Some of them were effectively hidden by the attacker’s own bandwidth.

Under a tireless attacker (read: AI), exposure stops being “what fraction is unpatched” and becomes “is there at least one reachable, usable, exploitable gap.” That number stays stubbornly close to 1 until coverage approaches 100% for reachable assets. Improving from 30% to 80% may produce close to zero risk reduction. The remaining 20% is not hiding anymore. This is new, and a bit scary. But this is an assumption to test, not a law. We need data!

But if it holds even partially, the levers change:

Shrink the denominator. Fewer things that need patching. This is why attack surface reduction jumps up in importance.
Make the gaps unreachable. Network isolation converts “unpatched” into “unpatched yet irrelevant.” This is why segmentation is back. Microsegmentation grows in importance.
Make patching a rebuild, not a maintenance window. If you cannot rebuild a workload from code in minutes, you are not going to win a speed contest against a vuln storm. This is less a security basic than an IT cornerstone, which is exactly the problem.

So “patch faster” and “patching doesn’t cut it” are both right. The goal survives. The implementation everyone recognizes as “patching” does not.

That pattern repeats across the table: many basics survive as objectives and die as the specific practice we associated with them. Similarly, awareness training survives as “humans exercise judgment” and dies as “annual click-through module.” Least privilege survives as a principle and dies as “someone reviews IAM policies quarterly.”

What this means, operationally

If you take one thing from this: subtract before you add. Before buying the AI-vs-AI tooling that every vendor is now pitching, remove the software you don’t need, cut the wires that don’t need to exist, and finish the asset inventory you’ve been not-finishing since your first CMDB project. These are not exciting. They are also the only controls on the list that a tireless attacker cannot outrun. Niels Provos reminds us of the same.

One more honest observation. Several of the “promoted” basics above (remove unnecessary software, segment aggressively, fix least privilege) have been recommended for 20 years, and no previous threat trend actually motivated organizations to do them. Maybe an attacker who never sleeps and never gets bored finally will. Or … maybe we will spend the budget on AI-powered SOC dashboards instead. I am, as always, an optimist…

Related:

Survival of the Basics: Which Security Fundamentals Were Secretly Relying on Lazy Attackers? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

SIEM: Centralize Like You Mean It, Federate Like You Have To

anton@chuvakin.org (Anton Chuvakin) — Thu, 27 Aug 2026 15:48:57 -0700

(by Anton Chuvakin & Usman Chaudhary)

Prologue: Three Years After “The End Is Nigh”

Back in 2023, one of us wrote “Log Centralization: The End Is Nigh?” — an admittedly incomplete-thought blog with a scary premise: after 20+ years of yelling “centralize your logs!” (the earliest surviving deck is from 2003), we may be running out of places where centralizing all the logs is feasible, workable, or even worth the pain.

The conclusion then was cautious: centralize as long as you can, in as many places as you can, and augment with some form of centrally defined, lightly managed, highly distributed collection. By 2025 the position got more contrarian: the SIEM of 2027 will be roughly “90% centralized / 10% federated,” and anybody promising you the inverse is selling a demo, not an architecture.

This post is the practical sequel. Not “is federation the future?” (it is a future, not the future), but the far more useful question: when, precisely, does the federated SIEM actually work — and when does it blow up in your face at 3AM?

The Breaking Point of the Centralized Vault

For more than two decades, SIEM tools ran on a simple covenant: collect all telemetry into one repository, pay for the ingest and the storage, normalize everything upfront into one grand schema, and query from one console. In the era of predictable on-premises networks this worked — and, frankly, it still works for a lot of organizations.

But multi-cloud sprawl, ephemeral infrastructure, hundreds of SaaS applications and now AI agents have strained it in four specific ways:

The ingest and duplication burden. If you are present in multiple public clouds at scale, you are very likely not collecting logs into one place in one cloud. Egress fees, redundant storage, and pipeline sprawl make that a questionable decision. Add a few hundred SaaS apps, and “one vault” becomes a very expensive fantasy.
The fragile taxonomy tax. Forcing thousands of log sources into one rigid, deeply nested data model creates brittle pipelines. This was largely known since the mid 2000s when the first schema on-read vendors appeared. A minor upstream vendor format change silently breaks parser mappings, and your detection rules go blind without so much as a warning.
The volume-to-value problem. Some log types are hugely useful in bulk and for investigations but almost never trigger a detection on their own — DHCP leases, VPC flow logs, long-tail of DNS resolution logs. Many organizations simply stop collecting them because they are “too costly to centralize” (especially when the SIEM vendor charges per EPS or per GB). That is not a data decision; that is a billing decision masquerading as one (Making that tradeoff an explicit engineering discipline — cost per detection, which telemetry earns full-fidelity treatment — is something we’ve written about in FinOps for SecOps.)
The volume curve just bent. Log growth was already relentless; AI made it vertical. A recent State of Log Management 2026 research found AI workloads drove a 93% increase in log and telemetry volume in a single year, with 1 in 5 organizations seeing growth above 150% — and organizations now exclude an average of 86% of their log data just to manage cost. Read that again: most enterprises are already discarding the vast majority of their telemetry, not by security design, but by budget necessity. Agents generating machine-speed telemetry will not slow this down.

Here is the honest framing, unchanged since 2023: the problem isn’t that the distributed approach is easy. The problem is that the centralized approach is getting harder as volumes, source counts, and geographic sprawl go up. And, as we keep saying in the output-driven SIEM context: if you collect, you pay. Somebody has to own the hard drives.

Note that there is also another driver that is neither cost nor architecture: data sovereignty. For multi-jurisdiction and sovereign-cloud organizations, some telemetry legally cannot cross borders — residency mandates make centralizing certain logs not expensive but impossible. For that class of organization, federation is not a temptation to resist; it is a compliance requirement to engineer for.

The Federated Temptation

Into this gap stepped two families of technology alternatives:

Federated query platforms. Leave the telemetry where it lives — cloud object stores, SaaS vendor event stores, edge repositories… your uncle’s flooded basement ;-) — and push the compute to the data via distributed indexing and schema-on-read.
The open security lakehouse. Decouple storage from analytics: keep structured logs in open formats (Apache Iceberg, Parquet, etc) on cheap — relatively — cloud storage and query them through engines you already have (BigQuery, Snowflake, Databricks, and friends).

Plus the classic third option that predates both — tiering: dump the “less useful” logs into cheap storage and pray to the security gods you never have to search them at speed.

The reality may look different from a marketing glossy or an RSA demo.

Specifically:

real vs demo federation

The pitch is intoxicating: stop paying egress! stop duplicating data! just federate the search! It is also, in specific and bounded conditions, correct. The trouble starts when “specific and bounded” quietly becomes “default.”

The Dark Side of Federation (Read This Before You Sign)

Federated search sounds magical until you are investigating a breach at 2 AM.

Here are the costs and risks you actually have to swallow:

1. It is slower than centralized — unless you architect specifically for speed (and then pay for it)

A federated query across three clouds and forty SaaS APIs is bounded by the slowest source, the tightest rate limit, and the coldest object-storage tier. It looks fast on a demo dataset sitting in one bucket. Cross-source joins on read are expensive by construction. The vendors know this, which is why the serious ones build distributed indexes at the source — but indexes must be built, refreshed, stored, and paid for.

And here is the trap from the 2023 post: if you deploy big indexers in every cloud, you haven’t eliminated centralization — you’ve just created several smaller islands of it. That isn’t inherently bad, but let’s be honest about what you’re doing: you aren’t escaping the architectural tax of centralization, you’re just trading one big central bill and management domain for three smaller ones that will each grow their own operational headaches over time.

2. You trade cost for resilience

This one is rarely on the slide. A centralized SIEM is one thing to harden, one SLA, one on-call rotation. A federated platform is a query engine whose answer depends on N independent sources being up, reachable, authenticated, and under quota — at the exact moment you need them.

You pay less for storage, and in exchange the overall resilience of your detection-and-response platform goes down. Yes, we really do mean it! Every added source is an added dependency, and dependencies fail at the least convenient time, by definition.

Naturally, centralized platforms fail too — but that risk is priced, contractually owned, and covered by one SLA. In federation, you self-insure across N sources. In theory, people assume that “distributed systems” are somehow more resilient. In practice and in this case, they are clearly less so.

3. No assurance the logs are even there

If you simply hope the logs will be there when your magical decentralized query tool reaches for them, you will be disappointed a lot. Sources get compromised, and attackers delete local logs. SaaS retention windows expire. A well-meaning admin “cleans up” a bucket. Then your IR consultant finishes the engagement and says: “Sorry, not sure what happened here — there were no logs — but here is the $100K bill for all the things we tried.” Centralization has a cost, but once you pay it, you reliably own the logs. Federation gives you a pointer, not a possession.

4. Compliance did not get the memo

Many mandates directly require collection and centralization. PCI DSS v4 Requirement 10.3.3, for one, expects audit logs to be promptly backed up to a secure and central log server (or other media that is difficult to modify). Security people love to mock regulations as outdated for the cloud era; in this case they are a stabilizing force, perhaps.

Yes, you can mitigate this in a federated model — object lock, versioning, WORM buckets, immutable retention policies, documented evidence that every source enforces them. But note who does that work: you, the client. The federated search vendor gives you a query layer; it does not give you an audit trail your QSA will accept, at least not without a stressful argument. Budget the engineering time — and the assessor’s skepticism — accordingly.

5. Federated search is workable; federated analytics mostly isn’t

Detection is not the same as search. Continuous complex event processing — stateful detection windows, multi-event sequences, streaming IoC matches at line rate — needs data flowing through one high-speed engine, normalized to something. Mapping blast radius and lateral movement across users, assets, and service accounts needs a persistent entity graph, not a multi-table join fired off on read.

If your algorithms rely on normalized logs, you will wait a very long time for all logs to be normalized “naturally” wherever they sit (OCSF or no OCSF). We have barely made centralized analytics work well; decentralized analytics is a research project, not a product category. To detect real-world threats, you may need a separate tool that sits on a stream of pre-normalized data and allows for fast detections. In the age of AI-speed attacks, speed matters again.

6. Operational toil, and nobody to scream at

A natively designed, integrated SIEM is simpler to run than a multi-component stack you assemble at home. A DIY lakehouse-plus-federated-search-plus-detection-layer is a data platform, and data platforms come with data platform engineers. If you do not employ them, you are not building a federated SIEM; you are building a science project with a SIEM logo. And when it breaks, you lose the underrated benefit of a “single face to scream at.”

7. AI agents do not make it less messy (enough)

AI agents genuinely help here in one specific way: they are patient. An agent can fan out slow federated queries in the background without a human staring at a spinner. But “I didn’t save any logs from X — hey agent, go get me the logs from X” does not work in real life. Worse, watch for the nastiest failure mode: an agent that reports “nothing found” when the truth is “source unreachable.” In a centralized system that distinction is obvious. In a federated one it is a silent false negative, and automation bias will make sure nobody questions it. This is a big deal, folks! Always require explicit status reporting from agents so that absence of evidence does not become evidence of absence.

The Architectural Spectrum: Is There a Middle Path?

Yes — but the middle is much closer to the centralized end than the vendor decks suggest.

Here is the full spectrum, honestly labeled:

Two observations. First, the “classic tiering” row is where many organizations already live comfortably and should probably stay. Second, the jump from “hybrid” to “federation-first” is not a matter of degree — it flips who bears the assurance, compliance, and resilience burden from the platform to your engineering team.

When Can Federated Actually Work? The Criteria

Federation is not a wand; it is a tool for specific conditions. The discipline that matters is deciding — in writing, ahead of time — which bucket each source falls into, rather than discovering the answer mid-incident. For a given log source, federated/decentralized handling works well when all of the following hold:

The use is largely asynchronous. Deep-dive forensics, threat hunting, post-incident review — situations where a query that takes 20 minutes costs you patience, not the company. If an active attacker is moving laterally, you cannot afford an hourglass spinner.
The source is reliable, managed, and tamper-resistant. A robust SaaS platform with documented retention, or a cloud store with versioning, object lock, and retention policies you control and can prove. If the attacker who compromised the host can delete the log, that log is not federated — it is gone.
The volume-to-value ratio is terrible. Petabytes of flows and DNS queries you rarely touch but desperately need when a specific IP shows up in an alert.
The queries are targeted, not fishing. “All DHCP leases for MAC X on date Y” — yes. “Show me anything weird across everything” — no, that is what your hot core is for.
No compliance mandate requires a central, immutable copy of this data — or you have already built and evidenced the equivalent controls at the source.
Nothing in your real-time detection depends on it. Federated data is for context and investigation. The moment a detection rule needs it, it belongs in the core.
Somebody owns the “is it still there?” question. A central catalog of what lives where, with retention, ownership, and health checks — centrally defined, lightly managed, highly distributed. Without this, you have not federated your logs; you have misplaced them.

If any criterion fails for a given source, the pragmatic answer is boring: centralize that source.

The Pragmatic Hybrid: Mapping Telemetry to Tiers

Rather than an all-or-nothing choice, modern architectures converge on an integrated high-speed core for continuous detection and graph correlation, coupled with open lakehouse federation for on-demand investigation.

Concretely:

Strategic Takeaways for Security Leaders

Avoid dogmatic extremes — but anchor on centralized. Pure centralization creates cost and schema bottlenecks; a fully disconnected DIY federated stack trades those for operational complexity, lost resilience, performance surprises, and toil. Look for platforms that integrate fast streaming detection with flexible storage options, with the center of gravity firmly in the integrated core.
Separate hot detections from cold investigations, and expect AI to widen the gap. Route identity, endpoint, and control-plane data through real-time detection; stow voluminous low-signal telemetry in cost-effective open lakehouses. AI-driven detection will increase the pull toward the hot core — models correlating across identity, endpoint, and cloud events need the data in one place, fresh, and normalized. The federated tier is where AI agents go for context, at their own pace, with a hard rule that “unreachable” is never reported as “nothing found.”
Inventory before you federate. Know which logs exist, where, for how long, under whose control, and with what immutability guarantees. If you cannot answer those questions for a source, you are not ready to leave it there.
Build on open standards — but “open” is not “free.” Open formats preserve agility and keep security telemetry aligned with the enterprise data architecture. Somebody still runs the lakehouse, and that somebody works for you.
Test the 2 AM query. Before production, run your worst realistic investigation query across every federated source during a simulated outage of one of them. The result tells you more than any vendor benchmark.

The Verdict

The centralized approach to logs will work as long as it can and in as many places as it can — that sentence has survived three years and two blog posts unchanged, and we see no reason to retire it. The physics of cloud-scale data means we will augment the centralized brain with centrally defined, lightly managed, highly distributed collection and federated analysis. Fine. Just remember what you are buying: cheaper storage in exchange for assurance, resilience, speed, and compliance work that lands on your desk.

Choose the 10% wisely. Or prepare to explain either your cloud storage bill to the CFO, or your missing logs to the regulator — and only one of those conversations ends with a budget adjustment. We aren’t going back to the 1980s where you need to telnet to see logs. But we are entering an era where every log has to earn its place in the center.

(A version cross-posted by Usman here)

SIEM: Centralize Like You Mean It, Federate Like You Have To was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

Stop Building a 2003 SOC with AI: Local Context, Failure Modes and Your Path (Part 3)

anton@chuvakin.org (Anton Chuvakin) — Wed, 26 Aug 2026 09:53:50 -0700

In Part 1 of this series, we dumped a pile of uncomfortable questions on you and promised answers. In Part 2 of the series, we talked about why 1990s-2000s alert triage must die.

The core thesis, if you recall: if you add AI agents into a legacy, swivel-chair SOC structure, you are essentially building a robotic horse pulling an 1850 buggy. Sure, it saves on hay. It probably costs more in tokens.

2003 SOC + AI = somewhat better 2003 SOC.

That’s it. That’s the ceiling. So today we continue answering the questions and plotting this course.

The Hard Problem Nobody Markets: Local Context

Here is the dirty secret of every AI SOC deployment: the model (well, not just the model, but the entire system) is brilliant at general security knowledge and clueless about your environment. What is normal for your finance team in mid July? Which “server talking to the internet” is a shadow-IT disaster versus a legitimate — if a bit odd — business process? How engineering workloads talk to the outside when the code is being pushed to prod? All these matter for detection signal analysis.

“Make tribal knowledge machine-consumable” is what CMDB, ASM/CASM, asset inventory, and many expert opinions have promised and not delivered. If the AI is a robotic horse pulling your legacy 1850 buggy, ignoring Local Context is why it’s still stuck on the same dirt road...

What is actually different now — and what we would actually try:

Harvest context from the investigation loop itself. When the agent hits an unknown, it should not just escalate; it should ask a specific question (“is svc-etl-07 expected to authenticate from Ireland?”), and the human answer should be captured as a durable, attributed context object — not buried in case notes. Your SOC generates hundreds of these decisions a week today and, essentially, throws all of them away. This is the one genuinely new mechanism agentic AI brings to the context problem: the machine can now ask, at scale, in context, at the moment the answer is cheap to give.
“Context as code” (ha, I just made it up!), with owners and expiry. Context objects get a source, an owner, a confidence, and a review date. “The finance file server talks to this SaaS” is true until it isn’t. Unowned context is a future false negative with a countdown timer.
“Buy” context from the business, not from the SOC. App owners answer questions about their apps far better than analysts guessing from netflow. Route unknowns to them, in their tools, with a 24-hour SLA — and track answer rates as an org-health metric. This has worked in some places in regards to DLP alerts (I recall these conversations in my Gartner days, it also worked for some elite teams in general)
Past cases as curated reference — with a promotion process. Somebody must authoritatively designate “this case was handled correctly; AI, learn from this. That one? Never speak of it again.” Make it a real workflow: two-person promotion, provenance, expiry, re-certification, and the ability to revoke a reference case and re-run everything that leaned on it.
Measure context coverage. What fraction of investigations were completed without an unresolved unknown? That number is your real AI SOC readiness score, and it is far more honest than any maturity model.

This is also why “fully automated detection engineering” remains, in our view, a hybrid effort: the dependency on local, inconsistent, poorly-documented environment context makes pure machine DE a fantasy for now. Machines draft; humans anchor to reality.

Now, these context gaps directly drive the machine failure modes. Let’s go there next.

When the Machine Is Wrong: Failure Modes and Accountability

At some point in the future, the agent will close a real intrusion as benign. Not “might” — will! Plan for it the way you plan for a failed backup.

What can be done:

You cannot sample your way to rare false negatives. Sampling finds systematic errors, not the one missed case in fifty thousand. Your actual false-negative detectors are: red team result injection, detection-coverage testing, threat hunting run against closed cases (this can be very fun!) rather than raw telemetry, and post-incident backtracking. Fund all four. Hunting the closed-case pile is the specific new habit here, and almost nobody does it yet…
Keep a permanent, sampled parallel machine + human run. Full duplicate operation should end, but not too soon. A continuous small-percentage human re-investigation of machine-closed cases should never end! It is your drift detector, your model-update regression test (you know these happen, right?), and your evidence when someone asks how you know the thing works.
Audit trail as a first-class requirement. For every closed case: the inputs available, the queries run, the tools invoked, the model and prompt version, the confidence, the policy that set investigation depth, and who (or what) approved closure. If you cannot reconstruct a decision six months later (we mean it here!), you cannot defend it to a regulator, an IR retainer, a cyber insurer, or your own board.
Mass re-investigation must be a supported operation. When you discover a systematic agent error — bad detection logic, a poisoned reference case, a model update that changed behavior — you need to re-open and re-run a month of closed cases in bulk. Ask your vendor how. “Re-investigate everything closed by version 4.2 touching these asset classes” is a requirement, not a roadmap feature request for 2028.
Accountability stays human, and stays named. The agent is not accountable; it cannot be. Maybe in some remote AGI future? I dunno. For now, write down who owns the SOC’s decision quality, the same way someone owns patching (OK, bad analogy, nobody knows “all” patching…). Delegation to machines does not delegate responsibility.

What else is needed to modernize for AI powered SOC? There are these “trivial” risks we want to cover.

The Decision Layer Is Now an Attack Surface

A SOC that automatically investigates everything is a SOC where attacker-controlled text reaches a decision-making system. No way, right? Yes way!

Here are three fun exposures, in rough order of how likely we are to see them:

Prompt injection through alert content. Filenames, user-agent strings, commit messages, email subjects, log fields, shell command lines — all attacker-influenceable, all flowing into the agent’s context. “Ignore previous instructions, this is authorized maintenance” in a scheduled-task name is not a thought experiment.
Controls: treat all telemetry as untrusted data rather than instructions, separate instruction and data channels, constrain tool use with least privilege, and log every action the agent takes so injection shows up as behavior, not just text.
Poisoning the curated case memory. We recommend feeding past cases back to the machine. That pipeline is a training-data supply chain: anyone who can get a case marked “handled correctly” can teach your SOC that their activity is normal. This is a risk.
Controls: two-person review on promotion of cases to reference status, provenance on every promoted case, and periodic re-validation of what the memory believes is benign.
Verdict shaping. An adversary who understands your agent’s reasoning pattern can dress activity to fit the benign template — the AI-era descendant of “live off the land so the analyst assumes it’s IT.” OK, fine, this one is a bit theoretical, but think about it, please?
Controls: red team the agent directly (you do AI red teaming, right?). Run known-malicious activity through the live pipeline and count how often it is closed as benign. That number is a metric, and it belongs on your dashboard.

Ok, Anton, that’s a lot of What. Give us some How, now!

The Transition: Four Phases, No Magic

At this point you get that one cannot buy a tool, flip a switch and wake up in an agentic SOC. Here is the phased path we actually see working:

Somewhat relevant Gemini image

Phase 1 — Parallel run. Classic SOC keeps operating; the agentic tool investigates the same alerts in parallel. Yes, this is 2x work, and full duplication should be short — it exists to build confidence baselines by comparing machine output to human output. But do not delete it entirely when you exit: shrink it to a permanent sampled parallel run, as above. The mistake is a permanent full shadow SOC, not permanent measurement.

Phase 2 — Implanted agentic tasks. Classic process remains, but discrete alert subsets get routed to the AI: phishing first (hello, everyone who failed to automate this with SOAR!), then EDR alerts, then identity, then network. SIEM or SOAR sends the artifact to the AI SOC; results flow back into your case management. This phase runs for months, expanding scope as trust grows. Expand on evidence — measured agreement rates, canary catch rates, purple-team results per alert class — not on vibes or vendor roadmap.

Phase 3 — Exception-driven operations. Full automation for the majority of investigations. Humans set investigation-depth criteria (and token budgets), act as the final validation boundary, and handle the explicit “unknown / inconclusive / hand-to-human” bucket. This is the humans decide what machines do phase — the real agentic SOC.

Phase 4 — Full auto with broad automatic remediation. Let’s be honest: today this is mythical for most environments. Aspire, but don’t promise it to your CISO with a date attached. This is frankly mythical as of now, unless your environment is very modern, very predictable and you are very, very lucky…

Sound familiar? It should — this is the SOAR lesson replayed. Organizations that used SOAR only for enrichment or only for phishing got stuck in a permanent Phase 2 and called it transformation. Don’t repeat that with better marketing.

Next up: how SOC metrics must change when volumes and closure rates stop mattering — decision quality, investigative cycle time, escalation rates, canary catch rates, cost per investigation, AI error budgets — and how to run the human-to-AI feedback loop so corrections actually improve future performance instead of vanishing into the void. Stay tuned! This one may take a while…

Related blogs:

Stop Building a 2003 SOC with AI: Local Context, Failure Modes and Your Path (Part 3) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

The Feynman Bet: Why You Still Won’t Vibe Code Your SIEM (Today)

anton@chuvakin.org (Anton Chuvakin) — Thu, 20 Aug 2026 15:26:28 -0700

Gemini about this blog

The Feynman Betting Strategy and the Inertia of Security

Many years ago, I read a book by the legendary quantum physicist Richard Feynman. One story from his time at Los Alamos during the war has always stuck with me. Feynman entertained himself by making bets with his colleagues about various wartime events in Europe.

He won — and won a lot. He won so often that his colleagues, naturally impressed by his scientific stature, assumed he had developed some profound forecasting technique rooted in the depths of quantum physics.

Eventually, Feynman revealed his “secret.” It was deceptively simple: he always bet that things would stay exactly as they were. Would the Germans take a certain city? “No.” Will the third bombing raid destroy a key Rhine bridge? “No.” Was a major dramatic change imminent? “No.” And so he won. He won a lot.

He didn’t need quantum mechanics. He needed a base rate. Feynman was, arguably, the world’s first Bayesian troll.

The Power of IT Inertia

I’ve used this story frequently in discussions about security predictions because it mirrors a lesson I learned during my eight years as a Gartner analyst: IT inertia is the most powerful force in the universe. It is the only force known to survive three digital transformations, two technology revolutions and a dozen re-orgs. If a company does something a certain way today, it’s a very safe bet they’ll still be doing it that way tomorrow. Or in 2033.

Now, I’m not an idiot, and neither was Feynman. This strategy is not foolproof; it fails dramatically when the world actually does change. Also, Murphy’s Law guarantees it fails at the worst possible moment, right when you are puffed up full of “predictioneering” hubris.

The deeper message is that most predictions miss the speed of change, not the direction. We are prone to Amara’s Law: we overestimate the short-term impact of new tech and underestimate the long-term impact. The Feynman bet wins in the short term precisely because everyone else is overestimating; it (eventually) loses in the long term because the long term is where the underestimated change finally shows up.

OK, Anton, where are you going with this? This isn’t Instagram… I promise, this is coming!

AI, “Vibe Coding,” and the DIY Trap

Lately, I’ve been reading a lot about organizations’ ability to “vibe code” replacements for their own security tools (discussion).

When I see a prediction that AI will radically transform “cyber everything” in the next 90 days, my Feynman instinct screams to bet against it. History is on my side. Similarly, enterprise DIY projects have a uniquely high failure rate — if you failed to build a custom Hadoop cluster in 2010, why would you succeed in building a custom, AI-generated SIEM or EDR today? The technology changed; your organization didn’t. And the Hadoop cluster didn’t fail because of Hadoop. But here is where the debate gets more interesting than “DIY bad, vendor good.”

It’s Not the Code. It’s the Content (and the Data)

A security tool is not just code. It is code + content + data, in wildly varying proportions. And AI is — today — spectacularly good at the first and mediocre-to-useless at the other two. You can vibe code an agent; you cannot vibe code a threat research team (you can give an agent to a threat research team and they will be much better as a result). You cannot vibe a decade of malware telemetry into existence. This means the vibe coding question has a different answer per category:

Firewall: mostly code (+ policy you already own). Packet filtering logic is decades old, exhaustively documented, and thoroughly represented in every model’s training data. The “content” — the rules — is yours to begin with. Vibe coding a basic firewall is… actually kind of plausible? (Please don’t for many other reasons! But it’s plausible, based on this particular theory) Content ratio: low.
EPP/EDR: the code is the cheap part. The agent is software, sure. But the value is the content: detection rules, behavioral analytics, ML models trained on billions of endpoint events, cloud reputation, and threat intelligence refreshed continuously by attack data. Vibe the agent all you want — you have vibed yourself a very elaborate way to detect nothing. Content ratio: extreme for EPP, large for EDR.
SIEM: kinda sorta in the middle. (Naturally. SIEM has never once in its life given a straight answer.) The platform — ingest, store, search, correlate — is code, and honestly not magical code. But then come the hundreds of parsers that must not drift (but must evolve with data) , the detection content that must map to your environment, and the real killer: data gravity plus years of accumulated operational muscle. You can vibe a log pipeline in a weekend (OK, maybe, I have not tried). Can you vibe 500 parsers, a detection rule library, and a team that knows what “normal” looks like in your environment? Partially maybe? Not really. Content ratio: medium-high, data gravity: brutal.
GRC: workflow code + your own policies. Closer to the firewall end - the “content” is largely your documents, your controls, your evidence. Content ratio: low-to-medium. This one will “vibe-die” soon, it seems.

So the Feynman bet decomposes nicely: bet against vibe-replacement in proportion to the tool’s content-and-data ratio — not its code complexity. AI collapsed the cost of code. It has not collapsed the cost of content, and it definitely has not collapsed the gravity of data.

Now, behold the X polls! If somebody comes to you and says “we will #vibe code a replacement for our market-leading $CATEGORY tool,” you say…

So the X crowd’s gut matches the framework: the more a tool’s value lives in vendor content and accumulated data, the harder the audience laughs at the vibe coder…

“What If This Time It’s Different?”

Everything in my soul says the skeptics are right. And yet, there’s a quiet voice in the back of my mind asking: “Anton, what if this time it’s different?”

It is dangerous to silence that voice. “The pace of change has never been this fast, yet it will never be this slow again” (Justin Trudeau, Davos 2018). And: “If the rate of change on the outside exceeds the rate of change on the inside, the end is near” (Jack Welch). Feynman vs. Trudeau, base rates vs. exponentials — pick your prophet.

Here’s the mechanism, though, not just the vibe. The Feynman bet fails at exactly one point: when the cost of change drops below the cost of inertia.

Call it the inertia break-even point. I’m seeing data points from highly respected experts suggesting that complex, low-vulnerability software can now be rewritten with AI — which means for code-heavy, content-light tools, we may have already crossed break-even. For content-heavy tools, we haven’t. Yet. The line will move; the question is how fast, and Amara’s Law says we’ll get the timing wrong in both directions.

The Bottom Line: If you ask me today whether a typical large enterprise should vibe code their own SIEM, I’d take a deep breath and still say no. But that “no” is now a priced bet, not a reflex — and the price changes by category. Firewall-shaped things: the odds are shifting. EDR-shaped things: Feynman still collects your money. SIEM: kinda sorta, as always.

Bet against change — but re-price the bet every quarter. Inertia is a base rate, not a law of physics.

Keep an open mind. Buy infrastructure :-)

Related blog:

The Feynman Bet: Why You Still Won’t Vibe Code Your SIEM (Today) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

So Is Your SOC AI-Ready? Part 3: API or Die Audit!

anton@chuvakin.org (Anton Chuvakin) — Wed, 19 Aug 2026 10:13:26 -0700

This is Part 3 of the AI-ready SOC series (Part 1, Part 2), and it is focused on validating readiness for pillars #1 (SOC Data Foundations) and #4 (Modern SOC Technology Stack). Specifically, it is about the audit I promised in Part 2:

“The ‘API or Die’ Data Audit: You need to audit every critical data source to ensure it has a robust, well-documented API. An ‘enthusiastic’ AI agent will query your systems at a frequency no human ever could. If your CMDB or logging tier can’t handle the load, the agent won’t just fail; it might unintentionally DoS your internal infrastructure.”

Steampunk SOC again!

BTW, I now have too many blog series, so let me deconflict this here:

Series 1 Focused on assessing your overall SOC readiness for AI arrival:

Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer! (Part 1)
Beyond “Is Your SOC AI Ready?” Plan the Journey! (Part 2)
THIS BLOG (Part 3)

Series 2 Focused on changes to people /process side of SOC during AI arrival:

Anyhow, back to the topic

Why This Audit, Why Now?

If we’ve learned anything from the last decade of SOC evolution, it’s that manual is the enemy of scale. Remember toil? When you introduce AI agents into your workflow, they don’t “click buttons” in a UI like a human analyst — they consume APIs (and use CLI like humans, I guess). Yes, agents can screen-scrape and click around, but you probably don’t want to burn GPU cycles teaching a frontier model to navigate your SIEM’s 2009-vintage web UI (not a joke, I saw this happen!). But, yes, that’s a party trick, not an architecture.

If your telemetry sources have weak, poorly documented, limited-capability, or aggressively rate-limited APIs, your expensive AI agent is essentially a Formula 1 driver stuck in a traffic jam behind a horse buggy. It has the horsepower (Ha! I got a pun! Take that, Tim) to win, but it has nowhere to go.

And here is the scarier version: a human analyst queries a SIEM maybe 10 times an hour. An AI agent might query it 100 times in 30 seconds to correlate one alert (agents looove to brute force, as we all know). Multiply by a batch of alerts during an incident, and your “AI SOC transformation” becomes a self-inflicted DoS on your own EDR, GRC, or CMDB (if you have that thing). Fun times!

So before you buy the shiny agentic thing, audit your primary telemetry and context sources (EDR, NDR, cloud logs, identity, CMDB, ticketing, etc.) with cold, cruel eyes (Claude wrote this, I am sure its eyes are very cold…). Here is how.

So before you buy the shiny agentic thing, audit your primary telemetry and context sources (EDR, NDR, cloud logs, identity, CMDB, ticketing, etc.) with cold, cruel eyes (Claude wrote this, I am sure its eyes are very cold …). Here is how.

Phase 0: The “Cold Eyes” Inventory

Don’t just list your tools; list your data paths.

The goal: Identify every system an analyst touches during a typical investigation (SIEM, EDR, CMDB, identity, DHCP logs, ticketing, that one Wiki page everybody swears by, etc.).
The test: If an analyst has to “swivel-chair” — copy-paste from one tab to another because there is no integration — that is a Priority 1 gap. Whatever the human bridges manually, the agent cannot cross at all.
The how: Start by interviewing your SOC / D&R analysts and shadowing them during a real investigation. Review SIEM/EDR query logs to see which systems are consistently touched. Check SSO/IAM logs to see where they authenticate. Scan your internal wiki or shared drives to identify those “secret” cheat sheets or side-tools they rely on. If they are swivel-chairing (hi, 1990s SOC!), you will find the proof in their browser history or their documented SOPs.

Now run every item on that list through the five tests below.

Test 1: Connectivity & Accessibility (The “Can I Even Get There?” Test)

An AI agent needs a direct, programmatic path to the data. If a human has to “export a CSV”, “log into a separate portal”, or, worse, “Slack another human”, that data source is dead to the AI (agent UI scraping is doable, but sad and not scalable or reliable).

Machine-readable documentation: Does the tool have a public (or well-documented internal) REST/gRPC API, or an MCP server? If the only way to learn the API is “emailing a support engineer,” you’ve already failed. (And no, MCP is not magic — it’s a protocol, not a personality transplant for your legacy tool.)
Modern authentication: Does it support secure, programmatic auth (OAuth2, OIDC, scoped API keys, workload identity)? If it requires a “service account” with a static password and no MFA, congratulations, your AI enablement project just became a security liability. Remember vulnerability scanners that wanted an admin password for all systems back in the 2000s to do authenticated scanning?
Network pathing: Can your AI orchestration layer — wherever the agent actually lives — reach the endpoint without weeks of firewall hair-pulling? This seems trivial for 2026, but I assure you it is anything but. And also: if this is too easy, perhaps you have a 1990s flat network?

Test 2: Performance & Throughput (The “Agentic Load” Stress Test)

This is where most “legacy” security tools break, and where you must test before an incident tests it for you.

Concurrency limits: What is the maximum number of concurrent API requests the tool allows? If the answer is “one,” your agent is going to be very lonely. Keep in mind, agents like to swarm (OK, yours may not yet, but this is coming).
Rate limiting: When exactly do the “429 Too Many Requests” errors start flying? Or, worse, the response is there, but the data is 1–99% incomplete? Will your threat intel provider cut you off the moment an agent starts enriching a batch of 23000 IPs because it, well, felt like it? Find the burst capacity of your stack now, on your terms. Don’t wait until you need it.
Response latency: Measure time-to-first-byte on realistic queries. If a simple process tree query takes 45 seconds, your agent times out, retries, times out again… and your MTTR goes up… if you are lucky. Or, something else breaks, if you are not. “Multi-hour data queries” (hi again, the 1990s!) are an automatic fail here.

Test 3: Data Quality & Schema (The “Context Fidelity” Test)

Having an API is step one. Having useful data at the end of it is step two. AI agents are only as smart as the context they can read when they need it — GIGO is still law! BTW, the agentic spin on GIGO is of course being “confidently wrong.”

Structured output: Does the API return JSON or YAML? If your legacy ticketing system returns a 2MB “stream of consciousness” text (well, text-ish) blob, your AI will burn tokens (and, thus, your money) just trying to find the root cause. Force structured entry at the source (yes, this is the case management revamp from Part 2, and yes, this is painful and not fun at all).
Schema stability: Is the API versioned? If the vendor silently renames src_ip to source_address, your agent logic breaks instantly and quietly (OK, this is not fair, a smarter model will in fact figure this one out… but it will cost ya!). Quiet breakage in a SOC is the worst kind.
Joinable fields: Does the telemetry include correlation keys (cloud_instance_id, user_sid, asset IDs) so the agent can pivot to the next tool without guessing? Agents that guess entity resolution are agents that hallucinate incidents…

Test 4: Functional Depth (The “Can It Actually Do Work?” Test)

An AI-ready API shouldn’t just be for reading data; eventually it is for taking action — with the human/agent handoff lines you drew in Part 2 firmly in place. Due to vulnerability apocalypse fears, a lot of vendors started to promise automatic remediation, and guess what? This means needing APIs to act on systems.

Read/write balance: Can the API perform response actions — isolate a host, disable a user, update a rule? Read-only APIs give you an AI-powered observer, not an AI-augmented SOC of the future.
Granular scoping: Can you give the agent least-privilege access? “Read all logs” but “isolate only these subnets”? If the tool’s permission model is “admin or nothing,” that’s a hard stop for autonomy.
Server-side filtering: Does the API support filtering at the source (?status=active&severity=high)? If the agent must pull 10,000 records to find 5, you’re paying token tax on the vendor’s laziness. But hey, somebody is getting rich…

Test 5: The Auth & Agent Identity Layer

Agents need keys — and keys need governance. Free wisdom from the 2010s, I guess. The 1990s are finally over!

The audit question: Do you have a centralized way to manage API credentials and identities for your agents — as workload identities with registration, ownership, rotation, and revocation? Let me guess … mmmm … the answer is ‘no’?
The risk: “Shadow AI” starts the day a helpful analyst hands their personal API key to an LLM to “help out.” Your audit must define how agents authenticate, how permissions are scoped, and who owns each agent identity (yes, really). If you can’t answer “which agent did this and on whose behalf?”, you are not ready for an agentic SOC.

The “Agentic Readiness” Scorecard

For every primary tool, assign a score:

Level 1 — The Dinosaur: No API. UI-only. (Status: replace, or accept it’s invisible to your AI. Or suffer and pay for scraping the UI “agentically”)
Level 2 — The Relic: Basic API, poorly documented, slow, falls over under load. (Status: high risk)
Level 3 — The Standard: Decent REST API and docs, but read-mostly, limited response capabilities. (Status: usable with additional tools?)
Level 4 — The Modernist: Robust, fast, versioned APIs with real write capabilities and granular RBAC. (Status: AI-ready)
Level 5 — The Agent-First: Native agentic support (MCP, high concurrency, agent-aware auth, feedback loops). (Status: the gold standard, and yes, these exist in 2026)

Where You Arrive: The Binary Map

When you finish, you shouldn’t have a “nice-to-have” list. You should have a binary map:

Machine-ready: API is fast, documented, structured, and scoped. Your agents can use it.
Legacy debt: No API, or a brittle one. These sources are invisible to your AI.

And here’s the uncomfortable conclusion: if a data source is invisible to your machine, it should probably not be part of your modern detection strategy. We are moving to a world where “if it isn’t via API, it didn’t happen.” By the way, those living in organizations with modern IT stacks are surprised this is even an issue worth discussing. But, I assure you, it is…

This audit is also, not coincidentally, foundational work for an engineering-led SOC and ASO: the same API-first plumbing that feeds your agents feeds your detection-as-code pipelines, your metrics (pillar #5!), and your humans too. Fix it once, win three times.

So: which of your “critical” tools is actually an API-less paperweight? Name and shame (or just vent) in the comments!

Related blogs and podcasts:

So Is Your SOC AI-Ready? Part 3: API or Die Audit! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

The Ancient Art of SIEM: Why 2003 Problems Look So Familiar in 2026

anton@chuvakin.org (Anton Chuvakin) — Thu, 13 Aug 2026 16:09:57 -0700

Lately, I’ve been reading a lot of insightful posts related to best practices in SIEM, detection, and logs (written in 2026). The interesting bit is that a lot of these best practices looked good to me and made sense — and yet, they felt incredibly familiar…

As I dug deeper, I realized they reminded me of things I had written 10, or sometimes even 20 (23 in one case) years ago.

Dark and ancient art of SIM/SEM to become SIEM

What does this mean? I hope you don’t take this post as something written purely to prove that I’m very smart and totally prescient (I am smart / I am not prescient). No, the actual lesson here is that things changed much less at many organizations than people assume.

So, let’s review some of the older wisdom from the mid-2000s and early 2010s and match it up against what people report as today’s best practices.

#1 Centralization

Let’s start with pure comedy. In 2003, I recommended that people … wait for it… centralize security data (funny enough, in 2023, I briefly questioned this idea). But on a more serious note, this is still — mostly — good advice, with some notable exceptions [A.C. — look at that emdash sucker there, got it?].

Excerpt from Anton Chuvakin 2003 slide

#2 Context

I am surprised about it myself, but back in 2003 I was a big fan of adding what later became known as context data into a SIEM. Asset info, vulnerability scans, etc need to go into your SIEM (well, SIM and SEM at the time; SIEM was born in 2005).

Excerpt from Anton Chuvakin 2003 slide

#3 Planning

Since the day I first laid my eyes on a SIEM in January 2002 (well, technically, it was a SIM), I realized that project planning makes or breaks a SIEM deployment. 20+ years did NOT teach many this lesson, as modern advice, sadly, is the same. Generic advice? Sure, but also evergreen!

Excerpt from Anton Chuvakin 2011 slide

#4 Buy vs DIY

You may think because I worked for vendors, I was always a fan of “buy from a vendor” as a default choice, and only resort to “build” or “buy then build” as an exception.No, I saw too many DIY SIEM disasters. Here we confirm that despite major changes in tooling (AI agents), for most organizations build vs buy decision remained largely the same, for now.

Excerpt from Anton Chuvakin 2010 slide

(a fun ancient exception: a certain “I-suspect-who” had to analyze 300TB (~ 1 trillion messages) of logs in 2005, and advice they were given is: DIY, nothing commercial can handle it … and as we learned later won’t for another 5–7 years at least)

#5 Output-driven SIEM

The idea of “Output-driven SIEM” was stolen by me in 2011 and then popularized widely my Gartner “megaphone.” I did a refresh on this in 2025, but, in brief, it means “deploying your SIEM in such a way that NOTHING comes into your SIEM unless and until you know how it would be utilized and/or presented.” This is very relevant today, because in the past it was hardware and not perhaps it means tokens. But “SIEM costs kill” message remains.

#6 Crown Jewels

Sometime around 2013, I was giving many clients this advice: do NOT start your security monitoring (really, D&R) scope from the most important assets, or crown jewels. Many a CISO argued hard (‘but Anton, what about “important first.”’ Yes, SAP is important but if you onboard SAP logs before firewall logs, you will probably die in the process. And step 2 will never happen. Modern advice seems to match perfectly.

#7 Retention

“Keep logs. If you don’t know better, keep logs for a year.” I said around 2006–2008. Then in 2019, I got somewhat shocked that keeping logs for a year is seen as a luxury by many. Today with data lakes and all sorts of crazy cloud storage people … well… often still don’t keep logs long enough.

Excerpt from Anton Chuvakin 2011 slide

#8 SIEM vs Log Management

SIEM vs LM was a hot topic in the mid-2000s. We had architectured for broad collection in LM and security focused subset in a SIEM. Today this just means SIEM and a data lake. So, this also aged very well.

#9 Log Data Mining aka UEBA

A lot of my early work in what I called ”log data mining” predated UEBA, and my predictions that rules will be complemented by analytics (hi Captain Obvious!) aged weirdly. They agend well, then not well, then well again. Today we have non-deterministic AI analyzing logs, and back then we had Marcus Ranum “NBS” for Never Before Seen….

#10 Misc

In my consulting days (pre-Gartner, which means pre-2011), I did a lot of “best / worst practices” presentations, such as this one. I think these aged well, but perhaps because they were a bit generic. Example that aged very well include:

“Phased Approach: Rather than feeding “all” logs into a SIEM immediately, organizations should start with limited devices (e.g., DMZ) and events (e.g., authentication)” then expand.
“Focus on Use Cases: SIEM requirements should be driven by specific problems the organization wants to solve, such as tracking unauthorized access or detecting web application hacking.”
“Tuning Ability: The organization must accept responsibility for customizing and tuning the tool, as “out-of-the-box” SIEM deployments rarely succeed.”

All of the above are from the early to mid 2000s. These also aged well, despite being almost ¼ of a century old…

Lessons? So what does it mean that advice from 2003 still works in 2026? A few uncomfortable lessons:

SIEM problems were never technology problems. They were — and are, and perhaps will be — people, process, and organizational physics problems wearing a technology costume. This is why 23-year-old advice still applies: the vendors shipped new tech, but nobody shipped new organizations.
The “what” aged well; the “how” got replaced. Output-driven collection, phasing, use cases, context, tuning ownership — all still true. What changed is the plumbing: appliances became data lakes, EPS became tokens, correlation rules got a non-deterministic AI sidekick. If your strategy changes every time the plumbing changes, you never had a strategy. Good news!? Yes!
Cost pain is eternal; only the currency changes. In 2003 you ran out of hardware, in 2015 you ran out of ingest budget, in 2026 you run out of tokens. “SIEM costs kill” is apparently a law of nature, so architect for it (output-driven!) rather than being surprised by it. Again.
If the advice didn’t change, but you still don’t follow it, the advice was never the problem. Everyone “knows” to plan the deployment, start with use cases, and own the tuning. Knowing isn’t the bottleneck. Doing is. AI won’t fix that either — it will just help you not-do it faster.
The industry has a roughly 7-year memory. Every cycle, “new” best practices get rediscovered — at $xxx/hour consulting rates — by people who could have read my 2005 SlideShare for free. Reading old stuff is the cheapest security investment you’ll make this year?

So no, I’m not prescient. The organizations are just slow (as I said after leaving Gartner: “IT inertia is the most powerful force in the Universe”). We had 23 years of progress, and the best practice is still “have a plan and don’t ingest garbage.” See you in 2043, when this post ages well too…

Related posts:

The Ancient Art of SIEM: Why 2003 Problems Look So Familiar in 2026 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

Ah, that can be, ahem, complicated :-)

anton@chuvakin.org (Anton Chuvakin) — Thu, 13 Aug 2026 08:16:24 -0700

Ah, that can be, ahem, complicated :-)

Originally published at Medium.

Yes, very true - and this is the topic I covered a lot on this blog, all the way down to…

anton@chuvakin.org (Anton Chuvakin) — Thu, 13 Aug 2026 08:16:09 -0700

Yes, very true - and this is the topic I covered a lot on this blog, all the way down to https://medium.com/anton-on-security/antons-alert-fatigue-the-study-0ac0e6f5621c

Originally published at Medium.

Stop Building a 2003 SOC with AI: Triage Must Die (Part 2)

anton@chuvakin.org (Anton Chuvakin) — Tue, 11 Aug 2026 11:58:33 -0700

(with key ideas from Augusto Barros)

In Part 1 of this series, we dumped a pile of uncomfortable questions on you and promised answers. The core thesis, if you recall: if you add AI agents into a legacy, swivel-chair SOC structure, you are essentially building a robotic horse pulling an 1850 buggy. Sure, it saves on hay. It probably costs more in tokens.

2003 SOC + AI = somewhat better 2003 SOC.

Gemini creation :-)

That’s it. That’s the ceiling.

So today we start answering the questions. And we start by attacking the most sacred cow of traditional security operations: the alert triage process.

Let’s Kill Triage. Seriously.

For a quarter of a century, the standard SOC pipeline has been carved in stone:

Detect → Triage → Investigate

Human L1 analysts sit in front of a flashing alert queue, spending 3–7 minutes per alert (and sometimes much more…) deciding whether something is a false positive or deserves escalation to somebody more senior (and more expensive…and just as human). We built this process for one reason and one reason only: humans do not scale (For the purist: OK, they do scale, but linearly with pay). Triage was a compromise born of “built-in” scarcity. We — obviously — never had enough human eyes to deeply investigate every signal hitting the SIEM, so we invented a cheap filtering step to ration the expensive investigation step.

Sometime in the 2010s, SOAR made triage easier, by first adding alert enrichment and then …. in many places, nothing more. In others, select alert types were triaged by the hard-coded playbooks.

Now, let’s do AI. It doesn’t get bored correlating IPs or summarizing logs at 3am. It doesn’t quit after 18 months to go do threat hunting somewhere else. Because machine scale allows comprehensive analysis of every signal, the triage step can just go and vanish.

The new pipeline collapses to:

Detect → Investigate.

Why spend minutes “skin-deep” triaging an alert to decide whether it deserves a look, when the machine can perform a full, deep investigation of 100% of your alerts? Gather the local context, pull the historical cases, map the artifacts, render a verdict with evidence — all before a human ever shows up.

For the impatient: the cost discussion is coming! Don’t freak out … just yet.

Wait — Can They Actually Do That Today?

Fair question, and here is where we owe you honesty rather than a slide.

Today’s “AI in SOC” ranges from “genuinely investigates” to “enriches beautifully then bullshits confidently.” The second one is an old SOAR chained to a language model aka the exact trap this blog warns about. If you cannot tell which one you bought, you probably bought the second one…

Our rough test for telling them apart, usable in a POV:

Does it ask new questions, or only pre-decided ones? Enrichment runs a fixed lookup list. Investigation forms a hypothesis, queries, reads the result, and changes what it asks next. Watch the query sequence, not the summary.
Does the conclusion move when the evidence moves? Feed it two near-identical alerts with one materially different fact. If the verdict does not change, you have a narrator.
Does it ever return “inconclusive”? A system with no uncertainty output has no calibration. Run away.
Does it show its work in a form a human can re-run? Queries, artifacts, timestamps — not just a paragraph asserting “no evidence of compromise.” OK, this is tricky, I admit.

Where does this leave the “kill triage” claim? Honestly: directionally right, unevenly available. For high-volume, well-bounded, evidence-rich alert classes — phishing, commodity EDR detections, identity anomalies — deep machine investigation of 100% is achievable now.

For multi-stage, low-signal, who-the-hell-knows-what-happened, context-heavy cases it is not, and anyone telling you otherwise is, ahem, exaggerating, to put it mildly. The pipeline collapse is real; the coverage is a rollout, not a switch.

Depth Gating: The New Triage Wears a Suit

So, if deep investigation is token-expensive — and it is, sorry! — then somebody, somewhere, is deciding how deep the machine goes on which alerts. We can call this decision A New Triage, while bending the truth a bit. It just moved from a human clicking a queue to a policy sitting in a config file, and pretending otherwise is how you end up with an unexamined control that quietly decides what you never look at. And, just as before, mistakes and decisions cost money.

So let’s examine it. Explicitly:

Who owns the investigation depth policy? Not procurement. Not “whoever set up the tool.” This is a detection-engineering artifact with a named owner, version history, and a review cadence.
Who owns the budget, and what happens when it runs out mid-month? If the honest answer is “all investigations get shallower,” you have just invented an availability attack against your own SOC. Define degradation behavior in advance: which alert classes keep full depth, what gets queued, what pages a human (do you still have said human handy?)
What is systematically under-investigated? Every gating rule creates a shadow. Write the shadow down. What gets triaged out? Review it quarterly against your threat model, not against your token bill. Well, OK, against both, really, but mostly vs the threats.
Are your thresholds guessable? If low-severity, off-hours, or particular-source alerts predictably get the cheap path, an adversary who learns that shapes activity to land there. Treat depth policy as security-sensitive configuration, not ops tuning.

Triage stops being a job and becomes a policy — and policies get attacked, drift, and rot. This is the broader theme of the whole series: humans move from doing the work to defining the rules for the work, which is harder, not easier, and needs the governance to match.

(And yes, “cost per investigation” becomes a real SOC metric — one that will fight with “detection coverage” in every budget meeting. More on the metrics carnage in a future part.)

So What Do the Humans Do?

Remember my favorite modern SOC question? “It’s 2030, you have a SOC, what do humans do?” If machines own frontline investigation for the vast majority of alerts, what happens to the people? Two dominant paradigms are emerging, and the answer for most organizations will be “both, in some mix”:

1. The Elite Threat Hunter Model. With the routine noise fully investigated by machines, humans are finally unchained from the queue. They pivot to hypothesis-driven hunting, deep-dive research, and the nuanced multi-stage attacker behaviors where AI (for now!) still struggle. Humans hunt; machines grind. Sorry, but “100% automated hunting” is not (today).

2. The Engineering-Driven SOC Model. This is our classic ASO mantra: humans build machines; machines do the work. Analysts evolve into detection and SOC engineers. Their day shifts from consuming alerts to building, tuning, testing, versioning and (yes) rolling back the AI logic and detection-as-code pipelines. Treat agents as engineering artifacts, not magic pets.

And the New L1 Is…

“OK, but classic L1 is dead. What do entry-level humans do?” OK, this is tricky! This is where a lot of “humanless SOC” enthusiasts embarrass themselves.

I think the new starter role is AI validation: sampling and reviewing AI-generated case files, validating the agent’s query logic against the data it actually had, hunting for hallucinated context and confidently wrong conclusions (got those?), and owning the “1% bucket” — the exceptions where the AI raises its digital hands and says “I don’t know, human, help me.” (Your AI SOC must have an explicit process for this bucket. If your vendor’s agent never says “I don’t know,” run.)

Now the two objections this role deserves, because “verify-and-validate is the new L1” is a slogan until you answer them.

Objection 1: where does the competence come from? Checking an agent’s homework requires knowing what good looks like — and L1s historically learned that by doing triage, badly, for a year. We removed the training ground and assumed the graduates.

So build the ground back deliberately:

Structured re-investigation as training. New analysts independently work a small set of already-closed cases without seeing the agent’s verdict, then compare. This is deliberate practice, and it doubles as an evaluation signal on the agent.
Curated case libraries as curriculum. The promoted-case archive is the best SOC textbook your org will ever have, sequenced from trivial to nasty. Use it as onboarding, not just as machine memory. You have AI, use it!
Rotation into hunting and detection engineering on a schedule, not “when someone has time.” Validation-only career paths produce validators, not investigators.

Objection 2: automation bias is real and it will eat your review process. Humans reviewing plausible, well-written machine verdicts approve them, every time. You do that, I do that (hey, I just did this with this blog sentence to illustrate this very point). You can’t order people not to. Well, you can order, but they won’t do it. This is one of the best-documented findings in human-automation research, and hoping your team is special is not a thing.

Design against it:

Blind review first. The reviewer forms a verdict before seeing the agent’s. Order matters more than effort here.
Canary cases. Inject known-bad cases with deliberately wrong agent verdicts into the review queue at a low rate. Measure catch rate. This measures the reviewers, and it is the only honest read on whether your validation layer is real.
Stratified, not random, sampling. Random sampling over a population that is 99% benign finds nothing. Oversample: agent-reported low confidence, unusual query paths, crown-jewel assets, first-time-seen behaviors, and anything closed suspiciously fast.
Incentives on catches, not throughput. If reviewers are measured on cases reviewed per shift, you have built a rubber stamp with a salary. Measure disagreements raised and misses found.

What’s Next?

Killing triage and re-blueprinting the humans is necessary but not sufficient. If your SOC still reports “alerts closed per analyst per shift,” you are measuring a process that no longer exists.

Next up: failure modes, local context pain, how SOC metrics must change when volumes and closure rates stop mattering …

Related blogs:

Stop Building a 2003 SOC with AI: Triage Must Die (Part 2) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.

Beyond the Vulnerability Apocalypse: Scaling Your Basics and Vulnerability Management

anton@chuvakin.org (Anton Chuvakin) — Thu, 23 Jul 2026 12:40:24 -0700

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.

Kinda sort framework but high level, for sure

The four moves: SEE → DECIDE → CONTAIN → RUN

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:

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.

Originally published at Medium.

“AI Normal Tech” vs “AGI by Tuesday”: Security Advice That Survives Either Future

anton@chuvakin.org (Anton Chuvakin) — Wed, 15 Jul 2026 16:12:22 -0700

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.

Originally published at Medium.

From Cloud to Chaos: Defining Shared Responsibility for AI Security

anton@chuvakin.org (Anton Chuvakin) — Thu, 2 Jul 2026 10:26:07 -0700

For 15 years (!), many of us who have touched cloud security have struggled with the shared responsibility model for cloud security. As…

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:

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.
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.
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.

CoSAI matrix

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.

Layers

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

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.
Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
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:

Originally published at Medium.

Anton’s Security Blog Quarterly Q2 2026

anton@chuvakin.org (Anton Chuvakin) — Tue, 30 Jun 2026 11:16:24 -0700

My Anton’s Security Blog Quarterly covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our…

My Anton’s Security Blog Quarterly 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):

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

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 2026 … we are in reviews 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” (Our classic 2021 ASO paper! Still epic, still relevant)

3 random fun posts, must-read:

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

Now, fun posts by topic.

Security operations / detection & response:

Cloud security:

How Google Does Security (HGD) — the new master site How Google Does It: An inside look at cybersecurity:

(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”
““Risk Tiering AI Use Case — A Practical Guide” (Google Cloud Community blog)
“Securing AI Supply Chain: Like Software, Only Not”
“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)

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) — should I do 25 years of SIEM in 2027?

Enjoy!

Previous posts in this series:

Originally published at Medium.

Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)

anton@chuvakin.org (Anton Chuvakin) — Mon, 29 Jun 2026 14:24:06 -0700

One particular aspect of an agentic or AI-powered SOC (but NOT “humanless SOC”) has bothered me over the last few months: specifically, the…

One particular aspect of an agentic or AI-powered SOC (but NOT “humanless SOC”) has bothered me over the last few months: specifically, the people and process side of such a SOC. If you recall my blog posts (part 1, part 2 and this video) about AI SOC readiness, I hinted at certain elements of a traditional process stack and legacy personnel profiles (both technical and leadership) that make AI adoption inside SOC incredibly difficult.

So we (me and Augusto Barros @ Prophet Security) want to create a modernized people and process framework for a SOC powered by AI and intelligent agents. Otherwise, what I am observing is a lot of “robotic horse pulls a buggy” kind of operations — where everything is kept exactly the same as it was in 2003, but “AI SOC” tools are simply tacked on to perform some of the tasks.

Gemini visual of old SOC with “AI SOC” tools

I believe that people and process components must change far more dramatically, and such changes are a critical requirement for achieving “step change” SOC with AI capabilities. Simply adding AI tools and Ai agents to a 2003-style SOC will produce, at best, marginal results. Things would get better, but not better enough to counter the feared “bad guy with AI.”

The SOAR Analogy

The analogy I want to use here is SOAR adoption from 10+ years ago. Back then, organizations simply shifted a few processes — or even just specific tasks — to a machine, and then kept the rest of their operations exactly the same. Because of that, I observed a lot of SOAR tools being used strictly for alert enrichment or for dealing with one specific, isolated type of alert, like phishing. To follow this analogy to the present day, I now frequently see an “AI SOC” being utilized only for EDR alerts or only for phishing alerts (wow, what a coincidence!)

A First-Principles Approach

What I really want to build is a first-principles approach to the specific personnel, skills, processes, and practices required to run a true agentic SOC in the late 2020s.

Now, if you prefer incremental change, that is OK, I won’t judge. However, you must be aware that the same principles caused organizations to struggle with cloud adoption. People often hear that “lift and shift” is bad. Most consultants will tell you that “lift and shift” is fine as a first step, but you eventually need to modernize and take more steps. Unfortunately, many organizations never make that second step. The same risk applies to the AI SOC. 2003 SOC + AI = somewhat better 2003 SOC.

BTW, many artifacts of the modern, engineering-powered SOC — which we covered in our now-famous ASO (Autonomic Security Operations) paper back in 2021s — apply here as well. In fact, if you recall, one of our core principles was: Humans build machines; machines do the work.

In the context of an agentic SOC, that evolves into:

Today, humans build the machines with the help of other machines, and then the machines do the heavy lifting.

So, our questions so far:

What do humans do in an agentic SOC?
What do entry-level humans do?
What SOC processes stay the same despite AI?
What SOC processes can just go and vanish (triage)?
What processes get handed to machines?
Are there new processes for humans?
What is the new human role for validation?
How do we check AI quality without fully redoing the work?
How SOC metrics must change due to AI and agents? (some ideas)
What do humans and machines do jointly? What does it mean, practically?
How to HITL in a SOC without breaking the humans or machines?
What is the effective mechanism for the human-to-AI feedback loop so that corrections actually improve future SOC performance?
Is “fully automated” detection engineering a realistic goal, or does the dependency on local, inconsistent environment context make it inherently a hybrid human-machine effort?
What do humans do before SOC (TI) and after SOC (IR)?
What is the first step to move from a legacy SOC to an agentic SOC?
Can we run legacy and agentic SOC structures in parallel during transition, or does this duplication create operational friction?
Is it easier to move from a modern non-AI SOC (aka “SOCless D&R”) to an AI SOC?

Looking Ahead

This blog post is just the first part of the series. My goal here is simply to collect the right questions we need to be asking, but I promise we will provide concrete answers in upcoming posts. This research is being undertaken together with my former colleague, Augusto Barros, now at Prophet Security

Related blogs:

Originally published at Medium.

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

anton@chuvakin.org (Anton Chuvakin) — Thu, 28 May 2026 16:36:22 -0700

So, you read my previous blog post about breaking the patch sound barrier, but it left you wanting more? Well, this is that “more.”

So, you read my previous blog post about breaking the patch sound barrier, but it left you wanting more? Well, this is that “more.”

Gemini blog illustration / steampunk vuln apoc

Here are three useful ideas to advance the conversation.

1. Defining the “Vulnerability Apocalypse”

People love to throw around terms like vulnerability apocalypse, but what does it actually mean? What is the crisp definition? Here:

Anton’s Vulnerability Apocalypse (VulnPocalypse) is …

… a rapid step increase in:

1. The number of software vulnerabilities (including zero-days i.e. vulnerabilities not known to defenders),

2. Speed of exploit development,

3. Volume of exploitation based on them,

4. Resulting incident damage.

With some help from the fine folks on Twitter and LinkedIn — and Gemini, naturally — the above is what I got.

Note that for a situation to truly qualify as “an apocalypse”, all four of these factors must be present simultaneously:

Massive Volume: A staggering influx of new vulnerabilities.
Rapid Exploit Development: Attackers weaponizing flaws nearly immediately.
Evident Exploitation: AI and automated tools scanning and exploiting at scale.
Severe Incident Damage: Widespread, material business impact resulting directly from these compromises.

The key? The fourth factor: incident damage. If you have a massive spike in vulnerabilities, but it doesn’t result in actual, widespread related damage, it isn’t an apocalypse — it’s just a high-volume vuln Tuesday.

How do we track that this is indeed coming? This is Part 3 of this saga, coming soon!

2. The Polarization of “Patch Faster”

Ever since advanced models capable of hunting down vulnerabilities emerged, the traditional advice of “just patch faster” has become incredibly polarizing.

Ultimately, my take aligns closely with a recent Cloudflare post: “Patching faster does not change the shape of the pipeline that produces the patch. If regression testing takes a day, you cannot get to a two-hour SLA without skipping it, and the bugs you ship when you skip regression testing tend to be worse than the bugs you were trying to patch.”

So, yes, do patch faster. And, no, patch faster won’t save you.

What will? This!

3. A Thought Experiment: The 15-Minute Magic Wand

Let me leave you with a useful thought experiment I recently used in a presentation.

Imagine you wake up tomorrow morning and, by pure force of magic, any vulnerability in your systems, applications, and operating systems can be patched within 15 minutes of patch release. The dream has come true!

Now for the fun part: Reverse engineer that reality.

What fundamental changes had to happen in your environment to make that 15-minute window physically possible?

If you actually run through this exercise, you will discover a goldmine of hidden opportunities. You’ll identify exactly where you can boost asset discovery, streamline software updates, automate testing, eliminate legacy roadblocks, and modernize your architecture. Fun!

Will it actually get your entire enterprise to a 15-minute patch cycle? No, probably not — and definitely not for every legacy application. But it will give you a concrete, actionable roadmap for modernizing your IT.

Let’s hope this was both fun and useful.

Related blog:

Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit Speed. So?

Originally published at Medium.

Very IMHO, AI Agents may mainstream the SDL, but they will not turn 100 data swamps and data…

anton@chuvakin.org (Anton Chuvakin) — Mon, 18 May 2026 09:38:25 -0700

Very IMHO, AI Agents may mainstream the SDL, but they will not turn 100 data swamps and data puddles into a coherent compliance-friendly security telemetry storage...

Originally published at Medium.

Very IMHO, AI Agents may mainstream the SDL, but they will not turn 100 data swamps and data…

anton@chuvakin.org (Anton Chuvakin) — Mon, 18 May 2026 09:38:18 -0700

Very IMHO, AI Agents may mainstream the SDL, but they will not turn 100 data swamps and data puddles into a coherent compliance-friendly security telemetry storage...

Originally published at Medium.

Exactly, things lime "Legacy or slow to patch services get moved to be hidden behind SaaS…

anton@chuvakin.org (Anton Chuvakin) — Tue, 5 May 2026 13:32:16 -0700

Exactly, things lime "Legacy or slow to patch services get moved to be hidden behind SaaS authentication" will sustain the system for awhile

Originally published at Medium.

Well, we will know in 6-9 months if this was necessary.

anton@chuvakin.org (Anton Chuvakin) — Tue, 5 May 2026 13:31:31 -0700

Well, we will know in 6-9 months if this was necessary. If the apocalypse won't come, then perhaps old ways lives on for a while longer. Again, your argument totally make sense

Originally published at Medium.

Thanks a lot for the comment.

anton@chuvakin.org (Anton Chuvakin) — Fri, 10 Apr 2026 16:59:53 -0700

Thanks a lot for the comment. For sure, there are legacy systems in use. But lets see a choice: a) fight the oracle DBA for 10 years so he patches 10% faster b) fight the CIO so he fires Oracle and DBA and uses (SAY) Cloud SQL? These two fights are very hard. But IMHO the first is harder/more painful

Originally published at Medium.

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

anton@chuvakin.org (Anton Chuvakin) — Fri, 10 Apr 2026 14:44:13 -0700

Many years ago while at Gartner, I wrote a blog post where I defined the concept of the “Patch Sound Barrier.” (original via Archive if you…

Many years ago while at Gartner, I wrote a blog post where I defined the concept of the “Patch Sound Barrier.” (original via Archive if you don’t believe that I was that smart back in 2013 :-)) This was an idea of a maximum speed that a given organization could fix a given vulnerability. If you full throttle beyond that, the engines will whirr louder, but the plane won’t fly faster, essentially.

Gemini illustration for this

The discussion arose from people constantly asking about the “optimal” or “desired” speed of patching. In my time as an analyst, I reviewed plenty of policies as well as “operational practices” (which is what people call it when they don’t actually follow their own policy “because reasons” :-)). BTW, I utterly hated “30 days flat” policies that say that vulnerabilities are fixed within 30 days no matter what, and always steered people to more nuanced risk-based policies.

One concept emerged: Given a particular IT environment, there is often a maximum physical speed at which an organization can patch. That is my Patch Sound Barrier.

Why bring this up now? Because the speed of vulnerability discovery is accelerating and so does exploit dev speed, but for many organizations, the speed of remediation simply cannot be accelerated. It is not accelerating, because it cannot. Full stop.

In the past, my guidance was to focus on better vulnerability prioritization so that you fix “real risks” using CISA KEV, EPSS, CVSS (OK, maybe not in the 2020s) and various tools that analyze the data and give you a ranked list.

But today we will have more vulns and prioritization tools won’t save you. If you have 1,000,000 vulns and 1000 are “risky for you” (however defined, let’s say you have the magical tool that reveals the true and real risk for your organization … ha), you can reduce the risk enough by fixing the 1000, if you have the bandwidth to fix the 1000 (in theory). Now, imagine you have 10m vulns (thanks AI!) and say 5000 are risky. But your bandwidth is there to only fix the 1000. So your risk goes up anyway, while you work as hard as before.

Now, you might say, “Anton, you’re making absolute statements. Surely things are flexible given enough money, enough talented engineers, and these days, enough LLM tokens?”

This is true in theory. But notice I said, “given the IT environment.”

There are definitely methods for accelerating remediation in a modern, beautifully and carefully designed environment (check our podcast episode 109 for those ideas).

But let’s review the scoreboard:

The speed of vulnerability discovery? Increased.
The speed of exploit development? Increased.
The speed of remediation in legacy environments? Unchanged.

OK, some of you might still think “cannot” is too harsh. But people at modern organizations — all DevOps, CI/CD, open source and now AI agents — sometimes cannot comprehend what it takes to deal with a 1990s-era “DBA from Hell” who views his beloved database as a pet, not cattle, and will only allow a patch twice a year on a rigid schedule. Don’t even get me started on OT or the sea of unpatched edge appliances out there (there are “forti” millions of them there, I hear …)

So, yes, I spent years providing recommendations on how to deal with this “vulnerability flood.” This isn’t just about the current fascination with AI; at one point, the “boogeyman” was Metasploit, or something else. Or, as old people told me, SATAN / SANTA in the mid-1990s.

The fact remains: there are more risky vulns than you have time / capability. Today. AI can find the bugs in milliseconds, but it still can’t convince a legacy middleware admin to reboot a production server on a Tuesday. Or in July. Or in 2026. Or this freakin’ century …

So far it sounds like a rehash of my past ideas, but I actually want to leverage some thoughts from Phil Venables’ blog series about speed (“Things Are Getting Wild: Re-Tool Everything for Speed” and “Cybersecurity’s Need for Speed & Where To Find It”)

Before we go there, we must remember about reducing risk without remediating vulnerabilities. This was often the most insightful bit I shared with clients back in my analyst days: Sometimes your focus must be on reducing your risk, rather than fixing the bug. Kinda “assume the breach”, but for vulns: “assume you can’t patch” then what?

So, how do you get speed to break through the sound barrier (alert: these do NOT apply to everybody):

Brutally destroy legacy systems; if it cannot be patched quickly and safely, don’t use it. Think “SaaS and Chromebooks” (and cloud) world. Don’t think 1980s ERP crap.
Modernize. Kill pets. Grow cattle. Ideally, get replaceable tiny insects as cattle. They are simpler, more replaceable and less cute. Think “pets -> cattle -> insects.” [P.S. I do not recall where I got this idea, if I stole this from you, I am sorry — happy to restore credit if you tell me]
Evolve IT culture to accept automatic patching, everywhere. If Chrome can autopatch 1b systems safely for 10 years, perhaps there is a way to do it, eh?
Eliminate the risk entirely (e.g., via micro-segmentation or data avoidance) when patching is impossible. If you cannot remove the vuln, remove the connection, the system or the entire business process.
Shift focus from patching to overall IT lifecycle velocity by decoupling the application from infrastructure. In faster IT, patching is faster. Fight friction, just like you fight toil.

These are some ideas on how to shift from “floor the gas” to “build a supersonic plane” to break the patch sound barrier! Are you still debating patch cycles, or are you architecting your way out of the need for them? Please share more!

Enjoy … living in interesting times!

Originally published at Medium.

RSA 2026: Agentic Future, Analog Fundamentals — The Paradox of Why the Old Guard Still Survives

anton@chuvakin.org (Anton Chuvakin) — Wed, 1 Apr 2026 14:42:54 -0700

OK, RSA 2026 is over. If my record keeping is correct, I first attended RSA in 2006. At that time, I was annoyed by … AI? XDR? NIDS? ……

OK, RSA 2026 is over. If my record keeping is correct, I first attended RSA in 2006. At that time, I was annoyed by … AI? XDR? NIDS? …. noooo… I was annoyed by NAC (“As many other RSA observers agreed, under each tree you now see a NAC.” NAC rapidly arose from the “wormy” early 2000s and quickly vanished inside network infrastructure devices).

That t-shirt

Anyhow…

If the RSA Conference is the annual, sprawling theme park of the cybersecurity industry, then RSA 2026 was the year the park owners unveiled the shiny, terrifying, and utterly bewildering “AI Rollercoaster.” But as my co-host Tim Peacock and I sniffed around the expo floor, a familiar suspicion crept in: half the queue signs were blatant fabrications, and the ride itself might only be half-built.

For decades, we’ve attended this annual security pilgrimage expecting consolidation, disruption, and an industry growing up. And every year, we leave with the same truth: the more things change, the more they stay the same (and no, I am not old enough to be called “a curmudgeon”). This year, the force of AI agents was everywhere, yet the industry’s response — the good, the bad, and the baffling - revealed more about our collective inability to do the fundamentals than it did about the technology itself.

The first thing you notice about the AI Rollercoaster is the marketing. It’s less about engineering excellence and more about colorful claims that would make a 1890s snake oil salesman blush. Our first, unavoidable observation was the sheer breadth of the AI Hype Spectrum, a problem of which AI washing is one of the levels.

We saw vendors across the spectrum: from those quietly using AI for genuine, impactful security tasks to those who merely “spray painted an AI” onto their 2021 marketing materials and called it a new platform. This latter group — the “AI touch-up” artists — are everywhere, simply adding a comma and the word “agents” to their identity management tools description, firewalls, anti-virus and calling it a day (I have booth pictures, yes)

Look, you are not an AI native company if you launched in 2003 and have a “talk to docs / manuals” chatbot in 2026. BTW, your chatbot can be easily convinced to spout political propaganda because your RAG sucks and you think “restrict via system prompt” is AI security…

This brings me to the first core truth of RSA 2026: to succeed, the buyer must be the expert. It is profoundly disappointing — though not surprising — that in an industry claiming to be on the cusp of a technological revolution (AI AI AI!), our most potent advice for a CISO is a throwback to the days of dial-up: due diligence. BTW, see this quote: “The problem is that most of the people attending the RSA Conference can’t understand what the products do or why they should buy them.” This is…. OH HORROR! .. Bruce Schneier in 2008.

The genuine use of AI in a product is now almost entirely disconnected from the glossy message on the vendor’s booth. You, the buyer, need to dig deep, get technical, and understand what they are actually selling. If they claim AI makes their firewall (or: your SOC) better, tell them to show you the numbers (Better how? Better where? By how much? Depending on what?). If they can’t produce data and solid metrics on how AI improved their thing, you must assume they are not credible and are essentially lying. Sorry, but “cloud native firewall” is not a thing.

And speaking of gloss, a related phenomenon was what we called the “Wiz Effect.” We saw a notable rise in whimsical, information-free booths — lots of pinks, purples, superheroes, and non-security-related sports figures. While a tasteful aesthetic is welcome, this strategy only works if you are already a $32 billion company named Wiz. It did work- and it still does work — for Wiz! Wiz can have soup cans in the booth, and it will sell CNAPP by the million. For others, a fantastical booth merely meant your booth was remembered, but your message was utterly lost. Goats! Also, its low-information density approach compounds the problem of AI washing.

In the past, some clowns predicted that our industry will consolidate and only a dozen large vendors will remain. In 2026, many fear a different Vendor Apocalypse where the large AI labs will simply run over existing security vendors. If a massive LLM can run on an endpoint and perform vulnerability analysis, why do you need a standalone vulnerability scanner? To me, this risk is absolutely real, particularly for product categories like Static Analysis (SAST), which seems custom-made for LLM decimation (reminder: I am not an appsec expert). The same logic applies to firewall rule analysis, policy writing, and many simple IAM/PAM decisions. However, it is not yet clear (my gut says “no”, my brain says “wait for RSA 2027, then ask again”) that the entire industry is vulnerable though…

And this is where the industry’s legendary IT inertia kicks in. The persistence of “The Old” is a stunning, annual lesson in the industry’s resistance to disruption. We saw large booths from vendors whose heyday was decades ago — the fifth best firewall and antivirus vendors are still alive and well as if the calendar still shows 2006. Do you believe that Checkpoint sells “AI security”? They do now! Anyhow, they are still collecting hard-earned money from buyers. This proves that the promised AI disruption has not yet killed off even the “number six” player in a market., much less hurt the #1. “Last vendor on the list is … still ON the list” was my insight here.

Why such epic survival skills? I think it comes down to enterprise knowledge and IT inertia. We debated whether the security industry would survive based on the same concept that keeps human analysts relevant against a giant LLM: the possession of “tribal knowledge.” This is the accumulated, aggregated, and integrated gossip … eh … customer data…that good security vendors hold about their clients’ specific environments. This tacit knowledge, the context of why things are done, is not public, and an AI robot won’t have it today (theoretically, there are ways for them to gather it, to be sure). If your security operation relies on this copious chunk of tribal knowledge, a super-intelligent chatbot won’t replace your vendor — at least not yet.

Another odd observation here. For some vendors, promoting “openness” seems like a signaling maneuver for weakness, not strength. We walked past booths proclaiming “open data lake,” “open detection,” and “open ecosystem.” While I believe openness has inherently positive value, my cynical analyst brain immediately wondered: are they more open or are they just not better? See, vendor A sells EDR, and it is really good. Vendor B EDR sucks compared to vendor A. So they market it as “open EDR” because they cannot market it as “the better EDR” (it ain’t better, even according to them). Reactions?

While the hype around AI for security was overwhelming, there was a positive and genuinely exciting shift: the rise of securing AI and agents. Last year, I lamented the lack of focus on protecting AI systems. This year, I was pleasantly surprised to see vendors focusing on securing agents, securing agent identity, and doing data security for the AI supply chain and training data.

The third pilar of this is the bad guy with AI. To me, the real fear isn’t the “Bad Guy with AI” or even the coming “Bad AI”; the fear is the acceleration of the inevitable. If your security posture is bad before AI, it’s just going to be bad — and faster — after AI. As attackers modernize their business with AI, the average time to compromise will drop even further and — IMHO more importatny — a chance of a compromise will go up (ref this week suppy chain hits)

The ultimate takeaway here is the “boring” lesson: Get the fundamentals right (and, yes, AI can help here too). No amount of AI from a threat actor will exploit your cloud misconfiguration if you don’t have one (well, either cloud or misconfiguration). If your defenses against misconfigured systems, containers, and instances are robust, it doesn’t matter that the bad guy has AI; your stuff is more secure. The acceleration brought by AI will simply kill off “luck-based security.” The old adage is true: if your app has no obvious exploitable holes, there’s nothing for the AI-armed attacker to find. Magic!

So my single piece of advice for dealing with this reality, whether you are a buyer, a seller, or an analyst, is simple: demand the data. Do not let vendors get away with buzzword bingo. If a vendor says AI helps, make them prove it with solid metrics. The time for “trust-me-bro” security better be over!

Finally, some reactions from my 3 sessions. The most shocking reactions came from my “AI SOC” peer discussion on Thursday. I noticed a shocking, near-total lack of enthusiasm about AI SOC startups (total) and AI SOC concepts (near total). The best I got was “AI in a SOC sounds great, we will just wait for our SIEM/SOAR vendor or MDR to build it” and “this is better SOAR and we want this, but later.” And think about it: this was for people biased in favor of AI SOC (because they showed up for the session)… Not sure yet what to think of it!

Fun takes from other people(and there are many) are here (key quote: “Perhaps I’m being overly dramatic but I was surprised with the generally relaxed tone about the impending wave of vulnerabilities and the extent of industrialized attackers coming in the coming quarters. Everyone seems to know vulnerability management isn’t where it needs to be in most companies and what’s coming will pile on the pressure.”), here, here.

Related blogs:

Originally published at Medium.

Anton’s Security Blog Quarterly Q1 2026

anton@chuvakin.org (Anton Chuvakin) — Thu, 19 Mar 2026 11:45:02 -0700

My Anton’s Security Blog (And Podcast!) Quarterly this covers both Anton on Security and my posts from Google Cloud blog, Google Cloud…

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).

Gemini image for this

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

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

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 2026 … we are in reviews 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!)

3 random fun posts, must-read:

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

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

Now, fun posts by topic.

Security operations / detection & response:

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

Cloud security:

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

How Google Does Security (HGD):

(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 ):

Enjoy!

Previous posts in this series:

Originally published at Medium.

Anton’s Vibe Coding Experience: A Reflection on Risk Decisions

anton@chuvakin.org (Anton Chuvakin) — Tue, 17 Mar 2026 13:38:50 -0700

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…

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.

Anton’s vibe app screenshot

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

Anton vibe app UX

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!

Originally published at Medium.