Dhrumil Patel - Elastic Security Labs

Benchmarking the Agentic SOC: How we evaluate LLMs for security workflows

Dhrumil Patel — Tue, 04 Aug 2026 21:59:59 GMT

An agentic SOC is only as good as the model driving it. The moment you let an LLM triage an alert, hunt across your telemetry, or author a detection rule, the question stops being "is this a smart model?" and becomes something much more specific: will it pick the right skill, call the right tool in the right order, and reach the right disposition without inventing a result it never actually checked?

That is not a question a general-purpose leaderboard can answer. A model can top every public benchmark and still confidently tell you a malicious loader is "clean" because it narrated a VirusTotal verdict instead of calling VirusTotal. In a SOC, that is not a rounding error. That is a missed intrusion.

So we built an evaluation framework to answer the question directly. It seeds a realistic intrusion into a live Elastic deployment, drives every available model through the same set of security tasks against the same agent, captures not just what each model said but every tool it called and every parameter it passed, and then judges the results blind. This post explains how it works and why we built it the way we did. The results themselves are published and continuously updated in the Large language model performance matrix for Elastic Security.

Why generic LLM benchmarks fail for agents for security

Public leaderboards measure knowledge and chat quality. They ask a model to recall facts, solve a puzzle, or write a tidy paragraph. Those are real capabilities, but they are the wrong proxy for agentic security work.

Inside an agent, the model is not writing prose. It is making decisions:

Which skill does this task need? Alert triage and entity risk-scoring are different jobs with different tools.
Which tool, with which parameters, in which order? A hash goes to VirusTotal; an on-call question goes to the schedule; a case gets opened once, with the right fields.
Is the output grounded? Did the model actually run the query and read the result, or did it produce a plausible answer with an empty trace?

The most dangerous failure mode in an agentic SOC is the confident, fluent, wrong answer that was never grounded in a tool call. Generic benchmarks reward exactly that, because they only see the final text. To evaluate a SOC agent honestly, you have to grade the work, not the writing.

What we actually need to measure

We anchored the evaluation on the concrete capabilities a security analyst relies on, most of them built-in Agent Builder skills we shipped in Elastic Security. (For the product side of that story, see our companion post on the five Agent Builder skills in Elastic Security.) That gives us seven capability categories:

These categories deliberately straddle two levels of the agent. Alert analysis, entity analytics, threat hunting, and detection rules are built-in Agent Builder skills; workflow authoring exercises the platform workflow capability; and triggering workflows and multi-step response exercise the custom tools and the model's ability to chain them. So the suite measures both things that matter: whether the model routes to the right skill, and whether it then selects and orders the right tools.

Alongside the agent suite, we run two parallel evaluations that apply the same philosophy to different tasks. One is Attack Discovery, which uses an LLM to correlate raw alerts into coherent attack narratives. The other is Automatic Migration, which uses an LLM to translate detection content from another SIEM (Splunk, QRadar, or Microsoft Sentinel) into Elastic rules. Each has its own answer key, so we grade them separately.

The framework, end to end

The whole system is one automated flow. Seed the right data, point every model at the same agent and the same prompts, capture the full trace of what each model did, then anonymize and judge.

The design principle throughout: hold everything constant except the model. Same agent, same skills and tools, same data, same prompts. The only variable that changes between runs is which model is answering. That is what makes the comparison fair.

Seeding a realistic range

You cannot benchmark an investigation without something to investigate. Real product telemetry is noisy, sensitive, and non-reproducible, so we generate a synthetic intrusion instead.

The scenario is the Chrysalis backdoor campaign we detailed in our earlier Attack Discovery post: a DLL side-loading attack on a Windows host, srv-win-defend-01, where a legitimate-looking BluetoothService.exe loads a malicious log.dll. A simulator seeds the alerts, endpoint telemetry, threat-intel documents, and an on-call schedule that make the scenario coherent enough for an agent to actually work through.

One methodology detail matters here. The "malicious loader" in the scenario carries the EICAR test file hash. EICAR is the industry-standard harmless test string that every antivirus engine flags as malicious by design. Using it as the stand-in loader means VirusTotal returns a stable, unambiguous "malicious" verdict on every run, we never touch real malware, and the ground truth never drifts. A correct model reports "malicious, flagged by many engines." A model that says "clean" or never calls VirusTotal is wrong, deterministically.

There is a second dataset in play, a set of eight independent detection episodes producing roughly 95 alerts, which we use as the ground truth for Attack Discovery. And this is where the most important operational rule lives:

The two suites need different, mutually exclusive alert data. Attack Discovery runs against the clean episodes-only index, because its answer key assumes exactly those threats are present. Agent Builder runs with the Chrysalis intrusion seeded on top, because its prompts reference Chrysalis entities. Mix them, and both answer keys become meaningless.

Getting this wrong does not throw an error. It silently corrupts the results. So the harness treats the index state as a first-class step: prep the correct data, print the alert counts, and pause for an explicit go-ahead before a single model request is sent.

The agent under test

Every model drives the same agent: the full Elastic AI Agent, with all of Elastic Security's built-in skills enabled (alert analysis, threat hunting, entity analytics, detection-rule editing, and more), extended with five custom, workflow-backed tools from the Chrysalis scenario. Skills and tools sit side by side on the agent. The built-in skills carry the investigative capabilities, and each one, when the model reaches for it, unlocks its own underlying tools. The five custom tools below bolt on the response actions the scenario needs:

These are live tools hitting live systems, including a real Slack connector. When a model decides to open a case or spin up an incident channel, it actually happens. That is deliberate: we want to measure what the model does when the tools are real and the side effects are real, not whether it can describe calling them.

Because those side effects accumulate, the harness cleans up after every call. Authored validation workflows are deleted, and any Slack channels the agent created are archived through the same connector the agent used. Cases are intentionally kept for later inspection.

The agent is given a two-phase playbook in its instructions. First a confirmation phase: verify the hash on VirusTotal, hunt the logs for corroborating activity, ground the finding in research, and reach a verdict. Then a response phase, entered only when the threat is confirmed: get the time, find the on-call responder, open a case, and spin up an incident channel. It is explicitly told not to open cases or channels for benign or low-confidence findings unless asked. That structure gives every model the same operating procedure, so what we are measuring is how well each one executes it, not whether it happened to guess the workflow.

The model routing is the elegant part. Every model on the deployment is exposed as an inference connector, and the converse API takes a connector_id per call. So swapping models is a one-field change. The agent, its tools, its instructions, and the data underneath it never move.

The prompt matrix

The suite is 21 prompts: three variants for each of the seven capabilities, all revolving around the same Chrysalis incident so the run reads like one coherent investigation rather than disconnected trivia. Prompts are written the way an analyst actually talks, and some carry attachments, the latest alert document or a detection rule to edit, so the model has real context to work from.

The three variants per capability are not just repetition. They escalate the difficulty in a deliberate way:

Variant A is the clear single-skill ask. The task names what it wants, and there is one obviously right tool for the job.
Variant B is realistic. It reads like a real analyst request, with enough context to be actionable but no explicit instruction on which tool to reach for.
Variant C is ambiguous, routing under pressure. It is underspecified or slightly misleading, so the model has to infer intent and still pick the right capability. This is where weaker models overreach or grab the wrong tool.

To make the escalation concrete, here is one capability, alert analysis, across all three variants:

A (clear): "Take a look at this alert and tell me what's going on. Is it something I should worry about, and what's your recommended disposition?" (latest alert attached)
B (realistic): "We've got alerts firing on srv-win-defend-01. Triage what's in the alert queue for that host, are these related to the same incident, and which entities do they share?"
C (ambiguous): "I'm seeing noise on srv-win-defend-01. Is this a real threat or a false positive? Pull in any threat intel that would help me decide."

Same capability, escalating difficulty: A names the task and the right tool is obvious, B forces the model to infer intent from context, and C is underspecified and slightly misleading, so the model has to resist the "false positive" framing and still investigate.

A few representative prompts across the other capabilities:

Threat hunting: "Hunt for signs of the Chrysalis backdoor on srv-win-defend-01. Look for BluetoothService.exe execution, suspicious DLL loads, and any C2 network or DNS activity. Walk me through what you discover."
Triggering workflows: "The Chrysalis loader hash is \. Check this hash against VirusTotal and tell me the verdict, how many engines flagged it and what threat name."
Multi-step: "There's a confirmed Chrysalis incident on srv-win-defend-01. Verify the loader hash on VirusTotal, check the on-call schedule, open a critical Security case, then spin up a Slack incident channel with the on-call responder and post the case summary and top IOCs."

The multi-step prompts are where models separate. They require ordering, carrying a finding from one step into the next, and knowing when not to act. One variant explicitly says "don't escalate if it's benign," which tests judgment: since the scenario is a true positive, the correct behavior is to escalate, and a model that bails out has misread the evidence.

What a single LLM evaluation run looks like

Before we scale to every model, it helps to watch a single prompt run end to end. The harness dispatches the prompt to the converse API, the agent routes to the right skill, and from there the work is real. It verifies the loader hash on VirusTotal, generates and runs an ES|QL hunt that turns up the corroborating events, checks the on-call schedule and resolves the responder in Slack, opens a critical case, and spins up an incident channel with the verdict and the top IOCs. Then the harness verifies the side effects and archives the channel it created. Every step, every tool call, every parameter and result, is captured as it happens.

That is one prompt. A full sweep is 21 prompts against every model in the catalog, more than 500 evaluated conversations, each one recorded in full.

Capturing tool traces, tokens and latency in agent workflows

This is the part that makes the framework more than a chatbot bake-off. For every single call, we capture the final answer and the full execution trace: the ordered steps the agent took, each reasoning turn, each tool it invoked with the exact parameters, the tool's result, plus token usage, latency, and the conversation and round identifiers. When a task routes through a built-in skill, the trace shows the model loading that skill first and then calling the tools the skill unlocks; when it uses a custom tool like vt.hash.lookup, the call shows up directly. Either way, the tool calls are the evidence.

Here is a real captured step from a triggering-workflows prompt, trimmed for length. The model was asked to verify the loader hash on VirusTotal:

{
  "steps": [
    {
      "type": "reasoning",
      "reasoning": "The user provided a file hash for the 'Chrysalis loader' and requested a VirusTotal verdict, including the number of flagging engines and the threat name. I will use the vt_hash_lookup tool to retrieve this."
    },
    {
      "type": "tool_call",
      "tool_id": "vt.hash.lookup",
      "params": { "hash": "275a021b...fd0f" },
      "results": [
        { "last_analysis_stats": { "malicious": 65, "undetected": 3 } }
      ]
    }
  ],
  "response": {
    "message": "The hash was flagged by 65 engines on VirusTotal..."
  }
}

That trace is the evidence. It lets us answer the questions a final answer alone cannot:

Did the model actually call vt.hash.lookup, or did it assert a verdict with no tool call? (If the latter, the answer is unsubstantiated, no matter how confident.)
Did it use the purpose-built entity tools, or fall back to a generic search and invent a risk score?
For threat hunting, is there an executed query in the trace, or just a claim of findings?

For workflow authoring, we go one step further and capture objective ground truth. When a model writes a workflow, the harness actually creates it, enables it, runs it, and polls the execution to a terminal status. The result is not a judgment call about whether the YAML "looks right." It either validated and executed against the live system or it did not.

Blind LLM evaluation: how we remove model bias from scoring

Once the matrix has run, every model has produced 21 traces. Scoring them by hand, knowing which vendor produced which output, is a recipe for bias. So we anonymize first.

A deterministic obfuscation step strips the model names and relabels everything Model A, Model B, Model C, and so on, consistently across every report and across both suites, so the same model wears the same label everywhere. It also scrubs identity giveaways out of the traces themselves, the connector ids and slugified vendor names that leak into things like workflow tags, while leaving legitimate vendor mentions in tool output intact. With more than two dozen models in a run, the judge, whether a human or an LLM, sees only the labels and the traces.

The judging rubric grades every capability on a 1 to 10 scale and weighs two things at once:

Answer quality: correctness against the ground-truth answer key, soundness of the disposition, depth, and actionability.
Tool and skill selection: did the model call and use the right tool for the job, in a reasonable order, without a pile of irrelevant calls or fabricated results?

And the rule that keeps the whole thing honest:

No tool call, no credit. A plausible answer produced without the supporting tool calls the task required is capped at 6 out of 10, because the result is unsubstantiated. A confident wrong answer scores lower than a hedged correct one. Evidence over eloquence.

Reliability is tracked separately from quality. Some attempts error out or time out; those are counted as reliability failures and excluded from the quality average rather than being silently folded in. A model that is brilliant when it works but fails a third of the time is a different proposition from one that is merely good but never falls over, and the report shows both.

What this surfaces that leaderboards miss

Because we grade the trace and not the prose, the framework consistently surfaces failure modes that a text-only benchmark would score as passing:

Fabricated verdicts. A model asserts a hash is malicious, or benign, without ever calling VirusTotal. Fluent, confident, and unsubstantiated.
Skipping purpose-built tools. For entity questions, a model leans on a generic search and invents a risk score instead of calling the entity lookups that would return the real one.
Workflows that do not run. Authored YAML that reads perfectly but fails validation or execution against the live system. The prose was fine; the automation was broken.
Reasoning strong, tool use weak. Some models narrate an excellent investigation plan and then do not execute it. Others quietly do exactly the right thing with minimal commentary. Only the trace tells them apart.

The headline finding is not "model X wins." It is that ranking flips depending on the capability. A model that is excellent at open-ended threat-hunting reasoning can be middling at the disciplined tool selection that multi-step response demands. The right model for an agentic SOC is a per-capability decision, and this framework is what lets you make it with evidence instead of vibes.

Evaluating Attack Discovery: how LLMs correlate alerts into attack narratives

