Elastic's Agentic SOC: How Self-Correcting AI Agents Lifted Alert Triage Accuracy from 60% to 92% — Lessons for Your SOC

Alert triage remains the single largest tax on SOC productivity. Analysts spend the majority of their shift clearing a queue dominated by false positives and low-fidelity detections, and every hour spent on noise is an hour not spent hunting the intrusion that actually matters. Elastic's InfoSec team just published a detailed engineering account of how they attacked this problem internally: a multi-agent AI triage system that improved automated triage accuracy from roughly 60% to 92%, to the point where analysts now clear most alerts with a single click inside Slack.

This matters to defenders for two reasons. First, it is a rare, transparent look at an agentic SOC architecture that actually works in production — not a vendor demo. Second, it carries a hard lesson that most organizations rushing to bolt LLMs onto their SOC are learning the expensive way: the model is not the hard part. The accuracy jump did not come from a better foundation model. It came from context engineering, structured feedback loops, and treating AI triage as a supervised system that must earn autonomy. If your organization is evaluating AI-assisted triage in 2026 — and nearly every SOC is — this is the reference architecture to study before you write a check or wire an agent to your case management system.

Technical Analysis: How Elastic's Agentic Triage Actually Works

The Problem With Naive AI Triage

The first iteration of Elastic's approach followed the pattern most teams attempt: point a large language model at an alert, ask it to determine malicious or benign, and route the verdict into the workflow. The result was approximately 60% accuracy — marginally better than a coin flip and nowhere near the threshold where analysts would trust the output. At 60%, the AI is not reducing workload; it is adding a second triage step that analysts must double-check, which is worse than no automation at all.

The root cause was not model capability. It was missing context. A raw alert — a detection rule name, a process tree, some network telemetry — is insufficient for any triage decision, human or machine. Human analysts compensate by pulling runbooks, checking historical precedent, and applying institutional knowledge about what is normal in their environment. The initial agent had none of that.

The Three-Agent Architecture

Elastic's production system decomposes triage into a pipeline of three specialized agents rather than one monolithic prompt:

1. Context assembly. The agents read the detection rule's investigation guide — the structured runbook Elastic Security ships with (and lets you attach to) each detection rule. This gives the model the same decision framework a human analyst would follow: what to look for, what benign looks like, what escalation criteria apply.

2. Historical precedent retrieval. The agents mine the closure reasons analysts wrote on cases from the trailing 30 days. This is the critical design decision. Every time an analyst closes a case as false positive, benign positive, or true positive with a written rationale, that rationale becomes training-context for future triage. The system learns your environment's ground truth continuously, without fine-tuning, simply by retrieving relevant prior closures at inference time.

3. Verdict and feedback loop. The triage output is delivered to analysts in Slack, where most alerts are now cleared with a single click. That click — agree or override — feeds back into the system, making the agents self-correcting. When the agent is wrong, the analyst's correction becomes new closure-reason context that prevents the same misclassification from recurring.

Why 92% Is the Number That Matters

The jump from 60% to 92% was achieved without changing the underlying model. It came from two disciplines most AI-SOC projects skip entirely:

• Context engineering over prompt engineering. The investigation guide and historical closure reasons are retrieval-augmented context, not clever prompting. The agent is answering the question with the same evidence a senior analyst would gather.
• Human-in-the-loop by design. Analysts remain the authority. The agent proposes; the analyst disposes with one click. Autonomy is scoped to drafting and recommending, not unilateral closure — which is the correct trust posture for any AI system operating on security verdicts in 2026.

The Defender's Risk Lens

A practitioner reading this should also see the failure modes. An agent that learns from closure reasons will faithfully reproduce your analysts' biases — including their mistakes. If your team has been systematically misclassifying a certain alert type as benign, the agent will institutionalize that error at machine speed. Similarly, investigation guides written poorly produce poor agent behavior. Garbage in, garbage out, now automated. And any pipeline where an LLM consumes alert content must treat attacker-controlled strings in that content (file names, command lines, email bodies) as untrusted input — prompt injection via alert telemetry is a real attack surface that your triage agent's prompt design must explicitly defend against.

Executive Takeaways

This story is a defensive architecture lesson, not a threat event — so instead of detection rules, here are the recommendations we give clients building toward AI-assisted triage:

1. Instrument your closure reasons before you buy anything. Elastic's system works because analysts write structured, meaningful rationales when closing cases, and those rationales are retrievable. If your case closure field today is a dropdown of "FP / TP / Benign" with a blank comment box, you have no ground truth to feed an agent. Mandate substantive closure notes now — it improves human triage immediately and builds the dataset your future agent needs.

2. Write investigation guides for your highest-volume detection rules first. Do not attempt to give an agent context for all 400 rules in your environment. Take the 20 rules generating 80% of your alert volume and author proper runbooks: expected benign behavior, key fields to examine, escalation criteria. This is valuable for human analysts even if you never deploy an agent.

3. Keep the human as the decision authority. Elastic's one-click Slack approval model is the right pattern: the agent drafts a verdict with reasoning, the analyst confirms or overrides in seconds, and the override becomes corrective context. Resist pressure to let agents auto-close alerts. The moment an agent silently closes a true positive, your AI initiative becomes an IR case study instead of an efficiency one.

4. Treat alert content as untrusted input to the model. Alerts contain attacker-influenced strings. Any LLM triage pipeline must sanitize and delimit telemetry fields, restrict the agent's tool access to read-only context retrieval, and never let alert content instruct the agent to take actions. Threat-model the agent itself — it is now part of your attack surface.

5. Measure accuracy against analyst verdicts, not vibes. The 60% → 92% number exists because Elastic tracked agreement between agent verdicts and analyst dispositions over time. Stand up that measurement loop on day one. If you cannot quantify triage accuracy, you cannot know whether your agent is helping or quietly corrupting your detection outcomes.

6. Expect the environment-specific work to dominate. The model is a commodity; the closure-reason corpus, the investigation guides, and the feedback plumbing are your institutional knowledge encoded. Budget engineering time for data hygiene and pipeline integration — that is where the accuracy actually lives.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub