How Not to Kill Your AI SOC

Disclaimer: Opinions expressed are solely my own and do not reflect the views or opinions of my employer or any other affiliated entities. Any sponsored content featured on this blog is independent and does not imply endorsement by, nor relationship with, my employer or affiliated organisations.

Route the wrong stage to the wrong tier and the system fails in a way no accuracy number will show you.

An AI SOC is not one technology. It is at least three, with different cost, latency, and reliability characteristics. The engineering question is not which one to use. It is which one to apply where.

Most products collapse too much into one tier. That is where the failures come from.

Deterministic execution. Code, rules, workflows, lookups. Correct behavior is specified in advance, execution follows explicit logic, marginal compute cost is typically low, and the path is straightforward to audit.

Machine learning. Classification, clustering, anomaly detection, baselining, graph analysis. Operates over a population and finds structure nobody can completely specify in advance. Low cost per item and measurable with precision, recall, false positive rate, and drift.

Language models, large and small. Reasoning over unstructured and contradictory evidence, forming hypotheses, generating queries, producing explanations. Highest cost, highest latency, and the tier whose output is hardest to reproduce exactly.

There is ordinary analytics around these tiers too. A count, aggregation, join, or group-by is not machine learning. If SQL can answer the question exactly, SQL does not need an agentic rebrand.

The architectural principle is simple. Computation with a known operation and a correct answer should happen outside the reasoning model.

Product Updates Section !

Deterministic owns repeatable stages and enforcement:

A guardrail that holds most of the time is not a guardrail. Your account disable action does not need to be creative.

Machine learning owns scale:

Language models own judgment:

Small models deserve separate mention. Narrow repeated tasks such as alert classification, observable extraction, and case routing do not need a frontier model. They are cheaper, faster, and easier to evaluate because the task is bounded.

Not every alert needs to visit a data center full of GPUs before somebody decides it is another failed login.

The industry uses one word for three very different operations.

Grouping by shared key is deterministic. Same host, same rule, same user, same time window. Most products call this correlation. It is aggregation, and it finds what already shares an identifier.

Statistical and graph correlation is ML. Co-occurrence that exceeds baseline, sequences that repeat across a population, paths through an entity graph connecting signals with no direct key. It finds that two things travel together, not necessarily why.

Attack-pattern correlation is reasoning-led. A failed authentication in one system, a scheduled task created somewhere else, and an outbound connection from a third host may share no direct key and have little useful statistical history. They can still belong to the same case because they fit an adversary behavior chain.

Recognizing that means hypothesizing a relationship, then looking for evidence that confirms or kills it.

Reasoning is not the only way to correlate an attack chain. Rules, graphs, and sequence models can identify parts of one. The difference is that reasoning can hypothesize a relationship nobody encoded in advance and actively investigate it.

Rule-based correlation engines have been shipping since the early 2000s, but somebody has to anticipate the relationship.

We have spent twenty years writing increasingly sophisticated versions of "if A and B happen within fifteen minutes, open a case."

It works. Until the attacker does C.

The number of possible combinations is too large for a team to enumerate. That is one of the constraints reasoning lifts, and it is a better argument for AI SOC than faster triage ever was.

Four questions settle most cases.

Frequency does not change the answer.

A judgment call does not become a lookup because it happens a thousand times a day. But high frequency changes the economics.

Decompose the work. Maybe the enrichment in front of the verdict is deterministic. Maybe extraction can move to a small model. Maybe routing happens before reasoning. Move those parts down and keep judgment where it belongs.

This is how you avoid paying frontier-model prices to discover that 8.8.8.8 is Google DNS for the ten-thousandth time.

The incumbents built the ML tier. SIEM, UEBA, and EDR vendors have run clustering, baselining, and statistical scoring in production for years.

A large share of newer AI SOC entrants started at the language model and never built the middle. Not all of them, and some ship real ML without talking about it, because ML had bad marketing and agents currently have excellent marketing.

The math did not care.

A model with a query tool can tell you the same pattern fired 4,000 times this month across 200 hosts. The question was never capability. It is what the answer costs, how long it takes, and whether you can trust it twice.

A group-by over indexed data runs in milliseconds and returns an exact result for the state of that data. Reaching the same result through a model means either asking it to generate the query, which is reasonable, or pulling records into context and asking it to do the computation, which is not.

Let the model write the SQL.

Do not make the model cosplay as the database.

Where the missing ML tier actually hurts is the work that has no simple query to write.

Which behavior is anomalous for this account? What does normal look like for a service principal nobody documented? Which signals travel together across the estate without sharing a key?

Those answers come from computation over the population. If that computation does not exist, the reasoning tier is not filling the gap. It is working without the input.

You can build an AI SOC without a real ML tier. But the work relocates:

This can hold together at moderate volume. At scale, population-level questions either go unanswered or get answered by running a model over work a cheap classifier or statistical system should have handled.

The problem is discovering that architecture at renewal, when the token bill scales with alert volume and nobody can explain how accurate the prioritization is.

