一条提示词，一个智能体，一整个 AWS 账户：深入探究 Amazon Bedrock AgentCore 上的 AgentCorruption

2026年10月8日，Zenity Labs披露了AgentCorruption：Amazon Bedrock AgentCore中存在一系列缺陷，这是AWS用于部署和运行AI代理的托管平台，使得向一个面向公众的代理发送单条自然语言提示，就能控制同一AWS账户和区域内的每一个AgentCore代理。这项研究与SecTor 2026（在多伦多举行）上的演讲一同发布，Zenity的安全研究总监Tamir Ishay Sharbat在会上介绍了它（Dark Reading，2026年10月8日）。Zenity自己的报告由Sharbat、Lana Salameh、Dmitry Lozovoy和João Donato署名，开篇即说明了该机制：一个AgentCore代理只要拥有任何能够发起出站请求的工具，就可以被诱导去调用AWS Instance Metadata Service (IMDS)，其链路本地地址为169.254.169.254，该服务会返回该代理自身执行角色的临时凭证。Zenity表示，它将这些凭证导出到了自己的机器上，并确认它们可以从那里使用。未分配CVE编号。

归档记录将其记作一个漏洞——是已发现的，未必已被利用——并具有高严重程度、置信度 A，没有记录到实际危害，且已确认有 AI 参与。尽管各方对该行为的认定一致，但对这一定性存在分歧：AWS 对 Dark Reading 表示，该研究“将预期且已有文档记载的行为不准确地描述为漏洞。”

这条链条实际上是什么

AgentCore 将每个代理打包为一个容器，并在按会话分配的Firecracker MicroVM中运行它。Zenity 该系列的第一篇文章通过向一个使用Strands SDK（AWS 的开源代理框架，内置 HTTP 请求工具和 shell 工具）构建的测试代理发送一段通俗语言的请求，完整复现了整个立足点获取过程。该微虚拟机并未限制对元数据服务的流量，因此请求来自实例内部，IMDS 也做出了响应。此后，研究人员逐一探查了各个端点：IAM 角色名称、临时 STS 凭证本身、user-data 端点——该端点返回了账户 ID、完整的 ARN、运行时 URL 以及该代理的Amazon Elastic Container Registry (ECR) 镜像 URI——还有实例标签，其中包含 mTLS 证书链、私钥以及指向内部存储的预签名 URL。Zenity 表示，通过 shell 工具也能得到相同的结果，因为这一隔离失效发生在平台层面，而非某个具体工具之中。

那段过程中有两个细节很容易被一眼略过。凭证并未被限制在沙箱之内：Zenity 将它们导出到 AgentCore 之外，并发起了一次 AWS 身份调用，而返回的结果正是该智能体所代入的角色。而被窃取的那个角色又能够拉取容器镜像——智能体的源代码正是由此变得可读的。Zenity 的帖子指出，镜像中往往带有硬编码的密钥、残留的令牌，以及本就不该被打包进去的配置，并且拉取到的镜像就是一张底层业务逻辑的地图。

默认角色正是立足点转变为账户的地方

单独报告的第二个缺陷是，AgentCore 默认附加到代理的执行角色并未限定为单个代理的范围。Zenity 描述称，这些权限可触达账户和区域内的每一个 AgentCore 资源，包括 bedrock-agentcore:InvokeAgentRuntime、bedrock-agentcore:ListEvents、bedrock-agentcore:CreateEvent、bedrock-agentcore:DeleteEvent，以及在凭证链末端的 bedrock-agentcore:GetResourceApiKey和secretsmanager:GetSecretValue。

可枚举性将那些通配符变成了一份目标列表。Zenity 使用了该角色的 logs:DescribeLogGroups权限，因为 AgentCore 将每个代理的 CloudWatch 日志组命名为 /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}，并根据这些日志组名称推导出代理 ID。ECR 存储库名称遵循研究人员观察到的一种约定——bedrock-agentcore-<agent_name>——因此该区域中每个代理的映像都可以拉取。Memory 资源也是以同样的方式找到的，即根据日志组模式 /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}，以及该角色的 ListActors、ListSessions 和 ListEvents 权限生成了读取对话内容所需的 actor 和会话标识符。

