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

28 August 2026 at 00:48

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

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)

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

Anton on Security

By: Anton Chuvakin

26 August 2026 at 18:53

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:

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.

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

Anton on Security

By: Anton Chuvakin

21 August 2026 at 00:26

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.

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

Anton on Security

By: Anton Chuvakin

19 August 2026 at 19:13

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

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.

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

Anton on Security

By: Anton Chuvakin

14 August 2026 at 01:09

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

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

#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!

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

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

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

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

Anton on Security

By: Anton Chuvakin

11 August 2026 at 20:58

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

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.

Beyond the Vulnerability Apocalypse: Scaling Your Basics and Vulnerability Management

Anton on Security

By: Anton Chuvakin

23 July 2026 at 21:40

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.

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

Anton on Security

By: Anton Chuvakin

16 July 2026 at 01:12

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.

From Cloud to Chaos: Defining Shared Responsibility for AI Security

Anton on Security

By: Anton Chuvakin

2 July 2026 at 19:26

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.

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

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

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

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

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:

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

Anton’s Security Blog Quarterly Q2 2026

Anton on Security

By: Anton Chuvakin

30 June 2026 at 20:16

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:

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

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

Anton on Security

By: Anton Chuvakin

29 June 2026 at 23:24

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:

Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

Anton on Security

By: Anton Chuvakin

29 May 2026 at 01:36

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?

Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

Anton on Security

By: Anton Chuvakin

10 April 2026 at 23:44

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

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.

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!

Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit… was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

Anton on Security

By: Anton Chuvakin

1 April 2026 at 23:42

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

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:

RSA 2026: Agentic Future, Analog Fundamentals — The Paradox of Why the Old Guard Still Survives was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Anton’s Security Blog Quarterly Q1 2026

Anton on Security

By: Anton Chuvakin

19 March 2026 at 19:45

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

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

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:

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

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

Anton on Security

By: Anton Chuvakin

17 March 2026 at 21:38

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On X: example example example
On LinkedIn: example example

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

1. You Make Implied Security Decisions with Every Prompt

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

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

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

3. AI Mistakes Require a New Response Model

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

4. Corporate Guardrails vs. AI Ambition

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

5. Public Data is the Only “Safe” Vibe

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

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

Enjoy the show! Now with video!

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

Google Cloud Security Threat Horizons Report #13 (H1 2026) Is Out!

Anton on Security

By: Anton Chuvakin

10 March 2026 at 21:02

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

My favorite quotes from the report follow below:

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

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

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

Now, go and read the CTHR 13 report!

My Really Fun RSA 2026 Presentations!

Anton on Security

By: Anton Chuvakin

9 March 2026 at 23:28

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

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

Here are these 3 fun things!

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

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

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

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

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

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

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

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

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

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

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

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

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

See you there!

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

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

Beyond “Is Your SOC AI Ready?” Plan the Journey!

Anton on Security

By: Anton Chuvakin

9 January 2026 at 20:36

You read the “AI-ready SOC pillars” blog, but you still see a lot of this:

How do we do better?

Let’s go through all 5 pillars aka readiness dimensions and see what we can actually do to make your SOC AI-ready.

#1 SOC Data Foundations

As I said before, this one is my absolute favorite and is at the center of most “AI in SOC” (as you recall, I want AI in my SOC, but I dislike the “AI SOC” concept) successes (if done well) and failures (if not done at all).

Reminder: pillar #1 is “security context and data are available and can be queried by machines (API, Model Context Protocol (MCP), etc) in a scalable and reliable manner.” Put simply, for the AI to work for you, it needs your data. As our friends say here, “Context engineering focuses on what information the AI has available. […] For security operations, this distinction is critical. Get the context wrong, and even the most sophisticated model will arrive at inaccurate conclusions.”

Readiness check: Security context and data are available and can be queried by machines in a scalable and reliable manner. This is very easy to check, yet not easy to achieve for many types of data.

For example, “give AI access to past incidents” is very easy in theory (“ah, just give it old tickets”) yet often very hard in reality (“what tickets?” “aren’t some too sensitive?”, “wait…this ticket didn’t record what happened afterwards and it totally changed the outcome”, “well, these tickets are in another system”, etc, etc)

Steps to get ready:

Conduct an “API or Die” data access audit to inventory critical data sources (telemetry and context) and stress-test their APIs (or other access methods) under load to ensure they can handle frequent queries from an AI agent. This is important enough to be a Part 3 blog after this one…
Establish or refine unified, intentional data pipelines for the data you need. This may be your SIEM, this may be a separate security pipeline tool, this may be magick for all I care … but it needs to exist. I met people who use AI to parse human analyst screen videos to understand how humans access legacy data sources, and this is very cool, but perhaps not what you want in prod.
Revamp case management to force structured data entry (e.g., categorized root causes, tagged MITRE ATT&CK techniques) instead of relying on garbled unstructured text descriptions, which provides clean training data for future AI learning. And, yes, if you have to ask: modern gen AI can understand your garbled stream of consciousness ticket description…. but what it makes of it, you will never know…

Where you arrive: your AI component, AI-powered tool or AI agent can get the data it needs nearly every time. The cases where it cannot become visible, and obvious immediately.

#2 SOC Process Framework and Maturity

Reminder: pillar #2 is “Common SOC workflows do NOT rely on human-to-human communication are essential for AI success.” As somebody called it, you need “machine-intelligible processes.”

Readiness check: SOC workflows are defined as machine-intelligible processes that can be queried programmatically, and explicit, structured handoff criteria are established for all Human-in-the-Loop (HITL) processes, clearly delineating what is handled by the agent versus the person. Examples for handoff to human may include high decision uncertainty, lack of context to make a call (see pillar #1), extra-sensitive systems, etc.

Common investigation and response workflows do not rely on ad-hoc, human-to-human communication or “tribal knowledge,” such knowledge is discovered and brought to surface.

Steps to get ready:

Codify the “Tribal Knowledge” into APIs: Stop burying your detection logic in dusty PDFs or inside the heads of your senior analysts. You must document workflows in a structured, machine-readable format that an AI can actually query. If your context — like CMDB or asset inventory — isn’t accessible via API (BTW MCP is not magic!), your AI is essentially flying blind.
Draw a Hard Line Between Agent and Human: Don’t let the AI “guess” its level of authority. Explicitly delegate the high-volume drudgery (log summarization, initial enrichment, IP correlation) to the agent, while keeping high-stakes “kill switches” (like shutting down production servers) firmly in human hands.
Implement a “Grading” System for Continuous Learning: AI shouldn’t just execute tasks; it needs to go to school. Establish a feedback loop where humans actively “grade” the AI’s triage logic based on historical resolution data. This transforms the system from a static script into a living “recipe” that refines itself over time.
Target Processes for AI-Driven Automation: Stop trying to “AI all the things.” Identify specific investigation workflows that are candidates for automation and use your historical alert triage data as a training ground to ensure the agent actually learns what “good” looks like.

Where you arrive: The “tribal knowledge” that previously drove your SOC is recorded for machine-readable workflows. Explicit, structured handoff points are established for all Human-in-the-Loop processes, and the system uses human grading to continuously refine its logic and improve its ‘recipe’ over time. This does not mean that everything is rigid; “Visio diagram or death” SOC should stay in the 1990s. Recorded and explicit beats rigid and unchanging.

#3 SOC Human Element and Skills

Reminder: pillar #3 is “Cultivating a culture of augmentation, redefining analyst roles, providing training for human-AI collaboration, and embracing a leadership mindset that accepts probabilistic outcomes.” You say “fluffy management crap”? Well, I say “ignore this and your SOC is dead.”

Readiness check: Leaders have secured formal CISO sign-off on a quantified “AI Error Budget,” defining an acceptable, measured, probabilistic error rate for autonomously closed alerts (that is definitely not zero, BTW). The team is evolving to actively review, grade, and edit AI-generated logic and detection output.

Steps to get ready:

Implement the “AI Error Budget”: Stop pretending AI will be 100% accurate. You must secure formal CISO sign-off on a quantified “AI Error Budget” — a predefined threshold for acceptable mistakes. If an agent automates 1,000 hours of labor but has a 5% error rate, the leadership needs to acknowledge that trade-off upfront. It’s better to define “allowable failure” now than to explain a hallucination during an incident post-mortem.
Pivot from “Robot Work” to Agent Shepherding: The traditional L1/L2 analyst role is effectively dead; long live the “Agent Supervisor.” Instead of manually sifting through logs — work that is essentially “robot work” anyway — your team must be trained to review, grade, and edit AI-generated logic. They are no longer just consumers of alerts; they are the “Editors-in-Chief” of the SOC’s intelligence.
Rebuild the SOC Org Chart and RACI: Adding AI isn’t a “plug and play” software update; it’s an organizational redesign. You need to redefine roles: Detection Engineers become AI Logic Editors, and analysts become Supervisors. Most importantly, your RACI must clearly answer the uncomfortable question: If the AI misses a breach, is the accountability with the person who trained the model or the person who supervised the output?

Where you arrive: well, you arrive at a practical realization that you have “AI in SOC” (and not AI SOC). The tools augment people (and in some cases, do the work end to end too). No pro- (“AI SOC means all humans can go home”) or contra-AI (“it makes mistakes and this means we cannot use it”) crazies nearby.

#4 Modern SOC Technology Stack

Reminder: pillar #4 is “Modern SOC Technology Stack.” If your tools lack APIs, take them and go back to the 1990s from whence you came! Destroy your time machine when you arrive, don’t come back to 2026!

Readiness check: The security stack is modern, fast (“no multi-hour data queries”) interoperable and supports new AI capabilities to integrate seamlessly, tools can communicate without a human acting as a manual bridge and can handle agentic AI request volumes.

Steps to get ready:

Mandate “Detection-as-Code” (DaC): This is no longer optional. To make your stack machine-readable, you must implement version control (Git), CI/CD pipelines, and automated testing for all detections. If your detection logic isn’t codified, your AI agent has nothing to interact with except a brittle GUI — and that is a recipe for failure.
Find Your “Interoperability Ceiling” via Stress Testing: Before you go live, simulate reality. Have an agent attempt to enrich 50 alerts simultaneously to see where the pipes burst. Does your SOAR tool hit a rate limit? Does your threat intel provider cut you off? You need to find the breaking point of your tech stack’s interoperability before an actual incident does it for you.
Decouple “Native” from “Custom” Agents: Don’t reinvent the wheel, but don’t expect a vendor’s “native” agent to understand your weird, proprietary legacy systems. Define a clear strategy: use native agents for standard tool-specific tasks, and reserve your engineering resources for custom agents designed to navigate your unique compliance requirements and internal “secret sauce.”

Where you arrive: this sounds like a perfect quote from Captain Obvious but you arrive at the SOC powered by tools that work with automation, and not with “human bridge” or “swivel chair.”

#5 SOC Metrics and Feedback Loop

Reminder: pillar #5 is “You are ready for AI if you can, after adding AI, answer the “what got better?” question. You need metrics and a feedback loop to get better.”

Readiness check: Hard baseline metrics (MTTR, MTTD, false positive rates) are established before AI deployment, and the team has a way to quantify the value and improvements resulting from AI. When things get better, you will know it.

Steps to get ready:

Establish the “Before” Baseline and Fix the Data Slop: You cannot claim victory if you don’t know where the goalposts were to begin with. Measure your current MTTR and MTTD rigorously before the first agent is deployed. Simultaneously, force your analysts to stop treating case notes like a private diary. Standardize on structured data entry — categorized root causes and MITRE tags — so the machine has “clean fuel” to learn from rather than a collection of “fixed it” or “closed” comments.
Build an “AI Gym” Using Your “Golden Set”: Do not throw your agents into the deep end of live production traffic on day one. Curate a “Golden Set” of your 50–100 most exemplary past incidents — the ones with flawless notes, clean data, and correct conclusions. This serves as your benchmark; if the AI can’t solve these “solved” problems correctly, it has no business touching your live environment.
Adopt Agent-Specific KPIs for Performance Management: Traditional SOC metrics like “number of alerts closed” are insufficient for an AI-augmented team. You need to track Agent Accuracy Rate, Agent Time Savings, and Agent Uptime as religiously as you track patch latency. If your agent is hallucinating 5% of its summaries, that needs to be a visible red flag on your dashboard, not a surprise you discover during an incident post-mortem.
Close the Loop with Continuous Tuning: Ensure triage results aren’t just filed away to die in an archive. Establish a feedback loop where the results of both human and AI investigations are automatically routed back to tune the underlying detection rules. This transforms your SOC from a static “filter” into a learning system that evolves with every alert.

Where you arrive: you have a fact-based visual that shows your SOC becoming better in ways important to your mission after you add AI (in fact, you SOC will get better even before AI but after you do the prep-work from this document)

As a result, we can hopefully get to this instead:

The path to an AI-ready SOC isn’t paved with new tools; it’s paved with better data, cleaner processes, and a fundamental shift in how we think about human-machine collaboration. If you ignore these pillars, your AI journey will be a series of expensive lessons in why “magic” isn’t a strategy.

But if you get these right? You move from a SOC that is constantly drowning in alerts to a SOC that operates truly 10X effectiveness.

Random cool visual because Nano Banana :)

