Why do LLMs struggle with SOC triage compared with traditional automation?

Why This Matters for Security Teams

SOC triage is not just classification. It is a sequence of decisions about priority, confidence, escalation, and containment, all made under time pressure and with incomplete evidence. LLMs can be useful for summarisation and analyst support, but they are not inherently reliable triage engines because their outputs can shift with prompt wording, context-window limits, model updates, and retrieval quality. That variability creates operational risk when the team needs repeatable outcomes rather than persuasive language. The NIST AI Risk Management Framework is useful here because it frames AI use around governable risk, not just capability.

Traditional automation has narrower behaviour, but that is often an advantage in SOC workflows. If a rule, playbook, or enrichment step is designed well, the team can test it, version it, and prove what it will do in a given condition. LLMs introduce another layer of judgment that can be hard to bound, especially when incident context changes quickly or when adversaries deliberately shape the input. This is why current guidance suggests treating LLMs as assistive controls, not primary adjudicators, for high-volume alert handling. In practice, many security teams encounter this only after a noisy alert queue has already been normalised by inconsistent model-driven recommendations.

How It Works in Practice

Traditional soc automation usually follows fixed logic: ingest telemetry, enrich with asset and identity context, score the alert, then route it based on thresholds. That flow is predictable and lends itself to validation against known cases. An LLM can sit on top of that flow, but it struggles when asked to make the flow itself adaptive because the model is probabilistic, context-sensitive, and only as good as the evidence it is given. The OWASP Agentic AI Top 10 and MITRE ATLAS adversarial AI threat matrix both highlight risks that matter in SOC workflows, including prompt injection, manipulation of tool use, and adversarial shaping of outputs.

• Use LLMs for summarising alerts, extracting likely entities, and drafting analyst notes.
• Keep deterministic rules for severity scoring, case routing, and containment triggers.
• Constrain retrieval so the model only sees approved runbooks, asset data, and incident history.
• Log prompts, outputs, and model versioning so results can be reviewed after the fact.
• Require human approval for actions that change access, isolate systems, or close incidents.

The main implementation issue is that SOC data is noisy and time-sensitive. Alerts often combine weak signals from endpoint, identity, cloud, and network sources, and the model may overweight whichever signal is most visible in the prompt. That is why the NIST AI 600-1 Generative AI Profile is relevant for shaping usage boundaries, while the Anthropic report on AI-orchestrated cyber espionage is a reminder that attackers already try to use AI to improve operational tradecraft. These controls tend to break down when the SOC is expected to let an LLM autonomously close alerts in fast-moving environments with poor telemetry quality and inconsistent enrichment.

Common Variations and Edge Cases

Tighter control over LLM use often increases latency and analyst overhead, requiring organisations to balance speed against auditability and decision quality. That tradeoff is especially visible in smaller SOCs that want a single assistant to summarise, prioritise, and recommend action. Best practice is evolving, but there is no universal standard that says an LLM should own triage decisions end to end. For now, the safer pattern is to let the model support human judgement while deterministic automation preserves the final routing logic.

Edge cases are where LLMs tend to disappoint most. Long incident histories may exceed the context window, making the model miss earlier indicators. Highly repetitive phishing, brute-force, or malware alerts are often better handled by rules because the desired outcome is stable and measurable. Conversely, novel campaigns may benefit from narrative summarisation, but not from fully autonomous severity decisions. The NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for mapping logging, review, and approval requirements to operational workflows, while the CSA MAESTRO agentic AI threat modeling framework helps teams think about tool-use boundaries and failure modes. Where the environment depends on strict chain-of-custody, regulated reporting, or rapid containment across identity and endpoint controls, LLM-led triage usually becomes too unpredictable to trust without heavy guardrails.

Related resources from NHI Mgmt Group

• Why do agentic AI workflows create new IAM risk compared with traditional automation?
• Why do AI-driven SOC workflows need stronger governance than traditional automation?
• Why do traditional SOC playbooks struggle in cloud and identity-heavy environments?
• Why do SOC teams struggle to scale SOAR automation?