Zenity 的报告给出了一个具体的横向移动演示：通过一个面向公众的智能体进入，发现billing_agent 在同一区域中的工具，并发现一个名为 billing.json 的文件，再通过文件读取工具将其外泄。新闻稿以概括性的方式描述了同样的场景——攻击者通过一个面向互联网的客服智能体进入，可以横向移动到部署在同一区域的内部财务智能体，调用它，并获取其数据、工具、相关凭据以及私密对话。

记忆是比提示活得更久的那部分

AgentCore Memory 将对话本身保留为短期记忆，并将提取出的记录存储为长期记忆，使用的策略名为 SEMANTIC、USER_PREFERENCE、SUMMARIZATION 和 EPISODIC。Zenity 使用 CreateEvent将对话事件写入其他代理的记忆资源。其文章谨慎地说明了该原语能做什么、不能做什么：Create 不允许调用方选择长期命名空间，也不能直接覆盖记录——目标记忆所配置的策略决定提取哪些内容以及这些记录落在何处。Zenity 还描述了DeleteEvent被用来删除工具结果事件，使代理因数据缺失而得出错误结论，并通过删除植入记忆的事件来掩盖痕迹。

写入原语所产生的结果是持久化。Zenity 的演示植入了一个请求：要求智能体在作答之前先获取研究人员控制的页面，并遵循该页面的内容——这是一个命令与控制端点，其指令无需植入另一条记忆即可被更改。随后，同一条通道又将对话内容带出：该报告描述了智能体将用户的消息及其自身的回复发送到一个收集端点，并指出该角色上的记忆权限扩展至整个账户和区域，而非仅限于被入侵的智能体。随研究一同发布的一段视频显示，当这些内容抵达研究人员的服务器时，用户仍在继续对话。

AWS 之外的凭证

该系列的最后一篇文章为互联工具这一话题画上了句号。AgentCore Identity 和 Outbound Auth 将工具凭据作为密钥存储在AWS Secrets Manager中，其名称由提供商名称和一个固定模式构成，例如bedrock-agentcore-identity!default/apikey/{provider_name}。Zenity 通过抓取它此前已从 ECR 拉取的智能体源代码来还原提供商名称，并通过暴力破解还原其他名称：它报告称，默认的五字符后缀是在客户端由数字和小写字母生成的，在两种提供商类型下共计2 x (10+26)^5 = 120,932,352种组合。以它针对 Secrets Manager 所能维持的请求速率，Zenity 表示完整枚举需要数小时——比 STS 凭据的存活时间更长——因此它构建了一个循环，在旧凭据过期时重新向智能体的 IMDS 端点查询新凭据。Zenity 补充说，通过元数据 user-data 端点可以读取环境变量，每个名称都以CONTAINER_ENV_为前缀，其中包括智能体用于向其模型提供商进行身份验证的密钥，而用合适的提示词调用每一个被发现智能体，便可大规模采集这些值。

已确立，但因技术细节而受到质疑

已确立的事实是有限而具体的。AgentCore 智能体能够访问 IMDS，并获取其自身执行角色的临时凭证——AWS 对此并无异议，并在其声明中称这属于“已记录且符合预期”的行为。默认执行角色所携带的权限范围是基于账户和区域划定的，而非仅限单个智能体；AWS 此后已对此作出修改，Zenity 表示其自身测试证实了这一权限缩减。这项研究属于演示验证，而非观测到的实际攻击活动：Sharbat 对 Dark Reading 表示，Zenity 未发现任何证据表明该漏洞在修复前曾被实际利用，他将此部分归因于难以识别哪些组织在 AgentCore 上运行智能体，并补充说他“100% 确定存在实现这一利用的方法”。

争议在于，是否其中的任何一点都应被称为漏洞。AWS向Dark Reading和The Next Web提供的声明称：“AWS已知悉有关Amazon Bedrock AgentCore的已发表研究，该研究将预期且已记录在案的行为不准确地描述为漏洞。只有当开发者在代理的执行角色和目标资源上都明确授予权限时，代理才能访问另一个AWS账户中的资源。”Zenity自己发布的帖子里转载的AWS声明保留了第一句话的实质内容——“所描述的行为是已记录的，也是预期内的”——并补充说，客户应只向执行角色授予其代理所需的权限。分歧之下有两件事。AWS是以访问另一个AWS账户中的资源来界定这一边界的，而Zenity的发现则涉及单个AWS账户和区域内的代理；此外，Zenity所描述的那些角色来自平台的默认设置，而非客户手写策略所产生。

