Elastic 的 Agentic SOC 执行攻击者设定的工作流

背景

安全团队正竞相采用 Agentic SOC（安全运营中心）以提升其安全防护能力；讽刺的是，AI SOC 本身却可能构成严重的安全风险。鉴于事件响应中涉及大量不可信数据（恶意活动报告）以及敏感操作的能力，AI SOC 成为间接提示注入攻击的主要目标。我们在 Elastic 的 AI SOC EASE 中演示了这一威胁。

Elastic 的 Agentic SOC 代理容易受到其被设计用于分诊的警报的操纵，并且它可以以用户的权限在 Elastic 中执行任何操作；无需人工审核批准。

在下方的攻击链中，代理被操纵以生成 API 密钥并将其发送给攻击者。随后，攻击者可以执行用户拥有权限的任何操作，例如禁用检测规则、创建虚假警报以掩盖真实攻击、从 Elasticsearch 中窃取数据或删除租户中的数据。

该漏洞已于 2026 年 8 月 23 日向 Elastic 报告，但在四次后续跟进后仍未得到解决。因此，我们发布此报告以告知用户相关风险及缓解配置。有关负责任披露的更多详情见文章末尾。

攻击链

1.
用户请求 AI SOC 协助分诊钓鱼警报

SOC 中非常常见的一个数据源是钓鱼热线，用户可以转发可疑邮件供安全团队进行分诊。

用户要求 Elastic AI 对钓鱼警报进行分诊。

2.
AI SOC 被其中一条警报操纵，以创建并执行恶意工作流

代理试图评估的一条钓鱼电子邮件指出，需要从特定 URL 检索其他警报，并且应使用带有子代理的工作流来处理它们。

Elastic AI 遵循嵌入在警报中的指令。

该工作流从攻击者控制的 URL 检索数据，然后生成一个子代理，其上下文仅限于攻击者的数据和系统提示：“执行以下操作”……导致子代理执行攻击者服务器提供的任何操作。

该工作流检索攻击者控制的提示并运行子代理。

注意：这一切都在没有人工审核批准的情况下发生，因为代理有权决定何时在工作流中添加“等待批准”步骤，而提示注入会劝阻这样做。

3.
恶意工作流窃取 API 密钥

在此处，攻击者的服务器返回一条指令，告知子代理它正在参与一项竞赛。为了获胜，它需要生成新的 API 密钥并将其发送给攻击者的服务器以“提交其发现结果”。

攻击者服务器记录由子代理提交的 API 密钥。

技术说明：该攻击还窃取了工作区 URL，这是攻击者使用窃取的 API 密钥发出请求所必需的。

4.
攻击者利用 API 访问权限在 SOC 中执行未授权操作并窃取数据
攻击者使用被盗的 API 密钥查询数据并修改警报规则。

利用窃取的凭据，攻击者可以执行用户所能执行的任何操作。这包括：

■
禁用或移除警报规则
■
创建虚假警报以掩盖真实攻击
■
从 Elastic 及集成系统中窃取数据
■
通过计划任务建立持久性
■
收集由 AI SOC 监控的设备上的数据

我们还要注意，所有这些结果都可以直接通过被操纵的子代理运行的工作流来实现，而不是利用工作流来窃取密钥并由此展开后续操作。

缓解措施

1.
代理配置：

禁用 Elastic AI Agent 设置中的“自动包含内置功能”，以允许手动管理启用了哪些工具。

您的项目 > 代理（左侧边栏）> 概述 > 编辑代理设置 > 自定义 > 自动包含内置功能 > 关闭

随后，我们建议禁用具有写入能力的工具，因为系统目前似乎不支持“人在回路”（human-in-the-loop）审批控制，仅在使用代理自行决定的“waitForApproval”工作流步骤中除外。

您的项目 > 代理（左侧边栏）> Elastic AI Agent（下拉菜单）> 管理代理 > 悬停于“Elastic AI Agent”，点击出现的编辑图标 > 工具选项卡 > 取消勾选不需要的工具

