Every few months someone declares the SIEM dead, and an AI layer that queries all your systems in place – no central log lake – is the latest murder weapon. The pitch is good. Stop paying to ship petabytes you never read. Let an agent connect to CloudTrail, Okta, and your sensors directly, and run detection at the edge, in place, in each system's native form.
The pitch is also half right, which is worse than wrong.
The SIEM isn't dying. The single thing we built it to do is splitting into two jobs that don't belong in the same box anymore – and the half of the pitch that's correct is hiding the half that decides whether any of this works.
The assumption nobody examines
We don't centralize logs because centralizing is good. We centralize because a query engine needs its data in one schema, in one place, to run. That's it. Detection was a query, and a query needed unified data, so we built an enormous machine whose entire purpose is to drag everything into one searchable pile.
That's an artifact of a constraint, not a law of nature. The constraint was real for twenty years. It's worth asking what's left standing when it loosens – when you can put an agent at each source that speaks the source's own API and correlates across them on demand, instead of pre-joining everything into one index first.
Some of the SIEM's reasons for existing survive that question. Some don't. The whole argument is about which is which.
The case for querying in place
Steelman it properly, because the economics are genuinely compelling.
SIEM licensing is volume-based, and most of what you ingest is never queried. You are paying to move and store an entire haystack in order to look at three needles. Query-in-place bills you only for what you actually touch.
The schema tax goes away too. Central SIEMs normalize everything into their own worldview on the way in, and they lose fidelity doing it. I've written two separate posts about Splunk quietly mangling field structure – braces from JSON arrays, multivalue fields collapsing – before a human ever sees the data. The store distorts the event as a condition of accepting it. Query the source natively and the event stays intact.
Then there's dark data. Full packet capture, the DNS firehose, verbose cloud audit – sources too large to centralize economically. They become huntable on demand instead of being dropped at the collector. This is where the idea is strongest for anyone who lives at the network layer: NSM and Zeek data is enormous, almost nobody ingests it whole, and an edge query layer is how you'd finally hunt over all of it.
Detection also moves closer to the source – no forwarder, index, and scheduled-search lag stacked in front of it. And the agent hunts the way a human actually does, pivoting an identity from Okta to AWS to Google Workspace in its native trail, instead of being boxed into whatever someone thought to pre-join into an index six months ago.
All of that is real. None of it kills the SIEM.
Why the "SIEM dies" version is wrong
Centralization solves problems that querying in place doesn't touch.
Retention and forensics. Source systems rotate and expire their own logs – CloudTrail defaults to about 90 days, Okta caps its retention, sensors overwrite. Incident response and compliance need immutable, timestamped evidence that lives for months or years. You still need a store. An edge query layer has nothing to say about where the data lives in six months.
Correlation at scale. The deterministic join – the same entity across five sources over a 90-day window – is exactly what a unified store does well and what N live API calls stuffed into a context window do badly. The thing the agent demo makes look easy on three events gets slow, bounded, and lossy at real volume.
Auditability. "Why did this fire" has to be answerable for the analyst at 2am and the regulator six months later. A query is something you can read. An agent's reasoning chain is not, not in a way that survives an audit.
These reasons don't evaporate because a demo was slick. They're load-bearing, and the edge-query pitch is quiet about all three.
The part that actually decides it
Here's the one that matters most, and it's personal to anyone who tests their detections.
A scheduled query returns the same answer every time it runs. You can backtest it against thirty days of history. You can prove it fires on a malicious sample and stays quiet on a benign one. You can version it, diff it, and put it through CI. An LLM inventing detection logic on the fly does none of that reliably.
I've argued before that an untested detection isn't a detection – it's a query that runs on a schedule and a hope. That argument assumes a reproducible artifact: a thing you can point a test at and get the same result twice. An agentic detection layer doesn't produce one. There's no Sigma rule, no CI gate, no backtest, no way to prove it can fire before you trust it to tell you the bad thing didn't happen.
You can't unit-test a vibe.
That's the line between the two jobs. Hunting tolerates non-determinism – a good hunter is supposed to follow a hunch and surprise you. Detection cannot tolerate it, because the entire value of a detection is that it does the same correct thing every time, including the times nobody's watching. Until agentic detection hands you a testable, repeatable artifact, it's a hunting accelerant, not a detection program. Those are different jobs, and conflating them is how you end up trusting silence you never validated.
The blast radius nobody prices in
One more. To query everything in place, the AI layer needs broad read credentials to every source system you own. That's a single identity with read access to your entire estate.
Compromise it and the attacker inherits your whole field of view at once. It's the same shape as the exclusion-list problem I've written about – the lookup that gives your detections coverage also becomes part of your blast radius if it's compromised – except now the blast radius is everything, in one credential. Add the rate limits and analytic-hostile APIs on the source systems, and "query everything live during an incident" starts throttling at exactly the moment you need it most.
What actually changes
So put the hype down and say what's really happening. The SIEM's two jobs come apart.
Hunting and detection federate out to an AI edge layer that queries sources in their own language. And retention, forensics, compliance, and the heavy deterministic correlation stay centralized – except, freed from the pressure to also be your live query surface, the central store can get cheaper and dumber. Object storage you query occasionally, not a search license you feed continuously.
The reason you centralize shifts from querying to remembering. That's the actual headline. It's less exciting than "the SIEM is dead," which is precisely why nobody trying to sell you the agent is saying it.
The actual lesson
The SIEM doesn't die. It stops being the place you hunt and becomes the place you remember – and those were always two jobs wearing one license.
Detection moves to the edge the moment an agent can query a source in its own language. But it stays a hunting tool, not a detection program, until the day it can hand you an artifact you can test. Watch for that day. It decides more than any pricing slide, and it's the one thing nobody demoing this wants to talk about.
Top comments (0)