Every few years, security operations gets a new word for the same problem. The problem never changes: a defender has to watch a large, constantly shifting environment, pull meaningful signal out of a flood of low-value noise, connect weak indicators across time and infrastructure, decide what actually matters, and respond before the damage is done. That was true in 1998. It's true now. What changes is the volume of telemetry, the tooling available to manage it, and — this cycle — the vocabulary vendors use to sell it to you.
Right now the word is "agentic." Autonomous SOC. Self-directed security operations. The pitch is that the platform doesn't just detect anymore — it decides. It reasons. It acts on its own judgment, the way a senior analyst would, except tirelessly and at machine speed.
I want to take that claim seriously enough to actually check it. Not dismiss it — check it. Because when you open up a production system marketed this way and look at what's actually running underneath the conversational interface, you find something specific and well-understood: distributed event processing, stateful correlation, graph analytics, deterministic workflow orchestration, and a probabilistic layer bolted on top for enrichment and language generation. That's not a criticism. Those are good, mature, battle-tested architectural patterns. But they are not autonomous cognition, and the difference isn't semantic — it determines how the system fails, who's accountable when it does, and what you're allowed to trust it to do without a human in the loop.
This is the first piece in a six-part series working through that argument in full — adapted from a longer paper I wrote this year, Bounded by Design. If you want the whole thing at once, the complete paper is linked at the bottom. If you'd rather take it a piece at a time, this is where it starts.
This is an old problem wearing a new interface
Security telemetry today comes from identity providers, cloud control planes, endpoint agents, DNS resolvers, firewalls, SaaS audit logs, container runtimes, Kubernetes control planes, proxies, packet sensors, and CI/CD pipelines — each emitting events in a different format, at a different velocity, with different assumptions about what "truth" even means. A platform has to ingest all of it, preserve ordering, normalize it into something coherent, enrich it with context, correlate it against everything that came before, and decide what deserves a human's attention.
That's an event-processing problem. It was an event-processing problem in 1995. The fact that a modern platform can now use a language model to summarize an investigation or explain why an alert fired doesn't change the shape of the underlying problem — it changes what happens after the deterministic systems have already done the hard part. The model is downstream. It receives context that ingestion, normalization, enrichment, and correlation have already shaped, and it produces language, ranking, or classification within boundaries that policy and orchestration still enforce.
The lineage nobody's citing in the sales deck
This didn't start with LLMs, and pretending it did erases three decades of real engineering.
Snort, released in 1998, established the pattern every platform since has inherited: capture traffic, apply detection logic, raise an alert when a signature matches. Simple, and it worked at production network speed — but it evaluated one event at a time, and it didn't take long to learn that a single event rarely tells you anything. A failed login means nothing. A failed login from an unusual location, followed by a successful one, followed by access to a privileged resource — that's a story. Telling that story requires memory: the system has to track entities — users, endpoints, sessions — and update their risk state as new events arrive. That shift, from single-event evaluation to continuously maintained state, is what turned IDS into SIEM.
SOAR solved the next bottleneck, which wasn't detection — it was everything that used to happen after detection. An analyst getting an alert, manually pulling endpoint data, checking identity context, searching threat intel, deciding if it mattered, opening a ticket, maybe isolating a host. SOAR encoded that sequence into executable automation. And here's the part worth sitting with: SOAR did all of this — branching logic, multi-system enrichment, conditional containment, human approval gates — without any AI at all. It looked intelligent because the procedure was intelligent, encoded by people who understood the investigation, and executed reliably by a deterministic workflow engine. A playbook is a state machine. It always was.
Modern agentic security platforms are built on this exact foundation. The interface is now conversational. The enrichment layer now uses embeddings. The planning layer now uses a language model to decide what to do next within a bounded set of options. All real improvements. None of them replace the event bus, the entity graph, the workflow engine, or the policy layer underneath — they extend it.
Why this matters more than it sounds like it should
You might reasonably ask: who cares what we call it, if it works? Architecture determines failure behavior — and failure behavior is the only thing that matters once a system has the authority to disable an account, isolate a production host, or revoke a credential. A deterministic workflow engine with a probabilistic layer on top fails in an inspectable way: a rule was wrong, a state transition was misconfigured, an API call failed. You can find it and fix it. A system genuinely operating on autonomous judgment fails in a much harder way to catch — and calling a bounded orchestration system "autonomous" doesn't make it safer. It just sets an expectation the architecture was never built to meet.
That's the case this series is going to make, section by section: not that AI doesn't belong in security operations — it clearly does, and does real work there — but that the industry has gotten sloppy about the difference between a system that reasons and a system that executes a well-designed procedure with a language model attached to the front of it. Getting that distinction right is the entire job of a security architect right now.