The Decoder 6小时前 · 2026-10-09 02:08:04 · 0 阅读

Zenity 研究人员：一条提示词即可劫持 AWS 账户内所有 AI Agent

核心要点

Amazon Bedrock AgentCore 平台存在一连串漏洞，研究人员仅向其中一个公开 Agent 发送了一条聊天消息，便控制了同一 AWS 区域内某公司的所有 AI Agent。
Agent 缺乏适当的隔离机制，在被询问时便交出内部 AWS 凭证。由于该平台在整个区域内授予了过宽的默认权限，研究人员得以访问并操控其他 Agent 的源代码、密码、私密对话及长期记忆。
AWS 已通过增加新 Agent 获取内部元数据的难度以及收紧默认执行角色权限，部分修复了此问题。研究人员仍建议企业手动为 AI Agent 分配访问权限更严格的角色。

Zenity Labs 的研究人员指出，仅 Amazon Bedrock AgentCore 上的一个可公开访问的 AI Agent，就足以接管同一 AWS 账户和区域内的所有 AgentCore Agent。

Amazon Bedrock AgentCore 是 AWS 用于运行企业级 AI Agent 的平台，支持工具调用、内存管理以及访问控制。安全公司 Zenity Labs 发现了一系列漏洞，研究人员将其称为“AgentCorruption”。

攻击者仅需拥有对一个公开 Agent 的聊天访问权限即可利用这些漏洞。研究人员表示，他们只用了一条提示词便接管了同一 AWS 账户和区域内的所有 AgentCore Agent，暴露了私密对话、源代码以及存储的凭证。据 Zenity 称，该问题是系统性的，影响了多个 AWS 账户中内置了工具的 Agent。

Agent 交出了自身凭证

AWS 在内部地址 169.254.169.254 运行实例元数据服务（Instance Metadata Service），为实例和工作负载提供临时凭证以进行 AWS 身份验证。任何人获取这些凭证后，都可以冒用该实例的身份。

通常情况下，AI Agent 不应能够访问该服务，但根据 Zenity 的技术博客，AgentCore 缺乏恰当的隔离机制。研究人员使用 AWS 的开源框架Strands构建了一个测试 Agent，该框架自带 Web 工具。当研究人员用自然语言要求 Agent 查询元数据服务并将结果发送到外部服务器时，Agent 照做了。研究人员写道：“我们原本应当依靠的沙箱边界，根本不存在。”

一家名为“TechHub”的虚构在线商店，其开放的客户支持聊天窗口中显示一条以红色高亮标记的俄语消息，指示 Agent 查询 IMDS 地址 169.254.169.254 并将响应发送到外部服务器。 — 客户支持窗口中的一条聊天消息，就诱骗 Agent 将其自身的 AWS 凭证发送到了外部服务器。 | 图片来源：Zenity Labs

这些被盗的凭证在平台外的研究人员本地机器上依然有效，因此攻击不再依赖 Agent 继续执行。该元数据服务还暴露了某个 AWS 内部服务的证书和密钥材料，以及一个指向不属于研究人员账户的内部 S3 存储的预签名 URL。

Burp Collaborator 视图，显示来自元数据服务的 JSON 响应，包含临时 AWS 凭证的 AccessKeyId、SecretAccessKey、会话令牌和过期时间。 — 元数据服务返回了 Agent 完整的临时 AWS 凭证，包括密钥和会话令牌。 | 图片来源：Zenity Labs

根据 Zenity 的说法，移除 Web 工具也无济于事，因为缺陷在于平台本身。研究人员还通过命令行工具实施了该攻击。

默认权限暴露了区域内所有 Agent

之所以能实现接管，是因为 AgentCore 的默认权限并不局限于接收这些权限的那个 agent。据 Zenity 介绍，这些权限适用于同一账户、同一 region 下的所有 agent，授予了读、写、删除权限，足以执行破坏性操作。

Terminal output of a script sequentially pulling container images of agents like "Ceo_assistant" and "CustomerSupport" from ECR and copying their /app directories. — 自动化脚本拉取了该 region 下所有 agent 的容器镜像，并复制了它们的源代码。| 图片来源：Zenity Labs

