You begin the day like any other Monday: You open the queue, and the wall of alerts is already waiting. New alerts land between 9:05 and 9:10 a.m., while you close yesterday’s. You're already drowning, and you haven’t even had a chance to refill your coffee. You know that you won’t be able to get to things that really need prioritization. Threat hunting stays deferred, and detection engineering waits. Incident response practice never quite starts. This is the default security operations center (SOC) day for a lot of teams, and that probably includes yours.

The concept of Alert Zero addresses this problem. It doesn’t mean that the analysts' queue will always remain at zero; new alerts will always come in, and some will still need a human in the loop to review and do deeper investigations. The goal is to keep that queue from dictating the analyst’s day. Instead of walking into a wall of alerts, the team starts with a smaller set of work that genuinely needs attention, giving analysts more time to hunt, tune rules, and investigate the threats that matter most. Alert Zero is about moving toward that kind of shift, and Elastic Security 9.5 gives teams practical tools to do it.

With 9.5, Elastic is bringing together three pieces that can move your SOC closer to Alert Zero without requiring you to build and maintain a complex agent architecture yourself:

1. The Security alert analysis workflow helps separate predictable false-positive noise from alerts that deserve attention.
2. Attack Discovery investigates the alerts worth pursuing and turns them into grounded attack narratives.
3. Elastic Workflows provides the automation layer that brings these capabilities into the playbooks your team already trusts.

You choose where to start and how much to automate. You also choose where a human still needs to approve the next step. That’s what an agentic SOC should look like in practice: agents handling more of the repetitive work, while analysts stay in control and the queue keeps moving closer to zero.

Suggested flow

What is Alert Zero, and how does it reduce SOC alert fatigue?

Alert Zero is a state that your SOC works toward over time, and 9.5 ships the pieces that make real progress toward making this practical. It isn’t a feature that you simply turn on. Most teams already automate some alert handling, whether that’s through playbooks or another automation method, but the hardest and most expensive work is usually what remains: true positives, unclear cases, and groups of related alerts that need human judgment. That’s where queues grow and analysts burn out. It’s also where gaps in your detections are easiest to miss.

Getting closer to Alert Zero changes what a security analyst’s shift can feel like. Senior analysts can spend more time investigating real risk instead of repeatedly gathering host, user, and alert context that the platform can collect for them. The queue gets shorter without turning false positives into incidents, and detection engineers can use lessons from real investigations to improve coverage. That’s the flow that every team wants and the one that the queue usually keeps out of reach.

None of this means handing the SOC over to autopilot. Analysts still make the decisions that matter. This is what we can’t stress enough. We want you to be making decisions on the things that actually matter, not automating your critical thinking away. Agents help with the first pass of triage and investigation, and you decide how much autonomy they receive. Process still matters, but Elastic Security 9.5 gives teams more practical tools for making that journey.

How Security alert analysis automates SOC alert triage

One of the first steps toward Alert Zero is reducing noise before it reaches an analyst or an agent. In Elastic Security 9.5, the Security alert analysis workflow can provide a first-pass assessment for alerts generated by rules you select. A security information and event management (SIEM) engineer or SOC manager chooses the agent and model and sets the confidence requirements. They also decide which rules participate.

When an alert fires, the workflow gathers the alert details, related alerts, frequency, and prior resolution history. It adds a note explaining the classification, confidence, and rationale, along with details about the workflow run. If you want to dig deeper, you can open the agent conversation and see what the model reviewed.

Auto-close is optional and disabled until you turn it on. Even then, it only applies to alerts classified as false positives above the confidence threshold you set. A sensible approach is to begin with notes and tags, compare the results with how your analysts would handle the same alerts, and introduce auto-close only once you trust the pattern. You remain the decision-maker; that is, you choose the rules and set the confidence level. You also decide how much autonomy is appropriate. Once those boundaries are in place, the agent operates within them.

The path to Alert Zero becomes more effective when Security alert analysis and Attack Discovery work together. Alert analysis handles the first pass by classifying alerts as true positives, false positives, or inconclusive and can optionally close high-confidence false positives. You can then use those results to focus Attack Discovery on the open alerts that deserve deeper investigation. That gives Attack Discovery a cleaner starting point and reduces noise and unnecessary token usage. That also allows it to spend more of its context finding relationships between the signals that matter. In 9.5, Attack Discovery takes that focused alert set and does more than surface a discovery; it investigates it.

How Attack Discovery investigates alerts as attack chains

