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

1. 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.
2. 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. No compliance mandate requires a central, immutable copy of this data — or you have already built and evidenced the equivalent controls at the source.
6. 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.
7. 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)

Related posts

• Log Centralization: The End Is Nigh? (2023)
• Decoupled SIEM: Where I Think We Are Now? (2025)
• Why Your Security Data Lake Project Will … Well, Actually …
• Output-driven SIEM — 13 Years Later
• Stop Building a 2003 SOC with AI: Triage Must Die (Part 2)
• FinOps for SecOps: How to optimize the agentic SOC for value

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

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: A Modern People & Process Framework (Part 1)
• Stop Building a 2003 SOC with AI: Triage Must Die (Part 2)
• Simple to Ask: Is Your SOC AI Ready? Not Simple to Answer!
• Beyond “Is Your SOC AI Ready?” Plan the Journey!
• So Is Your SOC AI-Ready? Part 3: API or Die Audit!
• WTH is Modern SOC, Part 1
• The Ancient Art of SIEM: Why 2003 Problems Look So Familiar in 2026
• The Return of the Baby ASO: Why SOCs Still Suck?
• Beware: Clown-grade SOCs Still Abound
• EP264 Measuring Your (Agentic) SOC: Two Security Leaders Walk into a Podcast

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

GRC

EDR

EPP

SIEM

Firewall

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:

• RSA 2026: Agentic Future, Analog Fundamentals — The Paradox of Why the Old Guard Still Survives
• The Ancient Art of SIEM: Why 2003 Problems Look So Familiar in 2026

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.

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:

• Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)
• Stop Building a 2003 SOC with AI: Triage Must Die (Part 2)
• Coming soon…

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:

1. Machine-ready: API is fast, documented, structured, and scoped. Your agents can use it.
2. 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:

• “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)
• “A Brief Guide for Dealing with ‘Humanless SOC’ Idiots”
• EP249 Data First: What Really Makes Your SOC ‘AI Ready’?
• EP252 The Agentic SOC Reality: Governing AI Agents, Data Fidelity, and Measuring Success

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.