The Attack Discovery suite runs the same philosophy on a different task. Attack Discovery has no tools; the model works purely from the alert context it is handed. Every model gets the identical clean corpus of roughly 95 alerts, which we constructed to contain exactly eight independent intrusions, one per host, spanning macOS, Windows, and Linux and built from real, publicly documented malware families. That number, eight, is the single most important figure in the evaluation. A top-tier model produces eight clean discoveries. Weaker ones surface a fraction of them, merge distinct intrusions into one blurry narrative, or over-split a single attack into several.

We grade the output on four axes, each on the same 1 to 10 scale:

Coverage: how completely the eight intrusions are accounted for, penalizing both misses and threats hidden by merging.
Accuracy: correct host, malware family, kill chain, and MITRE mapping, with fabrication penalized hard.
Correlation quality: the right alerts grouped together, without merging separate intrusions or over-splitting one.
Actionability: usable titles and summaries, a correct entity picture, and sensible risk prioritization.

The guiding principle is that a clean, accurate eight beats a noisy twelve. Surfacing extra "discoveries" that are really fragments of the same attack is not thoroughness, it is noise an analyst has to untangle. As with the agent suite, latency is reported as a secondary signal and never folded into quality, because correlation speed matters operationally when Attack Discovery runs on a schedule, but a fast wrong answer is still wrong.

Evaluating Automatic Migration: Using LLMs to Port Detections from Other SIEMs to Elastic

The third suite leaves the agent behind entirely and evaluates a different LLM-powered capability: Automatic Migration, the feature that ports detection content from other SIEMs into Elastic such as Splunk, QRadar, and, as of 9.5 release, Microsoft Sentinel. Here the model is not calling tools in a loop, it is doing a bulk translation job, and we grade it on how faithfully it lands. We evaluated it on a Splunk package for this run; the same method applies to any supported source.

The input used are real Splunk detection rules: 52 saved searches built on Sysmon and Windows event telemetry, spanning credential access, defense evasion, discovery, and persistence. Every model migrates the identical package, so the comparison is apples to apples. The wrinkle that makes this hard is macros. Splunk searches lean on reusable macros, and 33 of the 52 rules are macro-only, meaning their entire detection logic lives behind a single macro reference like sysmon_detect_dcsync_execution rather than in the search text itself. So we hand the feature both files it needs, the 52 searches and the 200 macro definitions they depend on, and a faithful migration has to resolve that nesting instead of translating the surface text.

Scoring is deliberately simple and objective. Each of the 52 rules earns a score based on translation fidelity:

Sum the per-rule points, divide by 52, and multiply by 10 to land on the same 1 to 10 scale as the other suites. The result is a single, legible number for a genuinely messy task: what fraction of a real customer's detection library would survive an automated migration, and how much of it would land clean versus need an analyst's rework.

Key takeaways

Grade the work, not the writing. In an agentic SOC, the tool trace is the evidence. Judging final text alone rewards the most dangerous failure mode there is: the confident, ungrounded answer.
Realistic data plus ground truth is non-negotiable. A reproducible synthetic intrusion with a known answer key, and strict discipline about which dataset backs which suite, is what makes the results mean anything.
Hold everything constant except the model. Same agent, same skills and tools, same prompts, one-field model routing. Fairness comes from the setup, not the scoring.
Capture the whole trace. Steps, tool calls, parameters, results, tokens, latency, and objective workflow validation. You cannot diagnose a failure you did not record.
Judge blind, and separate reliability from quality. Anonymize before scoring, cap unsubstantiated answers, and never average a model's crashes into its quality score.
The best model is per-capability. Rankings flip across alert triage, hunting, rule authoring, and multi-step response. Evaluate for the job you are actually asking the model to do.

Conclusion: Why evidence-based LLM evaluation matters for security use-cases

Three suites, three very different jobs, one standard of evidence. The agent suite measures whether a model can route to the right skill and drive the right tools in the right order. Attack Discovery measures whether it can turn a wall of alerts into the true set of intrusions, no more and no fewer. Automatic Migration measures whether it can faithfully port a detection library it did not write. Because all three land on the same blind-judged, 1 to 10 scale, every new model that ships gets a complete security profile in one view: where it is strong, where it fails, and whether those failures are quality or reliability.

That evidence is not academic. It is how we decide which models to put in front of security teams, and how we keep re-checking that decision as the model landscape shifts. The agentic SOC is only as trustworthy as the evidence behind the model you put in it. This framework is how we generate that evidence, so that when we say a model is ready to triage your alerts, we can show our work, and we keep the current results live in the Large language model performance matrix for Elastic Security.

One agent, the right skills: Elastic Security 9.4 brings domain expertise on demand to every SOC workflow

Dhrumil Patel — Mon, 04 May 2026 00:00:00 GMT

Three things land on you at once: Attack Discovery correlated 12 alerts into a credential-harvesting campaign overnight, your team just onboarded a new fleet of macOS endpoints and needs detection rules for LOLBin abuse, and a risk score spike on a service account just crossed the critical threshold.

In most security operations centers (SOCs), that's three different people, three different workflows, and a morning spent context-switching. In Elastic Security 9.4, it's one conversation.

You open the Elastic AI Agent and start working. The agent doesn't try to handle everything with one giant prompt. Instead, it activates the right skill for each task, loading specialized instructions, selected tools, and domain context only when needed. Detection Rule Edit writes your Elasticsearch Query Language (ES|QL) rule. Alert Analysis triages the campaign. Threat Hunting chases the service account. Each skill focuses on one job. Together, they cover the full pipeline.

In this article, we'll walk through the architecture, what each skill does, and how they work together in real scenarios.

The problem: AI assistants that know a little about everything

Most AI assistants are monolithic. One system prompt tries to cover detection, investigation, response, entity analysis, and threat hunting all at once. This creates two problems that compound as capabilities grow.

Context window dilution. Every instruction, every tool description, every example takes up tokens. When the prompt tries to cover every SOC workflow, the model has less room for the actual data it needs to reason about: your alerts, your entities, your logs. As you add more capabilities, the quality of each one degrades.

Jack-of-all-trades performance. A prompt that covers everything handles nothing with depth. Ask it to write a detection rule, and it produces something generic. Ask it to investigate an entity, and it misses the nuance of the risk score composition. The model knows a little about many things but lacks the specialized knowledge that makes the output useful.

The industry response has been to build separate agents for separate tasks: a detection agent, a hunting agent, a triage agent. But that fragments the experience. Analysts have to know which agent to use, switch between them, and manually pass context from one to another. The AI becomes a tool-switching exercise rather than a productivity gain.

We needed an architecture that scales to dozens of capabilities without diluting any of them, and without forcing analysts to manage multiple agents.

The solution: Skills

Skills are a well-established pattern in AI agent architecture, a way to give a generalist model specialized capabilities on demand. In our implementation, a skill is a package of three things: a system prompt tuned for a specific SOC workflow, a curated set of tools selected for the task, and referenced domain content. The concept isn't new. What's new is applying it to security operations with depth: Each skill encodes the reasoning patterns, query templates, and domain knowledge that experienced analysts use daily.

The architecture rests on three ideas.

