Why one LLM is not enough for an AI SOC

At a glance

What this is: This is an analysis of why an AI SOC needs more than a single LLM, with the key finding that raw security logs must be normalised, enriched, and validated before model-driven investigation can be trusted.

Why it matters: IAM, SOC, and AI security teams need this distinction because agentic workflows inherit the quality of the underlying identity and telemetry data, especially when log sources and schemas do not align.

Context

An AI SOC is only as reliable as the security data it consumes. When identity, endpoint, cloud, and SaaS logs arrive with different field names, different schemas, and different levels of completeness, the model is forced to infer structure before it can reason about the event. That creates a governance problem as much as a technical one, because the system may appear fluent while still being grounded in inconsistent evidence.

The article’s core point is that LLMs are useful inside SOC workflows, but they are not the control plane for truth. In practice, semantic normalisation, deduplication, enrichment, and validation are the layers that make investigation outputs usable. That matters directly for IAM and NHI telemetry, where a malformed log record or missed correlation can distort account activity, access decisions, and response actions.

Key questions

Q: How should security teams structure an AI SOC so one model is not making every decision?

A: Use the LLM as one layer in a pipeline, not as the entire decision engine. Pair it with preprocessing, canonical schemas, retrieval, and separate validation so the system can interpret telemetry without inventing structure or trusting its own output blindly.

Q: Why do raw logs create risk for AI SOC workflows?

A: Raw logs create risk because they shift the burden of correlation and context reconstruction onto the model. The agent may see isolated events but not the relationships that make them meaningful, such as a brute-force pattern followed by service-account credential activity. That leads to confident misclassification, even when reasoning effort is increased.

Q: What are the signs that an AI SOC is overrelying on the model instead of the data pipeline?

A: Common warning signs are inconsistent incident summaries, missing context after agent handoffs, and model outputs that sound confident but cannot be traced to source telemetry. If validation happens only after response logic has already acted, the architecture is too model-centric.

Q: How can security teams balance LLM use with existing SIEM, SOAR, and UEBA tooling?

A: Keep SIEM, SOAR, and UEBA as the systems that collect, detect, and automate, then use the LLM to explain, triage, and coordinate. That preserves deterministic controls where precision matters and reserves the model for language-heavy investigation work.

Technical breakdown

Why raw SOC logs break LLM reasoning

LLMs operate on token patterns, not on guaranteed truth. In a SOC, the same event can appear in different shapes across Entra ID, Google Workspace, and Okta, with different fields, different timestamps, and different naming conventions. Without a semantic layer, the model must guess how those records relate. That increases the chance of incorrect summarisation, missed context, and false confidence. The issue is not just volume, but inconsistency: when telemetry is not canonicalised, the LLM cannot reliably align identity events, session data, or response signals into one coherent analytical frame.

Practical implication: normalise security telemetry before asking an LLM to investigate it.

How multi-agent SOC architectures reduce model blind spots

A single LLM prompt is too brittle for operational security work. The article describes a layered agent design with orchestration, memory, retrieval, parsing, and specialised sub-agents for endpoint, cloud, and evaluation tasks. That architecture matters because no one model should be trusted to both interpret evidence and validate its own output. Multi-agent systems can separate collection, interpretation, and review, but only if handoffs preserve context. Otherwise, the chain amplifies summary loss and the final answer becomes cleaner sounding while becoming less defensible.

Practical implication: separate interpretation from validation so one model is not grading its own work.

Why time-series and behavioural analysis still need specialised detection

SOC investigations often depend on statistical outliers, timing patterns, and behavioural drift rather than text comprehension. LLMs are weak at numerical reasoning and sequence analysis, so they should not be the first-line engine for behavioural detection. The stronger pattern is to let traditional analytics, UEBA, or similar statistical methods identify unusual activity, then pass those findings to an agent for explanation and triage. This keeps the model in the role it handles best, which is narrative synthesis over pre-computed signals, not raw anomaly detection.

Practical implication: keep statistical detection upstream of the model and let the LLM explain, not discover, the anomaly.

Threat narrative

Attacker objective: The practical objective is to exploit weak telemetry handling so the SOC reaches a wrong conclusion or misses the real access event.

