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.

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 for svc-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.

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

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:

1. Determine the scope of analysis and relevant search criteria
2. Manually search for IOCs across multiple data sources
3. Correlate alerts that may span days or weeks
4. Validate findings against threat intelligence
5. Build the attack timeline
6. 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:

1. Many Alerts → Attack Discovery correlates disparate alerts into a single attack narrative
2. Attack Discovery → Generates an alert that triggers the workflow
3. Workflow → Invokes Agent Builder to analyze the attack discovery findings
4. Agent Builder → Calls enrichment workflows (VirusTotal, Threat Intel, ES|QL queries)
5. 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-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://<your-kibana-url>/app/agent_builder/conversations/<conversation-id>)

          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: <your-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:

1. initial_analysis: Send the attack discovery to Agent Builder with natural language instructions describing what you want done
2. 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:

1. First, verify the malware is real (VirusTotal)
2. Then, understand the impact (ES|QL log search)
3. Then, figure out how to remediate (product documentation)
4. Then, find the right person to respond (on-call schedule)
5. Then, create tracking artifacts (case)
6. 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:

1. Reads the threat report using the web.search tool to pull IOCs and TTPs from the Rapid7 blog
2. Generates ES|QL queries to hunt for Chrysalis indicators across your file, network, and process event logs
3. Checks VirusTotal for any matching file hashes found in your environment
4. 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

1. 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.
2. Workflows orchestrate the response, triggering on discoveries, invoking agents, executing actions.
3. 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.
4. 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.
5. 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.
6. 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.

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:

1. Trigger: Attack Discovery runs on a schedule and correlates 15 disparate alerts into a single, high-fidelity Attack Chain.
2. 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.
3. Workflow Step (Invoke Agent): The workflow passes this bundle of data to a specific "Triage Agent."
4. 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.
5. 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:

1. Analyst Prompt: "We have a confirmed incident. Who is on call? Please create a Slack channel for this incident and invite them."
2. Agent Reasoning: The agent recognizes the intent matches a "Incident Response Setup" workflow tool you have pre-configured.
3. 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.
4. 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:

1. Analyst Prompt: "Isolate the host involved in the BlackCat alert."
2. Agent Reasoning: The agent identifies the host123 host from the context of the investigation. It creates a plan to invoke the "Host Isolation" workflow.
3. Decision Point: The Agent presents the plan to the user: "I am about to trigger the 'Isolate Host' workflow for host123 via Elastic Defend."
4. 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.
5. 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.