Each skill does one job well. The Threat Hunting skill knows how to formulate hypotheses, iterate on ES|QL queries, identify anomalies, and document findings. It doesn't know how to edit detection rules. That's not a limitation; it's the point. Because each skill focuses on a single intent, it can include richer instructions, better examples, and more precise tool configurations than a monolithic prompt ever could.

Skills work together. When Alert Analysis encounters a high-risk entity, it references the Entity Analytics skill for deeper profiling. When Threat Hunting finds a suspicious binary, it can hand off to the detection pipeline. Multi-step investigations happen without requiring the analyst to orchestrate each handoff.

Nothing loads until it's needed. Skills activate on demand, not all at once. The agent's context window stays lean as the total number of capabilities grows. You can add a new skill without degrading any existing one, because each operates in its own focused context.

At a glance, the following image shows a skill in action:

Five skills for the security operations pipeline

Elastic Security 9.4 ships five skills that span the core SOC workflows: detection, triage, hunting, entity analysis, and anomaly investigation.

| Skill | Domain | What it does | Example prompt | |------|--------|--------------|----------------| | Detection Rule Edit | Detection engineering | Creates and edits detection rules from natural language, maps to MITRE ATT&CK, validates queries | Write a rule to detect DLL sideloading via unsigned DLLs loaded by signed binaries. | | Alert Analysis | Alert triage | Triages alerts, finds related alerts by shared entities, enriches with threat intelligence and risk scores | Analyze alert 82a1f, is this related to the credential-harvesting campaign? | | Threat Hunting | Proactive hunting | Runs hypothesis-driven hunts with iterative querying, embedded query templates for common tactics, techniques, and procedures (TTPs) | Hunt for lateral movement from the compromised host in the last 7 days. | | Entity Analytics | Entity investigation | Profiles entities from the Entity Store: risk scores, behaviors, asset criticality, relationships | Show me the riskiest users this week and what's driving their scores. | | Security ML Jobs | Anomaly investigation | Investigates anomalies from Security ML jobs, correlates with entity context | What anomalies are associated with svc-backup-prod? |

Three scenarios show how these skills work in practice.

Scenario 1: Writing a detection rule for macOS LOLBin abuse

Your team just onboarded a fleet of macOS endpoints. You have solid detection coverage for Windows living-off-the-land binaries but almost nothing for macOS equivalents. Attackers routinely abuse built-in macOS utilities, like osascript, curl, openssl, and sqlite3, to execute payloads, exfiltrate data, and access credential stores without triggering basic malware detection. You need rules for these, and you need them before the next red team exercise.

You open the Elastic AI Agent and type: Create an ES|QL detection rule for macOS LOLBin abuse. Look for suspicious use of built-in macOS utilities, like osascript, curl, openssl, and sqlite3, being spawned by unexpected parent processes.

The Detection Rule Edit skill activates:

The skill uses platform.core.generate_esqlto draft an ES|QL query targeting logs-endpoint.events.process-*, filtering for known macOS LOLBins spawned by unusual parent processes (for example, osascript launched by a web browser, or url invoked by a shell script running from /tmp).
It maps the rule to MITRE ATT\&CK: T1059.002, AppleScript, and T1105, Ingress Tool Transfer under the Execution and Command and Control tactics.
The skill calls security.security_labs_search to check whether Elastic Security Labs has published research on macOS LOLBin techniques, pulling relevant context into the rule's investigation guide.
It generates the complete rule definition (name, description, severity, risk score, tags, MITRE mapping, schedule, and the validated ES|QL query) and presents it as an editable rule attachment in the conversation.

You review the query, tune the parent-process allow list to exclude your IT team's legitimate automation scripts, and save. The rule is live. Total time: under five minutes.

Without the skill, this process means switching to the detection rules UI, manually writing ES|QL against the correct indices, researching which macOS utilities qualify as LOLBins, looking up the right MITRE technique IDs, and hoping you haven't missed an edge case. That's 30–60 minutes for an experienced detection engineer, longer for someone less familiar with the macOS process hierarchy.

Scenario 2: Attack Discovery surfaces a campaign

Overnight, Attack Discovery correlated 12 alerts across three hosts and two users into a single narrative: Credential harvesting via browser credential store access and suspicious authentication patterns. The discovery is sitting in your queue when you arrive.

You click into the agent and ask: Analyze the credential-harvesting discovery. Are these alerts true positives? What's the blast radius?

Alert Analysis goes first. It fetches the correlated alerts using security.alerts, pulling the full alert details: rule names, severities, MITRE techniques, affected entities. Then it uses its inline tool security.alert-analysis.get-related-alerts to find additional alerts sharing entities with the correlated set. It discovers four additional alerts involving the same user (j.martinez) from the past 48 hours, alerts that weren't part of the credential-harvesting campaign pattern but are relevant to the broader investigation of this user's activity. These are failed authentication attempts against a different service, suggesting the attacker is testing stolen credentials across systems.

Next, it queries security.security_labs_search to check whether the observed TTPs match known threat actor playbooks. It finds a match: The technique chain (credential store access → lateral authentication → service enumeration) aligns with a published Elastic Security Labs report on a commodity access broker toolkit.

Finally, it calls security.entity_risk_score to assess the involved entities. j.martinez has a risk score of 87 (critical), already elevated before this campaign due to prior anomalous VPN activity.

The triage is done: true positive, high confidence, expanding blast radius. But you want deeper entity context. What else has j.martinez been doing?

