By Dr. Deb Banerjee
In my previous article, I argued that AI agents succeed in the SOC when they are grounded in the enterprise’s unique data landscape. Situational awareness — powered by an Enterprise Security Graph — is necessary for successful outcomes in enterprise SOC’s beyond vendor demo environments.
But the grounding is only the foundation. For narrow and well-defined use cases with clear success criteria, developing AI agents can be as simple as using a frontier model, making available a set of tools with access to enterprise data, and detailing the task workflow in a system prompt.
In practice, even with perfect enterprise context, Large Language Models (LLMs) still fail in subtle and sometimes dangerous ways which surface commonly in these failure patterns.
- Hallucinations. There remains the problem of hallucination. For example, when asked to find endpoint threat indicators in a threat report focussed exclusively on network indicators it may respond by making up process paths and registry keys.
- Context Collapse. Keeping the agents grounded in SOC context is critical to accuracy; however if irrelevant pieces of context are provided to the LLM that can bias the LLM towards incorrect conclusions.
A variety of agentic design patterns have emerged to mitigate these problems. A fundamental design principle is to keep LLM focussed on narrow goals with precisely provided context. These require breaking down complex use cases into precise workflow steps which are delegated to teams of agents. Each of these agents are provided a narrow set of tools, and model context is precisely managed. Verifier agents are attached to each of the workflow steps which checks against hallucinations and verifies response quality against the enterprise environments.
We will describe how we have applied these agentic design patterns for developing reliable enterprise-grade AI SOC agents.
Even Perfect Context Doesn’t Eliminate Failure
Let’s assume we have done everything right architecturally.
We have:
- A continuously maintained Enterprise Security Graph.
- Accurate mappings to various standards including OCSF, CIM, and MITRE ATT&CK.
- Perfect visibility of events and alerts and detections across your data lake repositories such as Snowflake, Databricks, Splunk, ADX, and Log Analytics.
Even in that environment, LLM-based agents can exhibit unpredictable failure modes.
They:
- Hallucinate missing steps when reasoning chains are incomplete.
- Drift when exposed to too much context.
- Overgeneralize from adjacent patterns.
- Invent plausible but non-existent field names.
- Select incorrect tools when too many are available.
- Fill in gaps confidently when uncertainty is present.
Context reduces randomness. It does not eliminate probabilistic behavior.
And in most domains, that is acceptable. In marketing, summarization, or creative writing, a probabilistic output is fine.
In detection engineering, it is not.
The SOC Is an Intolerance Environment
Security operations is what I call an “intolerance environment.”
We cannot tolerate:
- “Mostly correct” detections.
- 90% accurate schema mappings.
- Plausible but unverifiable threat indicators.
- Silent schema drift.
- Queries that run but reference the wrong domain.
A detection that is syntactically correct but logically flawed is more dangerous than no detection at all. It creates false confidence.
This is where many early AI SOC projects failed. They assumed that improving model reasoning would eventually solve reliability. But model intelligence is not the same thing as system stability.
Determinism is not an emergent property of better prompts. It is an engineered outcome.
Predictable Failure Patterns in Agentic Detection Systems
When you look closely at multi-agent detection systems, failure patterns are not random. They are structural.
1. Context Collapse
More context is not always better. When an agent is exposed to excessive telemetry or documentation, it can lose its original constraint set. It begins reasoning more broadly than intended, drifting into adjacent domains or hallucinating connections.
2. Tool Overload
Agents exposed to too many tools often select the wrong one. A web log detection may accidentally pull endpoint logic simply because the agent sees it as relevant in a semantic sense.
3. Schema Drift
An agent invents or misapplies fields that “should” exist. The query looks reasonable, but the field is not present in the actual environment.
4. Indicator Hallucination
When extracting indicators from research blogs, LLMs can generate plausible but uncited URIs or hashes — especially if similar patterns exist in training data.
5. Cascading Error Amplification
The most dangerous failure mode is compounding error. A small mistake in intelligence extraction propagates into schema mapping, then into query generation, and finally into production deployment.
If the workflow is monolithic, these failures are hard to detect. By the time you see the error, it is deeply embedded.
This is not a model problem. It is a workflow design problem.
Engineering Discipline Over Model Brilliance
The path forward is not selecting a “smarter” model. It is structuring the workflow so that failure cannot propagate.
There are three core principles.
1. Workflow Decomposition
Detection engineering must be broken into discrete, verifiable steps:
- Intelligence extraction
- Indicator validation
- Schema mapping
- Data source selection
- Query generation
- Syntax validation
- False-positive reduction
Each step produces an artifact that can be independently checked.
When detection generation is treated as a single reasoning task, you have no visibility into intermediate failure. Decomposition makes error observable.
2. Worker and Verifier Separation
In reliable agentic systems, tasks are separated between Worker Agents and Verifier Agents.
- Worker Agents perform narrowly scoped actions.
- Verifier Agents audit outputs before progression.
- No step advances without passing validation.
Verification must occur at every state transition — not just at the end.
For example:
- A Research Worker extracts installer URIs from a blog.
- A Verifier confirms verbatim citation from source text.
- A Schema Worker maps fields to normalized data models.
- A Verifier checks field existence against the actual enterprise schema.
This separation of concerns mirrors good software engineering practices. We do not merge unreviewed code into production. We should not allow unverified reasoning to progress in AI workflows either.
3. Quality Gates as Circuit Breakers
Quality gates prevent cascading error.
Examples include:
- Citation requirement before indicator acceptance.
- Field existence validation before query synthesis.
- Native syntax validation before deployment.
- Domain confirmation before data source selection.
If a worker agent fails to provide a verifiable artifact, the gate closes. The system does not “try its best.” It stops.
This transforms LLM behavior from free-form reasoning into bounded, auditable execution.
OpenClaw: A Reliability Case Study
The OpenClaw detection use case illustrates this engineering discipline in practice.
The headline result — generating a production-ready detection in under 15 minutes — is impressive. But the speed is not the interesting part.
What is interesting is how many opportunities there were to fail.
The agent could have:
- Invented installer URIs not present in the source blog.
- Chosen an endpoint detection path instead of leveraging high-fidelity proxy logs.
- Referenced non-existent fields.
- Misapplied normalization mappings.
- Generated syntactically correct but semantically invalid SQL.
Instead, the workflow enforced:
- Tight and narrow context exposure, limited to relevant Snowflake proxy schemas.
- Verbatim citation requirements for extracted indicators.
- Explicit confirmation of CIM-mapped normalized fields.
- Field existence checks before query generation.
- Syntax validation prior to execution.
The system did not trust the LLM. It structured the LLM.
The result was not just a technically correct query — it was an operationally viable detection, grounded in the enterprise’s actual architecture.
The key takeaway is not that the model reasoned well. It is that the architecture prevented failure from propagating.
From Probabilistic Models to Deterministic Outcomes
We are not making LLMs deterministic. That is not realistic.
What we are doing is designing systems where:
- Enterprise Security Graph → provides situational awareness.
- Narrow-scope agents → reduce drift.
- Verifier agents → enforce correctness.
- Quality gates → contain error.
- Workflow decomposition → exposes failure early.
The combination transforms probabilistic reasoning into deterministic operational results.
Determinism, in this context, is not a property of the model. It is a property of the workflow.
What Advanced SOC Leaders Should Demand
As agentic AI becomes embedded in SOC tooling, practitioners should ask hard questions:
- Where are the verification layers?
- What artifacts are independently validated?
- How are hallucinations detected?
- What happens when a worker agent fails?
- How is schema drift prevented?
- Are errors contained early — or discovered at the end?
AI maturity in the SOC will not be measured not only by reasoning sophistication. It will also be measured by failure containment.
The future of AI in security operations will not only be defined by how creative our models are. It will also be defined by how rigorously we engineer around their limits.
Grounding agents in enterprise context was the first step. Engineering determinism on top of probabilistic systems is the next.
Only then does agentic AI move from cool to useful.