Nothing makes architecture visible quite like the renewal spreadsheet.

Every SOAR program has some version of the same history.

A playbook covers the common case. A field changes. An unusual variant arrives. An API returns an unexpected error. The team patches it. Patches accumulate. Maintenance eventually costs more than the work being automated and the playbook gets quietly disabled.

Nobody deletes it, obviously.

It remains in the SOAR forever, named something like Phishing_Response_v2_FINAL_new.

The failure was not determinism. The problem was that every exception had to be anticipated and implemented by a human.

Reasoning changes that in two places.

Runtime fallback. When the deterministic path reaches a condition it does not handle, escalate that case to reasoning. Deterministic execution keeps carrying the volume. You pay for reasoning on the fraction that needs it.

Build-time repair. Coding agents can write and fix the deterministic layer. New parsers, integrations against documented APIs, workflow updates after schema changes. This is bounded work that can be tested.

Together they create a useful loop.

If reasoning handles the same edge case repeatedly, codify it. Move it into the deterministic path and the next execution is fast, repeatable, and cheap.

The system should get cheaper and more predictable as it learns what work no longer requires reasoning.

Agent-written code is still code, though. It needs tests, review, version control, and an owner.

git blame does not accept "the agent wrote it" as an answer.

This is the argument for combining them.

Deterministic logic fails at the boundary of what was anticipated. Good systems fail closed or escalate. Bad ones keep executing because the input passes validation while the assumptions underneath it are wrong.

Machine learning fails on drift. The environment moves since training or calibration and performance degrades gradually rather than breaking visibly.

Language models produce confident, well-written output that can be wrong. Fluency is not calibration.

Combined, they check each other.

Deterministic guardrails constrain what reasoning can act on. ML output becomes evidence rather than a verdict. Model output gets validated against deterministic schemas. Closed case history supports baselining and similarity while giving reasoning grounded precedent.

A system made entirely of rules cannot handle what nobody encoded.

A system made entirely of a model cannot give you the execution guarantees you need.

Putting autonomous in front of either one does not change that.

It is common to hear that language models are inherently non-deterministic. The reality is more interesting.

With greedy decoding, often exposed through temperature-zero settings, the decoder selects the highest-probability next token. Output can still vary. Thinking Machines Lab showed that batch-size dependence in inference kernels is an important source of that variance. Their batch-invariant implementation produced bitwise-identical output across repeated runs, with a throughput cost.

Reproducibility is an engineering choice with a price, not a law of nature.

In an agentic system, the larger source of variance often sits above the model anyway. Tool results change. Retrieved context changes. Multi-step paths diverge. Model and prompt versions change.

By step six, arguing about temperature zero is a bit like arguing about the accuracy of the compass after somebody moved the road.

So do not design around the assumption that a run repeats. Pin versions, validate schemas, test properties rather than exact strings, and keep irreversible actions behind deterministic gates.

There is another layer underneath all three.

Anton Chuvakin makes this case in his API or Die audit [LINK]. Agents consume APIs at a frequency no human would. An analyst may query a SIEM a handful of times an hour. An agent can do it a hundred times in under a minute.

Run that across an incident and your AI transformation project becomes a load test against your own infrastructure.

Each tier also needs different data.

Deterministic execution needs stable schemas. ML needs representative history, and supervised tasks need reliable labels. Reasoning needs joinable context and structured output.

Hand a model a two megabyte text blob and it spends tokens finding the evidence before it can reason about it.

And access is not retrieval.

MCP standardizes how tools are described and called. It does not make a slow API fast, fix permissions, or repair bad data.

Wrapping a legacy interface in MCP gives you a legacy interface with a manifest.

Congratulations, the technical debt now has a tool description.

Retrieval has the same problem. Security data contains exact facts, relationships, timelines, and prose. Those need different retrieval methods.

A hash does not need semantic meaning. It needs the right row.

Google DeepMind's work on embedding-based retrieval demonstrates fundamental limitations of single-vector retrieval. For a SOC, retrieval needs to be hybrid: exact lookups and queries for facts, ranking for related history, and vector search where the source is actually unstructured.

Retrieval quality becomes a hard ceiling on reasoning quality.

Garbage in, but now with a very articulate incident summary.

Do not send everything to the biggest model you can afford.

Do not call every group of alerts correlation.

Do not ask a model whether something is anomalous without giving it a baseline.

Do not embed hashes, IDs, timestamps, and every other fact with an exact answer because somebody said RAG.

Do not give the agent 200 tools and hope it develops good taste.

Do not let the same probabilistic system investigate an account, decide it is compromised, and disable it.

And please do not measure all of this with one accuracy number, make the number green, and put it in the QBR.

Use deterministic execution where the operation is known. Use analytics and ML where the answer lives in the population. Pay for reasoning where judgment is actually required. Keep enforcement deterministic.

The goal is not to put AI everywhere in the SOC.

The goal is to know where not to put it.

If everything routes through a frontier model, cost scales with alert volume and peaks when you need the system most.

And if one accuracy number describes the whole architecture, ask what exactly it measured.