The Entity Analytics skill picks up. Using security.get_entity, it pulls the full entity profile: risk score history over 90 days, contributing risk inputs (the current campaign plus two prior anomaly detections), asset criticality (the account has admin access to three production databases), and behavioral patterns. The profile shows that `j.martinez's risk score has increased by 34 points in the last week, well above the significant-change threshold.

You now have the full picture: confirmed campaign, expanding scope, high-value target, and historical context. You ask the agent to create a case with all findings attached. It compiles alert evidence, entity profile, threat intel matches, and recommended containment actions into a single case.

Scenario 3: An anomaly leads to a hunt

While reviewing the morning's anomalies, the Security ML jobs flagged unusual behavior on svc-backup-prod, a service account that normally runs scheduled backup jobs between 2:00 and 4:00 a.m. The anomaly: large outbound data transfers at 11:00 p.m., well outside the normal window, to an IP address the account has never contacted before.

You ask: Investigate the anomalies on svc-backup-prod. What's happening?

The Security ML Jobs skill starts by calling find.security.ml.jobs to find the relevant ML jobs and anomaly indices, in this case jobs monitoring network traffic patterns and data exfiltration signals. It generates and executes an ES|QL query against `.ml-anomalies-*, filtering forsvc-backup-prod` records above the anomaly score threshold. The results show three anomalous sessions over the past week, each with increasing data volume: 2 GB, then 8 GB, and then 23 GB.

Since Entity Store v2 is enabled, the skill extracts the entity's unique identifier and calls security.get_entity to pull the full entity profile. It reveals that svc-backup-prod was recently granted access to a new file share containing customer PII, and its asset criticality is classified as extreme_impact.

The anomaly data is concerning, but you need to dig deeper. You type: Hunt for all network activity from svc-backup-prod to external IPs in the last 30 days. Compare against baseline.

The Threat Hunting skill takes over. Using platform.core.generate_esql and platform.core.execute_esql, it iteratively builds queries against logs-endpoint.events.network-*:

First pass: Aggregate all outbound connections by destination IP, ordered by total bytes transferred. The results confirm that the flagged IP (198.51.100.47) accounts for 33 GB of outbound traffic, all within the past 10 days. None before that.
Second pass: Check the destination IP against DNS resolution patterns. The IP resolves to a recently registered domain (storage-sync-cdn.cloud) with a registrar commonly associated with bulletproof hosting.
Third pass: Correlate with process telemetry. The connections originate from a process (rsync) that svc-backup-prod normally uses, but it's connecting to an unauthorized destination. The attacker is using a legitimate tool for exfiltration, making rule-based detection difficult.

The hunt confirms a data exfiltration campaign using living-off-the-land techniques. The Threat Hunting skill documents the hypothesis, queries, and evidence trail. You create a case with containment recommendations: Isolate the host, rotate the service account credentials, and block the destination IP at the network perimeter.

Three skills. One conversation. From anomaly to confirmed exfiltration in minutes, not hours.

Under the hood: How skills are built

Each skill is defined as a SkillType, a structured object that bundles everything the agent needs for a specific domain:

System prompt (content): The core instructions. This is where domain expertise lives. The Threat Hunting skill, for example, includes a complete hunting process (formulate hypothesis → identify data sources → explore iteratively → identify anomalies → search for IOCs → document findings) with embedded ES|QL templates for common patterns, like lateral movement detection and C2 beaconing analysis.
Registry tools (getRegistryTools): The set of platform and security tools the skill can invoke. Each skill gets only the tools it needs. Alert Analysis gets security.alerts, security.security_labs_search, and security.entity_risk_score. Threat Hunting gets platform.core.generate_esql, platform.core.execute_esql, platform.core.search, and platform.core.cases. No skill has access to tools it doesn't need.
Inline tools (getInlineTools): Skill-specific tools that only exist within that skill's context. Alert Analysis defines security.alert-analysis.get-related-alerts, a tool that finds alerts sharing entities with a given alert. This tool doesn't exist outside the Alert Analysis skill because no other workflow needs it.
Referenced content (referencedContent): Named chunks of domain knowledge that the skill can pull in when needed. The Threat Hunting skill includes embedded ES|QL query templates for lateral movement, C2 beaconing, brute force detection, and rare process execution. These are ready-made patterns that the agent adapts to the specific investigation.

Because each skill is self-contained, adding a new one (for incident response automation or binary analysis, say) doesn't touch any existing skill. Each operates independently, with its own prompt, its own tools, and its own domain knowledge

Skills in the Agentic SOC

If you read our previous post on Attack Discovery, Workflows, and Elastic Agent Builder, you'll recognize the pattern. In that post, we extended the Threat Hunting Agent with five custom workflow tools (VirusTotal lookups, on-call schedule checks, case creation, Slack channel creation, and time retrieval) to build an automated triage pipeline for advanced persistent threat–level (APT-level) threats.

Skills are the productized evolution of that approach. Instead of requiring each SOC team to build custom agents and wire up individual tools, Elastic Security now ships domain expertise out of the box. The five skills in 9.4 cover the workflows that every SOC runs daily (detection, triage, hunting, entity analysis, and anomaly investigation) with the same composable, tool-backed architecture.

Skills also integrate directly with the rest of the Agentic SOC stack:

Attack Discovery generates alerts that can trigger Workflows, which invoke the agent. The agent activates Alert Analysis, Entity Analytics, or Threat Hunting, depending on what the discovery requires.
Workflows provide the execution layer, both scripted automation and AI-augmented reasoning. A Workflow can run deterministic actions, like case creation, host isolation, and notification, but it can also invoke the Elastic AI Agent as a step, triggering skill-based reasoning mid-pipeline. This means a single Workflow can isolate a host (scripted), then ask the agent to triage the related alerts using Alert Analysis (AI-driven), and then escalate to Slack (scripted), combining reliability with intelligence.
Custom tools and Model Context Protocol (MCP) remain fully available. Skills don't replace customization. They complement it. Teams can still add workflow-backed tools, connect external MCP servers, and extend the agent for their environment-specific needs.

Security users also benefit from three platform skills that ship alongside the security-specific ones.

Dashboard Management lets analysts build and update Kibana dashboards through conversation. After completing the exfiltration investigation in Scenario 3, you could ask the agent: Create a dashboard showing outbound data transfer volume by service account over the last 30 days, with a breakdown by destination IP. The skill generates the visualizations and presents them as an editable attachment, so you go from investigation findings to a shareable executive briefing without switching tools.
Workflow Authoring (available as an experimental capability) helps teams write and modify workflow YAML through the agent. Instead of hand-authoring a triage Workflow from scratch, you could ask: Create a workflow that triggers on critical-severity alerts, runs the alert through the AI agent for triage, and creates a Slack channel if it's confirmed as a true positive. The skill generates the YAML definition, validates it, and lets you review before deploying. This turns Workflow creation from a manual authoring task into a conversation.
Graph Creation lets analysts visualize entity relationships and attack paths through conversation. After the Alert Analysis skill identifies that j.martinez's compromised credentials were used across three hosts, you could ask: Create a graph showing the relationship between j.martinez, the affected hosts, and the credential-harvesting alerts. The skill generates an interactive node-link visualization showing how entities connect, making it easier to brief stakeholders on attack scope and lateral movement paths.

The pieces form a layered system: Attack Discovery surfaces threats, skills provide domain expertise for analysis, Workflows execute the response, and platform skills help you build the dashboards, graphic representation, and automation that tie it all together.

Key takeaways

Skills are the unit of AI expertise in the SOC. Each skill packages domain knowledge, curated tools, and specialized instructions for a single workflow: detection, triage, hunting, entity analysis, or anomaly investigation.
One agent, not five. Analysts don't switch between agents. The Elastic AI Agent activates the right skill based on the task, keeping the experience unified and the context connected.
Composable by design. Skills reference each other. Alert Analysis hands off to Entity Analytics for deeper profiling. Threat Hunting builds on ML anomaly findings. Investigations flow naturally across skills without manual context transfer.
Efficient at scale. Skills load on demand. Adding new skills doesn't degrade existing ones. Each operates in its own focused context window, so quality improves as capabilities grow.
Built on the Agentic SOC stack. Skills work with Attack Discovery, Workflows, and custom tools. They make the automation pipeline richer by giving the agent deeper domain expertise at every step.
Extensible. The five out-of-the-box skills ship with 9.4, but the architecture supports custom skills. Teams can build skills tailored to their environment, their data sources, and their SOC processes.

Get started

Skills ship as part of Elastic Security 9.4. They're available out of the box in the Elastic AI Agent with no configuration required. Open a conversation, ask a security question, and the agent activates the right skill.

To learn more, see the Elastic AI Agent documentation and the Elastic Security 9.4 release notes.

Speeding APT Attack Confirmation with Attack Discovery, Workflows, and Agent Builder

James Spiteri,Dhrumil Patel — Wed, 18 Feb 2026 00:00:00 GMT

9:15 AM: The Non-Event - A headline breaks: "Chrysalis Backdoor: A Deep Dive into Lotus Blossom." Your CISO sends a Slack message: "Are we affected?"

In a traditional SOC, you’re about to lose your entire morning to a manual scramble - sifting through dozens of alerts, writing queries, manually checking VirusTotal, and pivoting across index patterns to build a timeline hoping you don’t miss something.

But in an Agentic SOC, the work is already done. Attack Discovery, running on its hourly schedule, had already correlated 5 critical alerts out of 30+ into a single attack narrative: "Malware with DLL Side-Loading Persistence." That discovery automatically triggered a workflow, which handed the findings to an agent. The agent used its tools and verified the malware hash on VirusTotal, searched your logs with ES|QL, checked the on-call schedule, created a case, and spun up a Slack incident channel with the on-call analyst already added, and also generated a CISO-ready summary — all before you sat down for coffee.

You reply to your CISO: "Already confirmed and triaged. The case is open. Here's the link."

This post explains how we built that pipeline: the integration of Attack Discovery, Workflows, and Agent Builder.

The threat: Chrysalis backdoor by Lotus Blossom

Threat actor profile

Campaign overview

Lotus Blossom executed a supply chain compromise of Notepad++ update infrastructure:

Attack Window: June 2025 – December 2025 (~6 months)
Vector: Hijacked Notepad++ update mechanism (WinGUp)
Method: Selective redirection of targeted users to malicious update servers
Payload: Previously undocumented "Chrysalis" backdoor
Discovery: Rapid7 MDR team, published 2026-02-02

Chrysalis backdoor capabilities

The Chrysalis backdoor is a sophisticated, feature-rich implant:

Custom encryption (LCG, FNV-1a hashing, MurmurHash)
Reflective DLL loading
API hashing for evasion
DLL sideloading via legitimate Bitdefender binary (BluetoothService.exe)
Full remote access capabilities
Persistent Windows service installation

Attack chain

[1] INITIAL ACCESS
    └── User executes malicious NSIS installer from Desktop
              ↓
[2] EXECUTION
    └── Installer drops files to hidden AppData folder
        ├── BluetoothService.exe (legitimate binary)
        └── log.dll (malicious Chrysalis loader)
              ↓
[3] PERSISTENCE
    └── BluetoothService.exe registered as Windows service
        └── Runs under SYSTEM context
              ↓
[4] DEFENSE EVASION
    └── DLL sideloading via legitimate signed binary
              ↓
[5] COMMAND & CONTROL
    └── DNS beacon to api[.]skycloudcenter[.]com ✅ CONFIRMED

MITRE ATT&CK mapping

| Tactic | Technique | ID | | :---- | :---- | :---- | | Initial Access | Supply Chain Compromise | T1195.002 | | Execution | User Execution | T1204.002 | | Persistence | Windows Service | T1543.003 | | Defense Evasion | DLL Side-Loading | T1574.002 | | Command & Control | DNS | T1071.004 |

The Challenge: Speed vs. Accuracy

When threat intelligence drops on a nation-state APT campaign, SOC teams face a brutal trade-off:

Speed: Executives want answers now. "Are we compromised?"

Accuracy: Analysts need time to hunt, correlate, and confirm before making the call.

Traditional workflows require analysts to:

Determine the scope of analysis and relevant search criteria
Manually search for IOCs across multiple data sources
Correlate alerts that may span days or weeks
Validate findings against threat intelligence
Build the attack timeline
Escalate with confidence

This process takes hours to days, during which an active attacker may exfiltrate data or move laterally.

The Solution: Attack Discovery + Workflows + Agent Builder

Elastic Security's AI-powered automation stack transforms this workflow from manual hunting to automated confirmation. But before we dive into the specific setup, it's worth understanding how the building blocks fit together.

Agents & Workflows: Two entry points, one composable architecture

Agent Builder gives you two primitives that work together:

Agents are the intelligence layer. They reason about a task, decide which tools to call, and adapt based on what they find. An agent can call search tools, MCP tools, and critically - workflows as tools.
Workflows are the structure layer. They're deterministic pipelines: steps run in order, reliably and repeatably. Any step in a workflow can optionally be an agent step, giving it the ability to reason mid-pipeline.

The two are fully composable. A workflow can invoke an agent. An agent can call a workflow. An agent step inside a workflow can call another workflow. Every connection is optional allowing you to mix and match based on what the problem demands.

This is what makes the architecture powerful: agents reason and decide; workflows execute and coordinate. For our Chrysalis attack scenario, we used both.

Our Flow

The Flow:

Many Alerts → Attack Discovery correlates disparate alerts into a single attack narrative
Attack Discovery → Generates an alert that triggers the workflow
Workflow → Invokes Agent Builder to analyze the attack discovery findings
Agent Builder → Calls enrichment workflows (VirusTotal, Threat Intel, ES|QL queries)
Agent Builder Calls a Workflow → Agent builder continues with incident response actions calling on workflow as a tool (case actions, isolate host, notify team)

Step 1: Attack Discovery surfaces the threat

Attack Discovery uses LLMs to analyze security alerts and identify attack patterns. Unlike traditional alert grouping, it understands the semantic relationships between alerts.

The alert queue: Needle in a haystack

Here's reality for a SOC analyst. You open the alerts page and see dozens of alerts across multiple hosts, users, and rules, combination of, mixed severities, mixed types, many of them noise.

Dozens of alerts. Multiple rules firing. Severity levels ranging from low to critical. Some are the Chrysalis attack. Some are unrelated Windows Defender events. Some are SIEM change detections from a completely different workflow. It’s difficult to find the coordinated attack in this wall of noise.

What Attack Discovery found

Attack Discovery analyzed all of these alerts and identified 5 alerts that belonged to a single coordinated attack - pulling them out of the noise and correlating them into one narrative:

Instead of presenting 5 individual alerts, Attack Discovery correlated them into a single discovery:

Malware with DLL Side-Loading Persistence

Malicious executable on srv-win-defend-01 escalated to persistence via BluetoothService.exe with DLL side-loading

Host: srv-win-defend-01
User: james_spiteri
Severity: Critical
Attack Chain: Initial Access → Execution → Persistence → Defense Evasion → C2

Attack Discovery also:

Mapped alerts to MITRE ATT&CK tactics
Identified the DLL sideloading technique
Flagged the suspicious persistence mechanism
Highlighted the C2 network indicator

Step 2: Scheduled discovery triggers the workflow

Attack Discovery doesn't require an analyst to click a button. We configured it to run on an hourly schedule, continuously analyzing the latest alerts for coordinated attacks.

When our hourly run kicked off, it ingested all alerts from the last hour including the Chrysalis-related alerts buried among routine detections and surfaced the DLL side-loading attack as a discovery.

Linking a workflow as an action step from attack discovery means every time Attack Discovery finds a coordinated attack, it automatically fires the workflow..

But here's what makes this approach different from traditional SOAR playbooks: the workflow doesn't script out every step. It hands the entire attack discovery to Agent Builder and says "figure it out."

Workflow definition

This is the real workflow we used consisting of two steps, that's it:

name: Auto Triage AD
description: >-
  Demonstrates the application of AI agents and workflows 
  to enable agentic alert triaging.
enabled: true
tags:
  - Example
  - Agentic Workflow

triggers:
  - type: alert                          # Fires when Attack Discovery generates an alert

steps:
  # Step 1: Hand the attack discovery to the agent with clear instructions
  - name: initial_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        agent_id:         # Your custom Hunting Agent
        input: |
          Confirm the attack by searching for behaviour in the logs 
          (all logs which are relevant), always leverage security labs tools, 
          always leverage virustotal if file hashes are available. 
          If this is a true positive, create a case with all the relevant content too.

          {{event|json}}

          Create a slack channel for this incident, check who's on call, 
          add them to it, and send a formatted message with what's happening 
          and next steps. If this is a true positive, create a case with all 
          the relevant content too - add a button to the slack message linking 
          to the case, and another button leading to the result of the attack. 
          Lastly, include a button that will take me to this agent conversation, 
          just replace the conversation ID with the actual one from this conversation 
          (https:///app/agent_builder/conversations/)

          Change the attack discovery status to acknowledged, or, 
          if false positives, close it.
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

  # Step 2: Follow up to catch anything that didn't complete
  - name: followup_analysis
    type: kibana.request
    with:
      method: "POST"
      path: "/api/agent_builder/converse"
      headers:
        kbn-xsrf: "true"
      body:
        conversation_id: "{{ steps.initial_analysis.output.conversation_id }}"
        agent_id: 
        input: |
          Complete any previous steps which might not have ran successfully. 
          Just in case, the conversation ID is 
          {{ steps.initial_analysis.output.conversation_id }}
    timeout: 10m
    on-failure:
      retry:
        max-attempts: 3

Why this workflow is so short

The entire automation is two steps:

initial_analysis: Send the attack discovery to Agent Builder with natural language instructions describing what you want done
followup_analysis: A failsafe that resumes the same conversation and asks the agent to verify all tasks were completed. Because agents call multiple tools in sequence and any individual tool call could time out or hit a transient error, this step ensures nothing falls through the cracks.

This is the fundamental shift: the workflow is the trigger and the safety net; the agent is the brain.

Under the hood: How we extended the Threat Hunting Agent

Before we continue with the results, it's worth pausing on what made this possible. One of Agent Builder's most powerful capabilities is that you can extend existing agents with additional tools. Rather than building from scratch, we took the default Threat Hunting Agent and added custom workflow-backed tools to give it the specific capabilities this scenario required.

What we added

Agent Builder ships with built-in platform tools like platform.core.generate_esql and platform.core.product_documentation. But the real power comes from adding your own. We extended the Threat Hunting Agent with tools across several categories:

Five custom tools. That's all it took to turn the default Hunting Agent into automatically verifying malware, searching logs, finding the on-call responder, creating a case, and spinning up an incident channel - all expediting the time to detect a potential threat.

The Agent's reasoning chain

Here's what's remarkable: given the Attack Discovery context, the agent automatically decided which tools to call and in what order. No human scripted these steps.

Step 1: VirusTotal Lookup: vt.hash.lookup

The agent's first move: verify the malware hash.

Step 2: Generate ES|QL Query: platform.core.generate_esql

With malware confirmed, the agent searched for all related activity.

Step 3: Product Documentation: platform.core.product_documentation

The agent referenced Elastic Security docs to generate remediation commands for the Response Console.!

Reasoning steps showing which tools were called in sequence for transparency

Shows the additional reasoning chain: referencing product documentation, then checking the on-call schedule information before creating a case with all relevant information and notifying the analyst on call over Slack.

Step 4: Check current time: get.time

Step 5: Check On-Call Schedule: check.on.call.schedule

The agent ran an ES|QL query against the on-call-schedule index to find the current responder:

Step 6: Create Case: create.case

Step 7: Create Slack Channel: create.channel

Why this matters

The agent wasn't following a script. It reasoned about the situation and decided:

First, verify the malware is real (VirusTotal)
Then, understand the impact (ES|QL log search)
Then, figure out how to remediate (product documentation)
Then, find the right person to respond (on-call schedule)
Then, create tracking artifacts (case)
Finally, coordinate the team (Slack channel)

This is the difference between a workflow (which follows a fixed sequence) and an agent (which reasons about what to do next). The workflow triggered the agent; the agent figured out the rest.

Step 3: Automated incident response

With high-confidence confirmation, the workflow automatically:

1. Creates an incident Case

A structured case is created with all relevant evidence attached:

Attack Discovery findings
VirusTotal analysis results
Threat intelligence matches
Agent Builder analysis
Recommended response actions

2. Notifies the SOC

A Slack message is sent to the right channel informing analysts of the critical incident.

3. Enables Response Actions

The workflow can optionally trigger automated response actions:

Host Isolation: Isolate srv-win-defend-01 via Elastic Defend
User Suspension: Disable james_spiteri in Active Directory
Network Block: Push C2 domain to firewall blocklist
IOC Sweep: Launch fleet-wide scan for Chrysalis indicators

Time-to-confirmation: Before and after

The other path: Just ask the Agent

Everything above describes the automated pipeline - Attack Discovery finds the threat, the workflow fires, the agent triages it, and the right analyst(s) gets notified.

But there's another equally powerful way to use this: go directly to Agent Builder and ask it in plain English.

Scenario: You read about the threat first

Imagine you're scrolling through your threat intel feeds and see Rapid7's blog post about the Chrysalis backdoor. You just want to know: are we compromised?

That's it. The same agent with the same tools does the rest:

Reads the threat report using the web.search tool to pull IOCs and TTPs from the Rapid7 blog
Generates ES|QL queries to hunt for Chrysalis indicators across your file, network, and process event logs
Checks VirusTotal for any matching file hashes found in your environment
Produces a CISO-ready summary with findings, confidence level, and recommended actions

The agent calls the same tools it would in the automated pipeline. The difference is the entry point: instead of a scheduled Attack Discovery triggering a workflow, you triggered the agent with a question.

Why this changes the game for analysts

This is the part that's easy to overlook but profoundly important: the analyst didn't need to know a single query language, index pattern, or tool name.

They didn't write ES|QL. They didn’t need to remember where their different data lives. They didn't need to remember the VirusTotal API syntax or figure out which threat intel index to query.

They asked a question in natural language. The agent figured out the rest including which indices to search, which queries to write, which tools to call, and how to synthesize the results.

For a junior analyst who joined the team last month, this is transformative. For a senior analyst who's been doing this for a decade, it's hours of their life back. For a CISO who wants a status update, it's a question away.

The barrier to effective threat hunting just dropped from "knows ES|QL and 47 index patterns" to "can describe what they're looking for."

Key takeaways

Attack Discovery on a schedule means you don't miss attacks - it continuously analyzes your alerts, so coordinated threats get surfaced even when no one is watching the queue.
Workflows orchestrate the response, triggering on discoveries, invoking agents, executing actions.
Agent Builder lets you build or extend agents for your needs - whether you start from scratch or add custom tools to an existing agent, you shape the capabilities to match your environment.
Agents reason, workflows execute - the agent autonomously decided to call VirusTotal, search logs, check the on-call schedule, and create a Slack channel. No human scripted that sequence.
Two entry points, same power - the automated pipeline and the chat interface use the same agent and the same tools. Whether a scheduled discovery triggers it or an analyst asks a question, the outcome is the same.
Natural language is the new query language - analysts don't need to know ES|QL, index patterns, or API syntax. They describe what they're looking for, and the agent handles the rest.

The Chrysalis backdoor campaign demonstrates why this matters. When nation-state actors can compromise your supply chain and establish persistence in 4 seconds, you need defenses that can match that speed - whether that's an automated pipeline running while you sleep, or a direct conversation with an agent when you're the first to spot the threat.

From Alert Fatigue to Agentic Response: How Workflows and Agent Builder Close the Loop

Dhrumil Patel — Tue, 03 Feb 2026 00:00:00 GMT

SOC leaders face a daily battle against basic math that doesn’t add up. Data volumes are growing exponentially, attack surfaces are expanding globally, yet your team’s capacity remains linear. You cannot hire your way out of this problem.

Attempting to chase individual alerts is a losing strategy. To succeed, we have to move beyond simple automation scripts and into the era of Agentic AI.

At Elastic, we view the modern security operation as an operational nervous system. It needs Senses (the data foundation to see everything), a Brain 🧠(AI driven analytics to find the signal in the noise), and Hands 🙌(Workflows to execute actions and drive outcomes).

With the introduction of Agent Builder and Elastic Workflows, we are unifying these elements. We aren't just giving you a chatbot; we are giving you the ability to construct an autonomous SOC where agents reason over data and workflows execute sophisticated actions—bidirectionally.

Here is how these two powerful engines work together to transform your security operations.

The Power of "Brain" and "Hands" Working Together

To understand why this combination is significant, we must differentiate their roles.

Elastic Workflows (The Hands): These are deterministic. They are perfect for rigid, repeatable processes—"If X happens, create a Jira ticket, ping Slack, and isolate the host." They provide structure, auditability, and reliability.
Agent Builder (The Brain): Agents are probabilistic and reasoning-based. They perceive the environment, plan a sequence of steps, and adapt. An agent can look at a vague threat report and decide which queries to run to find evidence.

The magic happens when they interact: Previously, you had to choose between a rigid playbook or a manual investigation. Now, Workflows can invoke Agents to perform complex analysis during an automation loop, and Agents can invoke Workflows as tools to perform reliable, heavy-lifting actions during a chat.

What This Isn't

Let's be clear: this isn't about replacing your analysts. It's about removing the toil that keeps them from doing the work that actually matters - the creative, adversarial thinking that no model can replicate. The goal is to shift your team from being reactive log-chasers to proactive threat hunters. The agent handles the grunt work; your people handle the judgment calls.

Use Case: Automated Triage at Alert Time

From Alert to Analysis without Human Intervention

Let’s look at a real-world scenario involving a ransomware attack (ex: BlackCat/ALPHV - a ransomware-as-a-service operation). In a traditional setup, an alert fires, and an analyst spends 30 minutes gathering logs, checking virus totals, and writing a summary.

With Elastic, this entire triage phase is automated before the analyst opens their laptop, reducing mean-time-to-triage from 30 minutes to under 2 minutes.

The Workflow:

Trigger: Attack Discovery runs on a schedule and correlates 15 disparate alerts into a single, high-fidelity Attack Chain.
Workflow Step (Enrichment): The workflow is triggered automatically and loops through every entity involved—hosts, users, file hashes. It runs a lookup against threat intel sources like VirusTotal.
Workflow Step (Invoke Agent): The workflow passes this bundle of data to a specific "Triage Agent."
Agent Execution: The agent doesn't just copy-paste data. It reasons over the attack chain, compares it against the MITRE ATT&CK framework, correlates related logs, and generates a human-readable investigation summary tailored for a Tier 2 analyst.
Outcome: The workflow posts this AI-generated analysis directly into a new Case, complete with severity scoring, deep dive investigation, root cause analysis, and recommended next steps.

User Impact: The analyst starts their day reviewing a fully contextualized case, not chasing raw logs.

Use Case: The "Human-in-the-Loop" Investigation

Turning Natural Language into Deterministic Action

Once an analyst is investigating, they often need to perform administrative tasks that break their flow like finding out who is on-call, setting up war rooms, or notifying leadership.

In Elastic Security, the analyst stays in the chat interface. Because we allow you to define Workflows as Tools for your agents, the analyst can simply ask the agent to handle the logistics.

The Workflow:

Analyst Prompt: "We have a confirmed incident. Who is on call? Please create a Slack channel for this incident and invite them."
Agent Reasoning: The agent recognizes the intent matches a "Incident Response Setup" workflow tool you have pre-configured.
Workflow Execution:

Step 1: Queries the PagerDuty integration to find the on-call engineer.
Step 2: Calls the Slack API to create a channel named #incident-[id].
Step 3: Posts the initial case summary into that channel.

Outcome: The agent confirms to the analyst: "I have created channel #incident-982 and added Jane Doe (On-Call) to the channel."

Use Case: Guided Remediation and Containment

Precision Response at Speed

When it is time to contain a threat, speed is critical, but so is safety. You don't want an LLM "hallucinating" an API call to a firewall. This is where the Agent + Workflow combination shines for safety.

The Workflow:

Analyst Prompt: "Isolate the host involved in the BlackCat alert."
Agent Reasoning: The agent identifies the host123 host from the context of the investigation. It creates a plan to invoke the "Host Isolation" workflow.
Decision Point: The Agent presents the plan to the user: "I am about to trigger the 'Isolate Host' workflow for host123 via Elastic Defend."
Workflow Execution: The deterministic workflow executes the isolation command via Elastic Defend (XDR), ensuring the action is logged and performed exactly as defined by your engineering team.
Outcome: The host is isolated immediately.

User Impact: You get the ease of natural language interaction with the safety and audit trails of hard-coded automation.

We are moving away from a world where you have to choose between flexible AI chat and rigid SOAR playbooks. The future is an Autonomous SOC where the two are inextricably linked.

By using Agent Builder to create custom agents that understand your specific environment (using RAG with your own data) and equipping them with Elastic Workflows as tools, you effectively multiply your team's capacity and scale expertise. You are not just deploying a chatbot; you are deploying a virtual team member that knows your runbooks, respects your permissions, and works 24/7.

For more detailed information on getting started with Agent Builder read this blog.

Agent Builder and Workflows are available now as a tech preview. Get started with an Elastic Cloud Trial, and check out the documentation for Agent Builder here, and Workflows here.