Elastic's security team has developed an "agentic" Security Operations Center (SOC) that automates alert investigation, significantly reducing the time it takes to triage security alerts. This new system can process alerts in under three minutes, a drastic improvement from the previous 30-minute manual triage time. The approach leverages Elastic's native technology stack, including Elastic Workflows, Agent Builder, the Elastic Inference Service, and Kibana Cases, without relying on third-party orchestration tools.
The core principle of this agentic SOC is to automate tasks that do not require human judgment, allowing human analysts to focus on more complex and critical alerts. This is particularly important as AI-assisted attacks are shortening the time from initial compromise to data exfiltration, making traditional manual alert triage insufficient. Hiring more analysts is not a scalable solution to the increasing volume of alerts.
The system begins by using deterministic ES|QL queries to automatically close obvious false positives. This process is cost-effective, consuming no computational tokens. For alerts that are not immediately closed, specialized AI agents investigate further across endpoint, cloud, and SaaS environments. A final review agent then compiles the findings and writes its verdict into a Kibana case.
A key aspect of the system is its handling of sensitive data during AI inference. The Elastic Inference Service directs requests to third-party model providers that have documented zero data retention policies and do not use input data for model training. Customers can verify the data handling status of specific models used in their pipelines. For highly sensitive or air-gapped environments, the same pipeline can be run using models hosted on the organization's own infrastructure.
Elastic's own InfoSec team acts as "Customer Zero," using the latest versions of Elastic Security in their production environment. Their infrastructure includes thousands of laptops, servers, and cloud workloads supporting a global workforce, making them a demanding user of new features. The agentic SOC journey began with a single Agent Builder triage agent in Elastic Security 9.2, which performed well for workstation alerts with consistent investigation patterns. However, the need for more specialized approaches for SaaS logs and higher-order threshold alerts led to the development of domain-specific agents.
The initial stage of alert triage relies heavily on ES|QL queries. The philosophy here is that any check resolvable by a query should be executed as such, rather than involving a more expensive and potentially less reliable LLM call. ES|QL queries are deterministic, auditable, fast, and free in terms of token costs. LLM calls, conversely, can be non-deterministic, slower, more costly, and introduce failure modes like hallucinations or inconsistent reasoning. Most well-understood false-positive patterns can be expressed in code, making token expenditure for reasoning about them unnecessary. LLMs are reserved for genuinely ambiguous data scenarios.
Detection rules within Kibana now support a new workflow action. When configured on a rule, any alert generated by that rule is automatically sent to a designated workflow for processing. This workflow serves as the entry point for the entire pipeline. The workflow's trigger is configured to accept alerts, and detection engineers tag rules with specific triage categories (e.g., "Workstation," "PMFA," "Asset," "All"). These tags dictate which checks are performed. For instance, workstation rules initiate device and user identity checks, while infrastructure rules run broader asset and CI/CD checks. This tagging mechanism defines what constitutes a false positive at the rule authoring stage and is automatically enforced by the workflow.
For alerts originating from IP-based sources like Okta, AWS, Azure, and GCP, the workflow executes up to 16 ES|QL queries. These queries span asset inventory, fleet data, and SaaS audit logs to determine if the source IP is part of known corporate infrastructure. An example query checks for an active, low-risk Okta session from the source IP, indicating the use of phishing-resistant multi-factor authentication. If any query yields a positive result, such as a successful low-risk Okta login from that IP, the workflow immediately closes the alert without creating a case or using tokens.
Alerts that pass the initial triage step proceed to the enrichment phase. This stage gathers all necessary supporting information to provide context for accurate triage. Any query an analyst would typically run for investigation is incorporated into the workflow. The workflow queries over 20 data sources using fields from the alert, including user and host risk scores, recent login locations and devices, asset inventory details, cloud account ownership, and activity across various SaaS platforms. It also lists recent alerts for the same user, workstation, and source IP within the last 72 hours, and checks for previous cases containing similar observables. This collected context is assembled into a note for the initial triage agent's prompt and is also added as an early comment if a case is opened.
The Initial Triage agent is the first AI agent in the pipeline, and its output dictates the subsequent workflow path. It utilizes the Elastic Security Labs knowledge base to compare alerts against published threat actor techniques and malware behavior. The agent performs a structured assessment, with its response formatted to include a Verdict (True Positive or False Positive), an Assessment (malicious, suspicious, unknown, or benign), and a Confidence level (high or low). This structured output allows the workflow to parse the agent's findings and route the alert accordingly.