Once the Security alert analysis workflow has classified and optionally closed false-positive alerts, the goal isn’t to investigate every remaining alert one by one. Attack Discovery takes that smaller set of alerts worth investigating and turns them into attack chains that become the unit of work. Since launching two years ago, its core strength has been correlating related alerts and building the broader story so analysts don’t have to piece it together manually. This frees your team to focus on the decisions and investigations that matter most.

Attack Discovery is also no longer disconnected from where analysts spend their time. In 9.5, its discoveries live on the new Attacks page under Detections, directly alongside Alerts. Analysts can begin with correlated attacks that are ready to investigate, with the underlying alert evidence right next to them when they need it, instead of starting their day with a wall of individual alerts.

In 9.5, it goes further. Attack Discovery still does what it has always done well: correlate related alerts and build the broader attack narrative. Now it investigates the activity behind that narrative, too, so by the time an analyst picks it up, much of the groundwork is already done.

Attack Discovery runs through a skill-backed pipeline powered by Elastic Agent Builder and Elastic Workflows. The skill begins by retrieving relevant alerts and then uses the available security skills to hunt for related activity, analyze individual alerts, inspect entity context, and search raw logs in the Elasticsearch platform before generating the attack narrative. These steps can uncover malicious activity that existing detections missed while gathering additional evidence to determine whether the activity represents a real attack. The result is a richer, more grounded discovery that gives analysts a much stronger place to begin their investigation.

Want to see it in action? David Elgut and Braxton Williams demo the full flow, from a noisy queue to grounded attack narratives, in the video below.

If the investigation uncovers activity that existing detections missed, the Attack Discovery skill presents a detection gap analysis showing what wasn’t covered. From there, it can draft an Elasticsearch Query Language (ES|QL) rule to close the gap. An analyst must review and explicitly approve the draft before the rule is created. No detection is added automatically.

Just as importantly, you can see how the investigation happened. Each run includes an Agent Builder conversation showing which skills were used, which alerts were investigated, and how the model reached its conclusion. If something goes wrong, before you consider opening a support case, the same agent can help explain where the run failed.

By the time an Attack Discovery reaches an analyst, much of the context gathering has already happened. The analyst can begin with a grounded attack narrative and focus on the decision that matters: what to do next, instead of jumping between alerts, entities, and raw logs. It gets analysts there faster, rather than replacing analyst judgment. That’s what moving closer to Alert Zero looks like for the hardest alerts in the queue.

Connect Attack Discovery to your existing SOC workflows

Most mature teams already have established playbooks and/or Elastic Workflows for tenant scoping, enrichment, escalation, cases, and more, so building toward Alert Zero doesn’t mean replacing the operating model that your SOC already trusts. The goal is to bring deeper investigation into those workflows, not force analysts to move their operations onto another product page.

This is what makes Attack Discovery an always-on part of the SOC. Schedule it to run as often as your team needs, or trigger it from a workflow, so investigations begin without waiting for an analyst. Your team still controls what happens next.

Elastic Workflows, generally available (GA) since 9.4, allows Attack Discovery to fit into that operating model. Many teams can begin with the skill-driven retrieval and default validation included with Attack Discovery, but teams with more complex requirements can connect custom retrieval or validation workflows to control how alerts are gathered, enriched, and approved. This might include translating output, checking indicators against VirusTotal, adding MITRE ATT\&CK context, or validating entities against other data in the environment.

You can also run the complete Attack Discovery pipeline as a step inside a workflow. That step retrieves alerts, generates discoveries, and validates the results before continuing through the rest of your playbook. Additional workflow steps let you manage alert and attack status, tags, and assignees from the canvas without writing Kibana requests by hand.

Once created, attacks become operational objects alongside alerts under Detections. Teams can search, filter, assign, tag, update, and add notes through the UI, APIs, or Workflows. If Attack Discovery surfaced an attack that looks suspicious to you as an experienced analyst, you can inspect why the pipeline trusted it. If it’s real, your team can manage the attack chain as the unit of work instead of returning to a wall of individual alerts.

The value goes beyond faster investigations. You can bring AI into your security operations without taking on a separate implementation project. Attack Discovery can live inside the playbooks that already page the right people, open the right cases, and drive the next response. That’s how Alert Zero becomes part of daily operations instead of another dashboard your team has to monitor.

Bring your own AI model to the agentic SOC

Moving toward Alert Zero requires trust. Teams need control over the models doing the work and over the decisions that those models are allowed to make.

Elastic lets you choose your model and provider, including local large language models (LLMs) for air-gapped and sovereign deployments. That means you can introduce AI-assisted triage and investigation without rebuilding your existing security, privacy, and governance programs around a vendor-selected model.