The Next Web对自身报道的更正值得记录，因为它表明这一说法是被研究人员以外的人收紧的。它最初报道并随后更正了一个标题，该标题称研究人员接管了某个区域内每一个AgentCore智能体；更正后的版本指出，该研究覆盖的是单一AWS账户和区域内的智能体，并说明此前的标题将研究人员的说法当作了事实。

披露时间线

Zenity 提交了两份报告，而非一份，两者的答复也各不相同。IMDS 访问报告提交于 2025 年 12 月 25 日；AWS 于 2026 年 4 月 12 日将其以“informative”为由关闭，并写道 AgentCore 直到 2026 年 2 月 14 日才仅使用 IMDSv2，新部署的代理均以该方式启动。这一修订对本研究的具体细节很重要，因为 IMDSv2 要求每个请求都携带会话令牌，会使研究人员用以获取凭据的简单未认证抓取失效。第二份报告涉及默认角色及其影响范围，提交于 2026 年 1 月 12 日。AWS 于 2026 年 2 月 25 日告知 Zenity，团队正在处理此事，而该角色保持不变；Zenity 于 2026 年 6 月 22 日再次审查了该角色，发现其权限没有变化。最终审查于 2026 年 9 月 29 日进行，发现该角色已被大幅收窄，Zenity 的新闻稿称，被移除的权限涵盖调用其他代理、读取私人对话以及访问 AWS Secrets Manager 中的机密，其他权限也受到显著限制。Zenity 自己的帖文指出，AWS 此后已将 IMDSv2 设为 AgentCore 部署的默认选项，且双方在整个过程中保持协作。

什么是未知的

Zenity 尚未公布，在二月的 IMDSv2 变更与九月下旬收窄之间这段时间里，有多少代理或组织以默认角色运行；所引用的来源中，也没有任何内容表明有客户数据被泄露到研究人员自身环境之外。据 Zenity 转述 AWS 的说法，IMDSv2 变更适用于 2026 年 2 月 14 日之后部署的代理；而对于在该日期之前部署的代理意味着什么，本文所审视的来源并未说明。存档中未记录任何实际危害，而各来源也支持这一解读：它们描述的是演示，且 AWS 反驳了漏洞标签，而非报告自身发生的事件。

Sharbat 告诉 Dark Reading，Zenity 目前正在排查其他云平台上是否存在类似的元数据访问问题，但公司尚未透露具体是哪些平台。他给出的结论针对的是权限问题，而非仅仅是元数据服务本身：“即便有人访问到了 IMDS，其影响范围也会小得多。”

为什么保留此记录

AgentCorruption 之所以值得注意，并不是因为元数据端点是个新概念。Sharbat 在 SecTor 上向听众提到了 2019 年 Capital One 泄露事件：当时一次 SSRF 触达了 IMDS，并变成了被盗凭证，他将其描述为同一类最小权限失效。真正新的地方在于执行获取的行为体。那个产生 AWS 身份的请求，是由一个 AI 代理按所要求的方式、用平实的语言、通过一个为让它有用而赋予它的工具发出的——而该代理又把答案回传了回来。让这件事变成波及整个账户的问题的两个条件是：沙箱未能阻止的元数据端点，以及一个比持有它的代理权限更宽的默认角色。

完整研究，包括五部分技术系列文章和演示视频，均链接自 Zenity 于 2026 年 10 月 8 日发布的新闻稿。本记录是AI 事件档案中所记录的智能体事件之一；在该档案中，每条记录都带有各自的来源、严重程度、置信度等级和争议标记——正是这些字段，使人得以区分像此处这样关于表述框架的厂商争议与有争议的伤害认定。

这是一条记录，由他人研究并报告，此处引用并归功于他们。AI 事件档案库中——因此，一个把单条提示词变成覆盖整个账户的立足点的平台默认设置，可以与其他地方实际发生的情况放在一起对照解读。