1. Entry occurs when analysts or automated workflows feed heterogeneous logs directly into an LLM without canonicalisation or schema control.
2. Credential or identity context is then misread because equivalent events from Entra ID, Google Workspace, and Okta do not share the same structure or field meaning.
3. Escalation happens inside the workflow when a hallucinated or truncated interpretation is reused by later agent steps or response logic.
4. Impact is incorrect investigation output, which can distort access assessments, delay containment, or drive the wrong SOC action.

Breaches seen in the wild

• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI SOC trust starts with telemetry integrity: A model cannot compensate for logs that are inconsistent, incomplete, or semantically ambiguous. The real governance question is not whether an LLM can summarise security data, but whether the input stream has been normalised enough to support a defensible decision. In AI SOC design, data trust precedes model trust, and practitioners should treat semantic normalisation as a control layer, not a formatting convenience.

One LLM is a weak control boundary for security operations: The article exposes a common architectural mistake, which is to treat the model as the analytical core rather than the orchestration layer. That assumption fails because the SOC requires both interpretation and verification, and those are different jobs. The durable pattern is a multi-stage pipeline where specialised analytics, retrieval, and validation surround the model, which is exactly how AI governance should be applied to operational security.

Semantic drift is the hidden failure mode in agentic security workflows: When the same event is represented differently across log sources, every downstream agent inherits ambiguity. That creates a governance gap that looks like automation success until the workflow starts summarising away the very evidence it was meant to preserve. Practitioners should recognise semantic drift as a control issue, not just a data engineering issue.

Identity telemetry makes the problem concrete: SOC tooling increasingly depends on identity events from SaaS and cloud sources, and those events are rarely schema-consistent. If an AI workflow cannot reliably distinguish session creation, login success, or actor identity across platforms, it will struggle to support IAM and NHI investigations. That means AI SOC design and identity governance now overlap at the data layer, where trust is either established or lost.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Semantic normalisation will become the gating control for AI SOC adoption: Security teams that skip data shaping will end up debugging model behaviour instead of investigating threats. The more identity and cloud sources are added, the more important it becomes to standardise event meaning before any agent sees the data.

AI SOC success will be measured by traceability, not fluency: A workflow that produces polished answers but cannot explain which log record or correlation produced them will not satisfy incident response or governance requirements. Practitioners should expect validation, provenance, and source traceability to become core design requirements for agentic SOC programmes.

For practitioners

• Implement a semantic normalisation layer Convert raw security telemetry into consistent schemas before any LLM or agent consumes it, especially for identity, cloud, and SaaS logs.
• Separate generation from validation Use one component to summarise or correlate and a separate evaluation step to verify the output before it drives response decisions.
• Route behavioural detection upstream of the LLM Let statistical and UEBA-style detection identify anomalies first, then use the model for explanation, prioritisation, and analyst support.
• Design agent handoffs to preserve context Define what each sub-agent must retain, pass forward, and verify so critical identity and incident context is not stripped away during orchestration.

Key takeaways

• A single LLM cannot reliably run a SOC workflow when the underlying telemetry is inconsistent, incomplete, or semantically ambiguous.
• The architectural fix is to normalise, enrich, and validate data before and after model use, so the model stays inside a controlled workflow.
• Identity and access logs make the problem visible, because cross-platform event differences can distort investigations if the pipeline does not establish a common schema.

Key terms

• Semantic Normalisation: Semantic normalisation is the process of converting different telemetry formats into a shared structure with consistent field meanings. In an AI SOC, it reduces ambiguity so models and analysts can compare identity and security events without guessing how each source encodes the same activity.
• Context Window: The context window is the text a model receives at one time, including prompts, retrieved documents, and conversation history. Security teams care about it because it becomes the practical boundary between trusted instructions and untrusted content, especially when the application assembles that text automatically.
• Agent Orchestration: Agent orchestration is the coordination of multiple AI agents or workflows to complete a task set with limited human intervention. In identity terms, it creates delegated execution paths that need ownership, scope limits, and auditability because work is no longer performed only by a person in one session.
• Canonical Schema: A canonical schema is the standard field set and naming convention used across telemetry sources and destinations. It gives security teams one expected record shape, which simplifies detection logic, correlation, and migration testing when multiple collectors or platforms are involved.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle controls. It is designed for practitioners building programmes that need stronger control over access, trust, and lifecycle risk.