You also control the level of autonomy. Workflows and agent conversations remain inspectable, so your team can see what ran and what evidence was considered. The team can also see how the agent reached its conclusion. You decide what happens automatically and what requires approval. Plus, you decide what remains entirely human-driven.

A clear queue isn’t a success if nobody can explain how the work left it. Staged automation, inspectable agents, and human approval for higher-risk actions help teams move toward Alert Zero without replacing alert fatigue with unexplained decisions.

How to get started with AI-driven SOC alert triage

You don’t need to adopt every capability at once. Start with a part of the alert queue your team understands, keep the first runs visible, and introduce automation only after the output matches how your analysts make decisions today.

Start with alert classification, not auto-close

Choose a small set of well-understood detection rules. Enable Security alert analysis with notes and tags, but leave auto-close disabled. Review the classifications, confidence scores, and reasoning with the analysts who normally handle those alerts.

Test Attack Discovery against known alert activity

Run Attack Discovery on demand against an alert window that your team already knows. Have senior analysts compare the attack chains, supporting evidence, and discarded alerts with their own investigation. Adjust the scope until the results consistently provide a useful starting point.

Connect alert triage and investigation to existing workflows

Use the classifications and fields written by alert analysis to focus Attack Discovery on alerts that deserve deeper investigation. Add the Attack Discovery step to an existing enrichment or escalation playbook, while leaving cases, paging, and response processes where they already work.

Add automation autonomy gradually

Once the results are reliable, enable auto-close for high-confidence false positives one rule at a time. Schedule stable Attack Discovery scopes, and keep analyst approval in place for new detection drafts. Monitor true-positive escapes more closely than queue reduction.

Measure what changed for the analyst

Track how much of the queue still requires human review and how long it takes analysts to reach a decision. You should also track whether new detection rules reduce repeat work. The success metric here is the measurable time saved rebuilding context repeatedly on your team, thus allowing analysts to investigate real threats and focus on protecting your customers.

Analysts remain in control throughout the process. The goal is to let agents handle repeatable work and to give experts a better place to begin, not to automate every click.

What changes for SOC analysts when the alert queue is clear

The point of Alert Zero is the freedom and agency that your team can regain when the queue no longer controls the entire shift, rather than to reach a number and stay there, finding a new metric to chase.

Security alert analysis handles more of the predictable noise, and Attack Discovery gives the alerts that matter a deeper, evidence-backed investigation. And Workflows put those capabilities into the operating model that your SOC already trusts. Analysts remain responsible for the decisions that carry risk, but they no longer have to begin every investigation from scratch.

The best outcome is an SOC where experts have more time to hunt, improve detections, practice response, and stop real attacks, rather than an empty dashboard. Elastic Security 9.5 gives your team a real place to start and a practical path toward an agentic SOC where the queue no longer runs the day.

See the documentation for Attack Discovery and Elastic Workflows to get started, and try it on your deployment. Or start a free trial. Connect with us on Elastic's community Slack to share feedback or tell us what you’re building.

Recently, we introduced MCP Apps for Elastic, built on the open MCP Apps extension to the Model Context Protocol, that lets an MCP tool return an interactive UI alongside its text response, rendered inline in Claude Desktop, Claude.ai, VS Code Copilot, Cursor, or any compatible host. This post goes deep on the Elastic Security MCP App, We’ll go over six interactive dashboards covering the core SOC loop, from alert triage to closed case, without leaving the conversation.

Elastic already ships AI agents inside the platform: Attack Discovery and Agent Builder work natively with your security data in Kibana. But analysts and security engineers also spend time in Claude, VS Code, and Cursor, writing detection logic, researching threats, and increasingly triaging findings. The question isn't whether to use Elastic's built-in AI or external tools. It's whether the external tools can give you the same interactive, visual workflow you get in Kibana. That's what the Security MCP App solves.

Security operations are inherently visual and interactive. An analyst scans alerts grouped by host, expands a process tree, traces a parent-child chain, and drags a suspicious entity onto an investigation graph. That loop doesn't survive compression into text. The Elastic Security MCP App brings those surfaces into the AI conversation, so the answer is the workflow, not a summary of it.

Why the Elastic Security MCP App matters for the SOC

When an agent tells a SOC analyst, "There are 47 alerts on host-314, here's a summary," it hasn't done any work. It's just pointed at where the work starts. The actual work lives in the alert list, the process tree, the investigation graph, and the case file. You can't do it from a paragraph of text.

