Notifications
Clear all
Topic starter
02/08/2026 12:06 pm
TL;DR: LLMs can help SOC teams summarise alerts and speed investigations, but Exaforce argues they are only one layer in an AI SOC because context loss, hallucinations, and inconsistent log schemas undermine accuracy without pre-processing, semantic normalization, and validation. The real design problem is not model capability alone, but whether security data can be made trustworthy enough for agentic workflows to act on it.
NHIMG editorial — based on content published by Exaforce: One LLM does not an AI SOC make
Questions worth separating out
Q: What breaks when an AI SOC relies on a single LLM?
A: A single LLM breaks down when it is expected to read raw security data, preserve context over long investigations, and produce reliable judgments without validation.
Q: Why do identity logs create problems for AI SOC automation?
A: Identity logs often represent the same action with different field names, schemas, and semantics across vendors.
Q: How can analysts tell whether AI-driven SOC automation is actually working?
A: Look beyond alert volume and measure whether the platform produces accurate incidents, preserves tenant context, and shortens time to closure without creating rework.
Practitioner guidance
- Normalize identity logs into a canonical schema Map Entra ID, Google Workspace, Okta, and other identity sources to a shared event model before LLM ingestion so the same action is represented consistently across platforms.
- Insert evaluation gates between agents Use validation agents or deterministic checks to compare intermediate findings against source evidence before passing a case to the next stage.
- Keep anomaly detection outside the LLM Run behavioural analytics, thresholding, and statistical detection in dedicated systems such as UEBA or other analytics engines, then feed the structured findings to the model for triage and explanation.
What's in the full article
Exaforce's full blog covers the operational detail this post intentionally leaves for the source:
- Concrete examples of how the semantic layer normalizes Entra ID, Google Workspace, and Okta logs into a common structure.
- The multi-agent workflow design behind orchestrator, evaluation, and response agents in an AI SOC.
- Implementation details for pre-LLM data processing, including deduplication, sanitization, and schema definition.
- The specific reasoning limits the vendor associates with context windows, drift, and hallucination in SOC investigations.
👉 Read Exaforce's analysis of why one LLM is not enough for an AI SOC →
AI SOCs need more than one LLM: where the architecture breaks?
Explore further
02/08/2026 1:11 pm
One LLM is not an AI SOC because security operations depend on structured truth, not fluent output. The article correctly identifies the central design error in many AI SOC discussions: assuming the model itself is the product. SOC value comes from the pipeline around the model, including normalization, enrichment, evaluation, and controlled handoff between tools. When identity logs and security events arrive in incompatible formats, the model cannot reliably infer meaning from syntax alone. Practitioners should treat the LLM as an interface layer, not the trust anchor.
A question worth separating out:
Q: Should SOC teams use LLMs for all detection and response tasks?
A: No. LLMs are better at summarising, explaining, and orchestrating than at statistical detection or truth verification. High-confidence anomaly detection, correlation, and numeric analysis should remain in specialised systems, with the model used to interpret those outputs and support analyst decision-making.
👉 Read our full editorial: Why one LLM is not enough for an AI SOC
