AgentCorruption：公开 Agent 拿到的云身份，为什么能打开其他 Agent 的门

一、客服只接了一句话，云权限却跟着走了

设想一个部署场景：公司把客服 Agent 放在公网，把财务 Agent 留在内部。访客本来只能问客服问题，客服却为了执行请求，替访客访问了运行环境里的身份服务。接下来，访客拿着客服的云身份去敲财务系统的门。这个例子解释的是权限关系，不代表某家公司已经发生事故。

2026 年 10 月 8 日，Zenity Labs 公布了 AgentCorruption 系列研究。在 Amazon Bedrock AgentCore 测试环境里，研究者从公开 Agent 取得执行角色的临时凭据，再把访问范围扩展到同一 AWS 账号、同一区域的其他 Agent。研究总览同时记录了 AWS 后续调整；不能把历史演示直接当成今天所有部署的状态。

真正被搬走的是云身份，对话只是拿到身份的入口。

AgentCore 是 AWS 托管 Agent 的运行平台。应用可以给 Agent 接入网络请求或命令工具，让它查资料、调用接口。这里的执行角色，就是应用在云服务里被允许做哪些事的身份，权限由身份与访问管理系统 IAM 决定。

研究者在启用相关工具的 Agent 中，让请求发往实例元数据服务 IMDS。它是运行环境内部提供配置和临时身份信息的服务。当工具没有拦住这类目的地，外部用户就能借服务器的网络位置访问内部端点，这类行为称为服务器端请求伪造，也就是 SSRF。

演示中，Agent 把身份信息返回给研究者。研究者随后在自己的终端验证了这些凭据可以代表该执行角色发起云 API 请求。到这一步，后续动作已经不需要继续说服同一个模型。初始访问技术稿提供了过程和配置前提。

看清三个边界，才能理解为什么一个聊天窗口会影响其他应用：

这三步不能混在一起。模型服从了一次请求，并不自动意味着整片环境失守；能触及多少资源，还要看拿到的身份被授予了多少权限。反过来，强大的虚拟机隔离也不能替代 API 授权：攻击者用合法凭据访问另一个资源时，决定结果的是服务的权限检查。

注意：此处的“其他 Agent”有账号、区域、角色权限和工具能力等前提。公开系列没有给出所有生产部署的受影响比例，也不是证明攻击者可以跨任意 AWS 客户账号访问。

今天的第一步，是在控制台打开公网 Agent 实际绑定的执行角色，核对它能否调用其他运行实例、读取其他记忆资源或访问无关凭据。记录具体资源范围，别只看角色名称，也别仅检查模型提示词里有没有写“禁止泄露”。

二、私有 Agent 的门，开在权限策略里

想象客服进程持有一把工作钥匙。若这把钥匙只开客服自己的资料柜，身份泄露仍然严重，但影响相对明确。若同一把钥匙还能开财务、其他用户会话和连接器密钥柜，入口的规模就无法代表损失的规模。

Zenity 的角色分析展示了这种放大过程：日志组名称帮助识别 Agent 和记忆资源；历史执行角色的权限又允许调用其他运行实例、获取会话事件。研究者在内部账务 Agent 上演示了通过工具读取文件。角色与会话技术稿列出了当时的资源通配范围。

会话按用户和会话编号组织，并不等于每个调用者只能读自己的记录。应用分组解决“数据放在哪里”，授权检查解决“谁能取走”。若云角色已经可以访问广泛记忆资源，仅靠用户编号把数据分开，还不足以阻断持有这个角色的请求。

要验证的不是“页面上写着私有”，而是公开 Agent 的身份能否操作这份私有资源。

这里还出现了第二种风险：拥有写入会话事件的权限，可以改变 Agent 下次看到的上下文。若应用把伪造事件当成可信历史，判断依据就可能被污染。研究中的读、写、删权限是不同能力，评估时必须分别检查，不能因为撤掉读取权限就默认其他能力也消失。

但这是一条有修复时间线的历史攻击链。研究总览记载：AWS 回复称，自 2026 年 2 月 14 日起，新部署 Agent 使用 IMDSv2；研究者在 9 月 29 日复查时，观察到默认执行角色已经明显收紧。AWS 对初始元数据访问报告的结案定性是“informative”，与研究方的漏洞表述并不完全一致。

IMDSv2 引入了获取元数据前的令牌流程，但不能由“用了 v2”这一句话推导所有工具和权限都安全。这里也没有证据说明每份旧角色或自定义策略都会随默认模板自动改写，应检查自己正在使用的配置。

按下面的顺序做一次受控检查，结果比一句“已用最新版本”更具体：

1. 列出公开 Agent 绑定的角色、可用工具，以及它确实需要的运行实例、记忆和连接器资源。
2. 比对策略里的资源通配符与这份清单，特别关注调用其他实例、记忆读取和写入、密钥读取能力。
3. 在授权测试环境，用无敏感内容的隔离资源验证跨 Agent 请求会被拒绝，并留存拒绝证据。
4. 同时验证网络工具不能访问不需要的内部目的地，覆盖命令工具和重定向路径，再确认正常业务仍能运行。

这是本文基于攻击链提出的工程检查顺序，不是研究者已经替每个读者完成的测试。网络限制缩小拿到身份的机会，资源授权缩小身份泄露后的范围；两项都应该有自己的验证结果。

三、会话事件怎样变成下一次对话的“记忆”

为什么一条被写进会话的指示，能在下一次对话继续影响 Agent？

CreateEvent 并不直接覆盖任意长期记忆。它写入会话事件，后面还要经过提取、存储和检索：哪一步会把外来指示变成“用户一直这样要求”？

连接器密钥已经放进 Secrets Manager，为什么还要检查公开 Agent 是否有直接读取权？

这两条路径的验证，要回到写入授权、记忆来源和凭据范围，分别留下证据。对 Agent 云身份这类问题，也可以在 云栈社区 继续跟进讨论。