The security MCP App returns the workflow itself. The analyst prompts the agent, and the agent returns an interactive dashboard in the chat where the analyst can drill into alerts, run threat hunts, correlate attack chains, and open cases, without losing the thread of the conversation. Everything you do in the MCP App writes back to Elasticsearch and Kibana through the same APIs the product uses. From Cases, alerts, and findings to hunt queries; you lose none of this context because it does not just live in the chat, but it is all stored in your Elastic cluster and Kibana environments, waiting to be picked back up when you are ready.

Six interactive dashboards

We chose six elements that map to the core SOC loop: detect, triage, hunt, correlate, respond, and test. Each one is a React UI that renders inline when the agent calls the corresponding tool:

| Tool | What it does | Interactive UI | | :---- | :---- | :---- | | Alert Triage | Fetch, filter, and classify security alerts | Severity grouping, AI verdict cards, process tree, and network events | | Attack Discovery | AI-correlated attack chain analysis with on-demand generation | Attack narrative cards with confidence scoring, entity risk, and MITRE mapping | | Case Management | Create, search, and manage investigation cases | Case list with alerts, observables, comments tabs, and AI actions | | Detection Rules | Browse, tune, and manage detection rules | Rule browser with KQL search, query validation, and noisy-rule analysis | | Threat Hunt | ES|QL workbench with entity investigation | Query editor, clickable entities, and investigation graph | | Sample Data | Generate ECS security events for common attack scenarios | Scenario picker with four pre-built attack chains |

Each tool returns a compact text summary that the model can reason over, alongside the interactive UI the analyst acts on. The UI can also fetch fresh data behind the scenes through the MCP host bridge. The full tool model and bridge API live in the repo's architecture doc.

The app also ships with Claude Desktop skills, SKILL.md files that teach the agent when and how to use each tool. You can download the pre-built skill zips from the latest release.

From alert to case

The five skills cover the core SOC loop. Each one picks up a prompt, calls a tool, and returns an interactive dashboard alongside a text summary that the model reasons over. The walkthrough below starts from scratch; if you're following along, the first step populates the cluster so the rest of the loop has data to work with.

Generate sample data. Starting with a fresh cluster? The Sample Data skill generates realistic ECS security events for four common attack scenarios: ransomware, lateral movement, credential theft, and data exfiltration. Ask the agent to generate sample data, pick a scenario, and within seconds, you have a populated alert queue to work from. Everything that follows in this walkthrough uses these events.

Triage alerts. Ask the agent to triage by host, rule, user, or time window. The Alert Triage skill returns a dashboard of AI verdicts above the raw alert list, with one verdict per detection rule classifying that rule's activity as benign, suspicious, or malicious, each with a confidence score and a recommended action. Click any alert to open a detailed view with a process tree, network events, related alerts, and MITRE ATT\&CK tags. No tab switching between your AI tool and the alerts dashboard inside Kibana; everything happens in real-time inside the conversation.

Hunt for threats. Ask the agent to hunt across your indices. The Threat Hunt skill returns an ES|QL workbench with the query pre-populated and auto-executed, with every entity in the results clickable for drill-down. The model writes a short read-out below the table: what's unusual, what's connected, and what's worth a closer look. It then offers the next pivot: go deeper into the threat hunt, or hand off to another skill. Attack Discovery is the natural next step; it gathers more context on the alerts you've triaged and the threats you've hunted, correlating them into attack chains.

Run Attack Discovery. The Attack Discovery skill triggers the Attack Discovery API and returns a ranked list of findings. Each finding is a set of related alerts stitched into one attack chain, with MITRE tactics, a risk score, a confidence label, and the impacted hosts and users surfaced up front. The agent's summary lands below the findings in the same rank order, and the conversation now holds everything needed to act: hunt queries, triage decisions, correlated chains, all staged for the next step.

Open cases without leaving the chat. Approve findings in bulk or ask the agent to open cases for specific alerts. The Case Management skill creates one case per approved finding (source alerts attached, and MITRE tactics inherited from the attack chain) and renders the live case list inline. Click a case for its detail view, which includes a row of AI action buttons: Summarize case, Suggest next steps, Extract IOCs, and Generate timeline. Each one drops a structured prompt back into the chat, so the agent picks up the case context without needing a reintroduction. The agent's summary sits below the case list and covers the full IR queue, including the cases just opened and earlier findings that still need one.