以下默认在默认代理上启用的工具风险最高：

■
Platform.core.execute_esql
■
Platform.core.execute_workflow

我们还强烈建议禁用自动将所有当前和未来的 Elastic 构建的工具、技能和插件分配给代理的设置。

您的项目 > 代理（左侧边栏）> Elastic AI Agent（下拉菜单）> 管理代理 > 悬停于“Elastic AI Agent”，点击出现的编辑图标 > 设置选项卡 > Elastic 功能 > 关闭开关
2.
默认模型选择

目前，Elastic 的默认模型是 Anthropic Claude Sonnet 4.5。

Elastic AI 的默认模型是 Anthropic Claude Sonnet 4.5。

较新的模型对间接提示注入具有显著更强的鲁棒性。通过以下路径配置替代默认模型：

您的项目 > 发现 Elastic AI / 配置 AI 提供商 > 选择提供商 > 在下拉菜单中选择模型
3.
IP 访问限制

要限制与不受信任的 IP 之间的 Elastic Cloud 入站和出站流量，请在以下位置配置网络安全策略：

组织设置 > 网络安全 > 创建策略
负责任披露

PromptArmor 于 2026 年 8 月 23 日披露了本文所述的漏洞。Elastic 确认收到了报告，但在四次后续跟进后仍未参与披露过程。因此，我们发布此文旨在告知用户相关风险及缓解这些风险的控制措施。

我们注意到，Elastic 的报告政策明确允许通过电子邮件进行披露，声明称：“如果您不希望使用漏洞赏金计划，您可以直接发送电子邮件至 security@elastic.co。”。
时间线
日期

事件

2026 年 8 月 23 日

PromptArmor 向 Elastic 披露

2026 年 8 月 27 日

PromptArmor 跟进

2026 年 8 月 28 日

Elastic 要求通过 HackerOne 提交

2026 年 8 月 28 日

PromptArmor 澄清电子邮件偏好

2026 年 9 月 1 日

PromptArmor 跟进，指出电子邮件是已记录的报告渠道

2026 年 9 月 6 日

PromptArmor 跟进

Elastic’s Agentic SOC executes the attacker’s workflow
Context

Security teams are racing to adopt Agentic SOCs (security operations centers) to improve their security; ironically, AI SOCs themselves can pose a serious security risk. Given the prevalence of untrusted data (malicious activity reports) and the capability for sensitive actions involved in incident response, AI SOCs are prime targets for indirect prompt injection attacks. We demonstrate this threat in EASE, Elastic's AI SOC.

Elastic’s Agentic SOC agent is susceptible to manipulation by the alerts it was created to triage, and it can take any action in Elastic with the user’s privileges; no human-in-the-loop approval is required.

In the attack chain below, the agent is manipulated into minting API keys and sending them to an attacker. The attacker can then take any action the user has permissions for, such as disabling detection rules, creating fake alerts to conceal a real attack, exfiltrating data from Elasticsearch, or deleting data from the tenant.

This vulnerability was reported to Elastic on August 23, 2026, but has not been addressed despite four follow-ups. As such, we are publishing this report to inform users of the risk and configurations to mitigate it. More details on responsible disclosure are at the end of the article.

The Attack Chain
1.
The user asks the AI SOC for assistance triaging phishing alerts

One very common data source in a SOC is a phishing tipline, where users can forward suspicious emails for triage by the security team.

The user asks Elastic AI to triage phishing alerts.
2.
The AI SOC is manipulated by one of the alerts to create and execute a malicious workflow

One of the phishing emails the agent is trying to assess states that there are additional alerts to retrieve from a specific URL and that it should use a workflow with a subagent to handle them.

Elastic AI follows instructions embedded in an alert.