凭借这些权限，研究人员可以列出所有 agent，几秒内下载它们的代码包，并逐一调用。这些代码包往往随源代码一起包含被遗忘的密码或 API key，泄露范围可能比 agent 本身更广。例如，攻击者可以从面向公众的客服 agent 横向移动到内部财务 agent，进而访问其数据。研究人员还能读取用户与 agent 之间的所有私密对话。

JSON output of an AgentCore memory event with highlighted session ID, actor ID "amanda_white," and the chat history between a user and a Finance Assistant agent. — 凭借窃取的凭证，研究人员读取了该 region 下其他用户与任意 AgentCore agent 之间的私密对话。| 图片来源：Zenity Labs

对于启用了长期记忆的 agent，研究人员可以篡改其记忆来影响后续行为。他们在关于记忆投毒的文章中描述了如何植入指令，让 agent 把之后的对话转发到外部地址。用户会在毫无察觉的情况下，继续和一个看似可信的 agent 对话。

AWS 建议将密码和 API 密钥单独存储在安全区域，与代理（Agents）隔离，但 AgentCore 的默认权限削弱了这种保护。根据 Zenity 关于凭据窃取的技术文章，这些权限允许代理访问存储的凭据，甚至包括 AWS 外部服务的密钥。

AWS 收紧元数据访问与默认权限

Zenity 称，他们于 2025 年 12 月 25 日向 AWS 报告了 AgentCore 的相关发现，随后 AWS 将新部署的 AgentCore 默认设置为 IMDSv2。IMDSv2 是元数据服务的更Secure版本，也是 Zenity 攻击的切入点。Zenity 同时销售面向 AI 代理的安全平台，因此该公司在此领域报告漏洞也存在商业利益驱动。

根据 Zenity 更新后的说明，AWS 在 8 月左右还调整了 AgentCore 的默认执行角色。更新后的角色不再允许代理调用其他代理、读取私有对话或从 AWS Secrets Manager 获取凭据。AWS 还大幅限制了其他权限，不过研究人员仍建议企业创建具有更窄访问范围的自定义角色。他们在这篇默认角色分析中解释了这些建议。

Zenity CTO Michael Bargury 认为，云安全与代理工作需要的那种灵活性之间存在冲突。他说：“云安全的核心在于分段隔离和最小权限原则。但 AI 代理需要创造力才能发挥作用。”所有在云端运行代理的企业都面临这种权衡，尤其是当面向公众的内部代理共享同一环境时。在这种配置下，单个漏洞就可能破坏整个系统的安全边界。

其他攻击也暴露了 AI 代理的类似弱点

AgentCore 的发现延续了 Zenity 在其他研究中记录的模式：看似无害的输入反而会让智能体（Agent）反戈一击，危害其所属机构。在 AgentFlayer 研究中，零点击攻击曾让 Salesforce Einstein、Copilot Studio 和 Cursor 被诱导重定向客户数据或泄露凭证。而在 AgentForger案例中，仅通过一个被篡改的 ChatGPT 链接，就能在 OpenAI 的 Workspace Agents 中创建一个自主智能体，且其权限审批机制已被禁用。

OpenAI 在四天内修复了该漏洞，但 AgentCore 过于宽泛的默认权限在 Zenity 报告发布后却持续存在了数月。AWS 已向所有企业开放 AgentCore，亚马逊称其用户包括索尼和爱立信。

关于智能体记忆的研究也记录了类似的弱点。Google DeepMind 在其“AI Agent 陷阱”分类法中，将长期记忆操纵列为独立的攻击类别，发现知识库中仅少数被污染文档就能诱导回复偏差。在红队测试研究《混沌智能体》（Agents of Chaos）中，研究人员通过记忆文件中链接的外部可编辑文档远程控制了一个 OpenClaw 智能体，而另一个智能体则直接交出了未脱敏的银行信息。

OpenAI CEO Sam Altman 曾表示，智能体应仅获取所需的最小权限。Zenity 指出，AgentCore 的默认角色设置违背了这一原则。

原始来源： The Decoder