Three dispatches in, everything I've argued has been building toward this one distinction, and if you only take one idea from this entire series, I'd want it to be this: deterministic orchestration and probabilistic enrichment are not interchangeable, and a safe security platform never lets them substitute for each other.
Two systems, two failure modes
Deterministic systems produce predictable, inspectable outcomes from defined inputs and known state. Probabilistic systems produce outputs from statistical inference — learned associations, embeddings, rankings, generation. Every serious security platform needs both. The mistake, and it's a common one, is treating them as if they belong to the same category of trust.
Deterministic orchestration matters because security operations have side effects that reach outside the platform. Disabling an account, isolating an endpoint, blocking traffic, revoking a token, changing firewall policy, deleting a workload — each of those affects a real business operation, sometimes a critical one. Actions with consequences like that need authorization, auditability, rollback planning, and predictable execution. And when a deterministic system fails, the failure is usually inspectable: a rule was wrong, a state transition was incorrect, a workflow condition was misconfigured, an API call failed. You can find it. You can fix it. You can explain to leadership exactly what happened and why it won't happen the same way twice.
Probabilistic systems fail differently, and less legibly. They can hallucinate — produce plausible, confident, and completely unsupported output that's genuinely difficult to catch without independently checking it against the source. They can overgeneralize. They can misread retrieved context. In a security context, a hallucinated investigation summary that confidently cites evidence that doesn't exist isn't just inaccurate — it's operationally dangerous, because the entire reason an analyst trusts a summary is to avoid re-verifying everything underneath it. Undermine that trust once, quietly, and you've made the tool worse than not having it.
The line that has to hold
Probabilistic systems recommend, classify, summarize, and prioritize. Deterministic systems execute, enforce, persist, and audit. Those are different functions, and the correct architecture keeps them different functions — the probabilistic layer can influence the deterministic layer through recommendations and prioritization, but it should never quietly replace it.
You can see this separation in the platforms that are actually built well. A model might assign a severity score or write the investigation narrative — genuinely useful, genuinely a place where AI adds value — but the remediation action that actually happens runs through a policy engine that checks whether the target is a domain controller, a production database, an executive's workstation, a medical device, or a piece of critical operational technology, before it proceeds. That check isn't AI. It's a lookup against a maintained asset inventory, evaluated by deterministic logic that doesn't care how eloquent the model's reasoning sounded. Its presence — boring, unglamorous, absolutely not something you'd put in a product demo — is what makes the rest of the system safe to actually run.
What LLMs are actually good at, stated plainly
None of this is an argument that language models don't belong in security operations. It's an argument for being precise about where. Their real value is semantic compression, not autonomous judgment.
Analysts spend an enormous amount of time translating machine-generated evidence into something a human — often a less technical stakeholder — can understand. Reading logs, reconstructing timelines, comparing events, writing tickets, explaining risk. A model that turns a thirty-minute triage task into a three-minute review is a genuine, measurable improvement to SOC throughput. A model that lets an analyst ask "why was this alert prioritized?" and get back a coherent, honest answer builds trust in the system rather than just speed.
Retrieval-augmented generation — grounding a model's output in an organization's own prior incidents, runbooks, threat intel, and asset metadata rather than relying purely on general training knowledge — is the mechanism that makes this work in practice. But RAG doesn't solve the provenance problem, it just relocates it. The quality of a retrieval-grounded answer is bounded entirely by the quality of what got retrieved. Pull an irrelevant prior incident, outdated documentation, or a case that's semantically similar but operationally unrelated, and the model will confidently build an explanation on top of the wrong foundation. If the entity graph has a stale relationship in it, the explanation inherits that error and states it fluently.
Why this is the load-bearing wall
An analyst has to be able to trace a model's claim back to the actual source — the events, the graph relationships, the detection logic, the workflow action that fired. Without that trail, language fluency stops being an asset and starts being a liability, because polished prose is exactly what makes weak evidence look authoritative. Nobody double-checks a sentence that sounds like it already did the checking for them.
This is the section of the argument everything else hangs off of. Get this distinction right — recommend versus act, probabilistic versus deterministic — and an agentic platform is a genuine force multiplier. Blur it, even a little, even with good intentions, and you've built a system that can act with the confidence of certainty on evidence that was never certain to begin with.