P.S. Anton, you said “10X”, so how does this relate to ASO and “engineering-led” D&R? I am glad you asked. The five pillars we outlined are not just steps for AI; they are the also steps on the road to ASO (see original 2021 paper which is still “the future” for many).

ASO is the vision for a 10X transformation of the SOC, driven by an adaptive, agile, and highly automated approach to threats. The focus on codified, machine-intelligible workflows, a modern stack supporting Detection-as-Code, and reskilling analysts as “Agent Supervisors” directly supports the core of engineering-led D&R. So focusing on these five readiness dimensions, you move from a traditional operations room (lots of “O” for operations) to a scalable, engineering-centric D&R function (where “E” for engineering dominates).

So, which pillar is your SOC’s current ‘weakest link’? Let’s discuss in the comments and on socials!

Related blogs and podcasts:

Beyond “Is Your SOC AI Ready?” Plan the Journey! was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Anton’s Security Blog Quarterly Q4 2025

Anton on Security

By: Anton Chuvakin

29 December 2025 at 23:16

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

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

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”?
Revisiting the Visibility Triad for 2020 (update for 2025 is here!)
Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
Beware: Clown-grade SOCs Still Abound
Why is Threat Detection Hard?
A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
Anton and The Great XDR Debate, Part 1
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 researching now!)
New Paper: “Future of the SOC: Forces shaping modern security operations”
New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (the classic 2021 ASO paper!)
New Paper: “Future of SOC: Transform the ‘How’” (Paper 5)
New Paper: “Securing AI: Similar or Different?“
New Office of the CISO Paper: Organizing Security for Digital Transformation” (paper)
10 ways to make cyber-physical systems more resilient” (paper)

