Two dispatches in, I've made the case that agentic security platforms are event-driven systems at their core, and that everything above the pipeline is bounded by what the pipeline actually delivers. This week I want to look at the part of these systems that most convincingly feels like reasoning — stateful correlation and graph analytics — and be precise about what it actually is.
Meaning isn't in the event. It's in the accumulation.
A single failed login, DNS query, process start, or outbound connection almost never tells you anything on its own. Meaning shows up when an event gets interpreted against everything that came before it: prior behavior, asset context, identity privileges, network relationships, sequence. That's why every serious security platform, past and present, is built around stateful correlation — the system has to remember.
Modern AI vocabulary likes to call this accumulated state "memory," and that word isn't wrong exactly, but it's imprecise in a way that has real consequences. In most production systems, what gets called agent memory is a distributed entity store, a graph database, a feature store, a time-series database, a case management system, or some blend of all of them — and each of those has different consistency guarantees and different failure modes. A graph database preserves explicit relationships well but handles temporal decay awkwardly. A vector store can retrieve semantically similar prior incidents but doesn't preserve exact causality. A time-series store keeps historical measurements but not entity semantics. A case management system keeps analyst decisions but not raw telemetry.
Calling all of that interchangeably "agent memory" erases exactly the distinctions that matter. A language model's context window is not a durable investigative record. A vector retrieval result is not ground truth. A graph edge is not causal proof. An analyst trusting a model-generated summary needs to know which of these systems actually contributed to it and what guarantee each one provides — because without that provenance, fluent language makes weak evidence look authoritative. That's not a hypothetical risk. It's the specific mechanism by which a confident, well-written incident summary ends up being wrong in a way nobody catches until it's expensive.
Why graphs make platforms look smart
If there's one capability that makes modern security platforms feel like a genuine leap forward, it's graph analytics — and it's earned that reputation honestly. Security environments are naturally graph-shaped. Users relate to devices. Devices run processes. Processes open connections. Identities assume roles. Roles reach resources. Certificates identify services. DNS names resolve to addresses. When a platform can show that a user authenticated to an endpoint, launched a suspicious process, accessed a credential store, connected to an unfamiliar destination, assumed a cloud role, and modified a policy — in that order, as one connected chain — it looks like it reasoned its way through an investigation.
Mostly, it traversed a graph. Graph traversal can genuinely reveal lateral movement paths, privilege escalation chains, blast radius, and hidden dependencies that would take a human analyst far longer to piece together by hand. That's real, valuable capability, and it's a large part of what separates a modern platform from a decade-old one.
But the appearance of reasoning comes specifically from the fact that a path through a graph resembles a human investigative chain — and that resemblance is only as trustworthy as the graph underneath it. If the graph is wrong, the story it tells is wrong. If an identity mapping is stale, a relationship gets misattributed to the wrong person. If process telemetry is missing, the system can infer causality where none exists. AI can make that graph easier for an analyst to read and understand in plain language — genuinely useful — but it doesn't remove the requirement for rigorous graph construction underneath. Good graph construction is data engineering. What sits on top of it is presentation.
The planner-executor pattern, and where it actually stops
The mechanism behind most "AI agent" tool-calling and multi-step investigation you'll see demonstrated — observe, reason, select an action, observe the result, repeat — comes from a pattern called ReAct, formalized by researchers at Princeton and Google in 2022. It's become the architectural backbone of nearly every current AI agent implementation, security or otherwise, and it's a genuinely useful pattern for letting a model interleave reasoning with tool use instead of trying to plan an entire investigation in one shot.
It is also not something a production security environment can let run unconstrained, and the more thoughtful vendors know this. The agent's tool catalog has to be restricted to pre-approved integrations. Its permissions have to be scoped to its actual role. Its actions have to be logged for audit. Remediation authority has to be gated behind policy checks. Access to sensitive data has to be governed. High-risk actions need a human in the loop. Execution needs to be reproducible.
What you end up with isn't free autonomy — it's bounded orchestration. The agent operates inside an execution envelope that policy, permissions, tool schemas, and safety controls define in advance. It can choose among allowed actions; it doesn't define what's allowed. It can recommend remediation; it doesn't bypass authorization. It can summarize evidence; it doesn't manufacture ground truth. The thing that actually distinguishes a modern security agent from a classical SOAR playbook is dynamic selection within a bounded set of actions — not the removal of the bounds. A platform that can't tell you what its bounds are isn't more agentic for it. It's just less safe, and it usually doesn't know that about itself until something goes wrong.
What this means for how you evaluate a platform
The honest test for any agentic security product isn't "does it sound smart in the demo." It's: can the vendor show you which parts of that investigation came from a durable, auditable record, and which parts came from a model interpreting or summarizing that record? Can they tell you exactly what the agent is and isn't permitted to do, in specific terms, not marketing terms? If the answer is vague, that vagueness is the actual product risk — not the AI itself.