Every step in this walkthrough runs the same loop: a prompt comes in, the skill picks it up, and the tool returns a compact text summary for the model to reason over, alongside an interactive UI that the analyst acts on. Chain the skills together, and they compose into an end-to-end SOC flow; hunt, triage, correlate, open cases, and drive the next pivot, all with the model carrying the session context across every step. Invoke any one on its own, and it's still the full dashboard, pointed at whatever slice of your data you name. Either way, the work accumulates inside the conversation; no tab switching, no copy-paste, no hand-offs.

One more skill rounds out the app: a detection-rule browser for tuning noisy rules, filtering by rule type, and flagging high-noise detections. A follow-up post will go deep on all six dashboards: investigation graph, attack-flow canvas, and end-to-end walkthrough.

Here’s the full walkthrough of this demo.

How Elastic's InfoSec team uses the Security MCP App

The MCP App's value compounds when the conversation has access to more than just Elastic Security. In a real SOC workflow, a single alert often leads to questions that span multiple systems: cases in Kibana, threads in Slack, issues in Jira, and cloud infrastructure logs. Traditionally, an analyst would pivot across each of those tools manually, assembling context one tab at a time.

With the Security MCP App connected alongside MCP servers for Slack, Jira, and cloud platforms, the agent can pull the full picture into one conversation: review a case and its attached alerts, cross-reference Slack channels for related outages or planned changes, check Jira for known issues, and compile a forensic summary covering root cause, actions already taken, and outstanding tasks, all before the analyst writes a single note. Once the analysis is reviewed and approved, the agent writes the findings back: a structured comment on the Kibana case, a summary posted to the relevant Slack channel, and alerts closed with context attached.

Cloud-based alerting benefits the same way. Strange activity in a cloud environment often turns out to be a known outage or an infrastructure change already under discussion in Slack or Jira. The agent can check those sources in seconds, correlate the context, and either close the alert with an explanation or escalate it with the full picture already attached.

The MCP App for Elastic Security bridges the gap between automated detection and manual hunting. By bringing our security data directly into a single interface within Claude Desktop, we surfaced 'silent' threats in under an hour — risks that didn't trigger standard alerts but required immediate action. It's a force multiplier for our analysts. — Mandy Andress, Chief Information Security Officer (CISO), Elastic

How it works

Each MCP App is a small Node.js server whose tools return both a compact text summary for the model and a React UI that the host renders inline. The server exposes two layers: model-facing tools the LLM calls (returning lightweight summaries for reasoning), and app-only tools the UI calls behind the scenes for interactivity, like expanding process trees or running ES|QL queries. Each view is a self-contained React app rendered in a sandboxed iframe. Because it's built on the open MCP App spec, the same server runs on any compatible host; see the repo's architecture doc for the full design

The agentic SOC, interactive

Two properties about this pattern are worth stating directly. First, the tool result is no longer the end of the work; it is the start of it: the conversation returns an interface you can act on, not a summary you have to act from. Second, this only works because Elasticsearch and Kibana already expose the security APIs. The MCP App is a thin interactive layer over the detection, investigation, and case management capabilities Elastic Security already ships.

Attack Discovery already powers the correlated findings view inside this app. Inside the stack, the same agentic pattern goes further: Elastic Workflows automate the deterministic steps (enrich entities, create cases, and isolate hosts), while Agent Builder reasons over the data and invokes those workflows as tools. The MCP App brings that same security surface into the external conversation; Workflows and Agent Builder deepen it inside the stack. Different entry points, same Elastic Security APIs underneath.

That architectural choice is deliberate. The MCP server runs on the analyst's own machine and connects directly to Elasticsearch using their API key. The LLM receives only compact summaries for reasoning, while the UI independently loads full investigation data through the same server. It adds a surface for analysts who already work in Claude, VS Code, or Cursor without introducing a dependency they have to adopt or a governance model they have to rebuild. The same role-based access controls you enforce through your Elasticsearch API keys apply to every action the app takes, which means the operational result is straightforward: analysts spend less time switching tools and more time closing cases.

Try the Elastic Security MCP App

The Elastic Security MCP App requires Elasticsearch 9.x with Security enabled, plus Kibana for cases, rules, and Attack Discovery. The fastest path is the one-click .mcpb bundle from the latest release; double-click it in Claude Desktop, and you'll be prompted for your Elasticsearch URL and API key. Setup guides for Cursor, VS Code, Claude Code, Claude.ai, and building from source are in the repo.

Don't have an Elasticsearch cluster yet? Start a free Elastic Cloud trial. For more on the building blocks behind the app, see the related Security Labs posts on Elastic Workflows and Agent Builder, Agent Skills, and Attack Discovery.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.