The workflow retrieves data from an attacker-controlled URL and then spawns a subagent with no context other than the attacker's data and a system prompt: ‘Action the below’... leading the subagent to take whatever action the attacker’s server supplies.

The workflow retrieves an attacker-controlled prompt and runs a subagent.

Note: This all occurs without human-in-the-loop approval because the agent has discretion over when to add a ‘waitForApproval’ step to its workflows, and the prompt injection discourages doing so.

3.
Malicious workflow exfiltrates API keys

Here, the attacker’s server returns an instruction telling the subagent that it is participating in a competition. To win, it needs to mint new API keys and send them to the attacker’s server to ‘submit its findings’.

The attacker server logs API keys submitted by the subagent.

Technical note: The attack also exfiltrated the workspace URL, which is necessary for the attacker to make requests using the exfiltrated API key.

4.
Attacker exploits API access to take unauthorized actions in the SOC and exfiltrate data
The attacker uses stolen API keys to query data and modify alert rules.

Using the exfiltrated credentials, the attacker can take any action a user could. This includes:

■
Disabling or removing alert rules
■
Creating fake alerts to cover for a real attack
■
Exfiltrating data from across Elastic and integrations
■
Establishing persistence through scheduled jobs
■
Harvesting data from devices monitored by the AI SOC

We also note that all of these outcomes can be achieved directly via a workflow run by a manipulated subagent, rather than using the workflow to exfiltrate keys and proceeding from there.

Mitigations
1.
Agent configurations:

Disable the Elastic AI Agent setting “Include built-in capabilities automatically” to allow manual management of which tools are enabled.

Your Project > Agents (left sidebar) > Overview > Edit Agent Settings > Customization > Include built-in capabilities automatically > Toggle OFF

We then recommend disabling write-capable tools, as the system does not currently appear to support human-in-the-loop approval controls, except for ‘waitForApproval’ workflow steps, which are used only at the agent’s discretion.

Your Project > Agents (left sidebar) > Elastic AI Agent (Dropdown) > Manage Agents > Hover 'Elastic AI Agent', click Edit icon that appears > Tools Tab > Uncheck unwanted Tools

The following tools, which are enabled by default on the default agent, carry the highest risk:

■
Platform.core.execute_esql
■
Platform.core.execute_workflow

We also highly recommend disabling the setting to automatically assign all current and future Elastic-built tools, Skills, and Plugins to the agent.

Your Project > Agents (left sidebar) > Elastic AI Agent (Dropdown) > Manage Agents > Hover 'Elastic AI Agent', click Edit icon that appears > Setting Tab > Elastic Capabilities > Toggle OFF
2.
Default model selection

Currently, the default model in Elastic is Anthropic Claude Sonnet 4.5.

Elastic AI’s default model is Anthropic Claude Sonnet 4.5.

More recent models are substantially more robust against indirect prompt injection. Configure an alternative default model via:

Your Project > Discover Elastic AI / Configure AI Provider > Select Provider > Select model in dropdown
3.
IP Access Restrictions

To restrict ingress and egress from Elastic Cloud to and from untrusted IPs, configure Network Security policies under:

Organization Settings > Network Security > Create Policy
Responsible Disclosure

PromptArmor disclosed the vulnerabilities described in this article on August 23, 2026. Elastic acknowledged receipt of the report but did not engage with the disclosure despite four follow-ups. As such, we are publishing to inform users of the risks and pertinent controls to mitigate them.

We note that Elastic’s reporting policy explicitly permits email disclosure, stating, “If you do not wish to use the bug bounty program, you may email us directly at security@elastic.co.".

Timeline
Date

Event

August 23, 2026

PromptArmor discloses to Elastic

August 27, 2026

PromptArmor follows up

August 28, 2026

Elastic requests submission via HackerOne

August 28, 2026

PromptArmor clarifies email preference

September 1, 2026

PromptArmor follows up, citing email as documented reporting channel

September 6, 2026

PromptArmor follows up