NEW: recent 3 fun posts, must-read:

Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer! (is your SOC AI-ready?)
Shadow Agents: A New Era of Shadow AI Risk in the Enterprise (see you at RSA 2026!)
Decoupled SIEM: Where I Think We Are Now? (this is not over yet!)

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

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

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

AI security:

”Our Security of AI Papers and Blogs Explained” (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”
“No Deep AI Security Secrets In This Post!”
“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:

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

Reading view

Prologue: Three Years After “The End Is Nigh”

The Breaking Point of the Centralized Vault

The Federated Temptation

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

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

2. You trade cost for resilience

3. No assurance the logs are even there

4. Compliance did not get the memo

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

6. Operational toil, and nobody to scream at

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

The Architectural Spectrum: Is There a Middle Path?

When Can Federated Actually Work? The Criteria

The Pragmatic Hybrid: Mapping Telemetry to Tiers

Strategic Takeaways for Security Leaders

The Verdict

Related posts

2003 SOC + AI = somewhat better 2003 SOC.

The Hard Problem Nobody Markets: Local Context

When the Machine Is Wrong: Failure Modes and Accountability

The Decision Layer Is Now an Attack Surface

The Transition: Four Phases, No Magic

The Feynman Betting Strategy and the Inertia of Security

The Power of IT Inertia

AI, “Vibe Coding,” and the DIY Trap

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

“What If This Time It’s Different?”

Why This Audit, Why Now?

Phase 0: The “Cold Eyes” Inventory

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

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

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

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

Test 5: The Auth & Agent Identity Layer

The “Agentic Readiness” Scorecard

Where You Arrive: The Binary Map

Let’s Kill Triage. Seriously.

Detect → Triage → Investigate

Detect → Investigate.

Wait — Can They Actually Do That Today?

Depth Gating: The New Triage Wears a Suit

So What Do the Humans Do?

And the New L1 Is…

What’s Next?

Why the urgency is real (and different this time)

Start by reverse-engineering the impossible

The Playbook: Fundamentals at AI Scale and Speed

The real reckoning

Universal Security Controls for Both Futures

1. Configuration Hygiene

2. Threat Detection & Security Monitoring

3. Accelerated Vulnerability Management

4. Data Security & Sensitive Data Discovery

5. Shadow AI Governance & Sanctioned Alternatives

6. Identity & Access for Agents

7. Environmental Reality Testing vs. Marketing Benchmarks

Moving Beyond the Debate

Summary

The SOAR Analogy

A First-Principles Approach

Looking Ahead

1. Defining the “Vulnerability Apocalypse”

2. The Polarization of “Patch Faster”

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

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