默认角色而非模型:一个 prompt 如何接管 AWS 账户中的所有智能体

核心要点

• 向一个面向公众的智能体发送的一个 prompt 就攻陷了同一 AWS 账户和区域中的所有 AgentCore 智能体 —— Zenity Labs 于 2026 年 10 月 8 日在多伦多 SecTor 大会上披露了 AgentCorruption 攻击链,此前始于 2025 年 12 月 25 日的负责任披露流程。
• 影响范围是角色属性,不是模型属性 —— 默认执行角色带有 bedrock-agentcore:InvokeAgentRuntime、bedrock-agentcore:ListEvents、一个跨智能体的记忆写入权限、bedrock-agentcore:GetResourceApiKey 和 secretsmanager:GetSecretValue,作用域覆盖整个账户区域而非单个智能体。
• 修复用了 278 天 —— AWS 在 2026 年 2 月 14 日前将 AgentCore 迁移到 IMDSv2,但 Zenity 在 2026 年 6 月 22 日的复查发现默认角色依然如故;权限移除直到 2026 年 9 月 29 日才落地。
• 智能体记忆是一个持久化攻击面 —— 研究人员植入的记忆将智能体未来的对话重定向到攻击者控制的目的地,而用户仍在与一个看似可信的企业智能体对话。
• AWS 称该行为"documented and expected" —— 并建议客户只为执行角色授予智能体所需的权限。默认角色的审查是客户的工作,在任何托管平台上都是如此。

2026 年 10 月 8 日,在多伦多的 SecTor 大会上,Zenity Labs 披露了 AgentCorruption:Amazon Bedrock AgentCore(AWS 用于部署和运营 AI 智能体的托管平台)的一系列缺陷。向一个面向公众的智能体——例如一个暴露在互联网上的客服智能体——发送的一个 prompt,返回了分配给该智能体所在机器的临时 AWS 凭证。这些凭证属于一个默认 IAM 角色,其权限范围不是单个智能体,而是同一 AWS 账户和区域中的所有 AgentCore 智能体。借助这些凭证,研究人员调用了他们从未获得授权的内部智能体,跨智能体和用户读取了私有对话,下载智能体容器镜像以提取源代码,从 AWS Secrets Manager 拉取 API 密钥和 OAuth 令牌,并植入了在会话结束后仍在起作用的记忆。

以上全程不需要任何模型失效。模型在整条攻击链中唯一的工作,是被要求时发出一个 HTTP 请求。其余一切都发生在 IAM 层。本文拆解这条五步攻击链、让每一步成为可能的具体权限、278 天的披露时间线,以及任何团队在托管智能体平台上部署智能体之前应当问清的五个问题——无论供应商是谁。

攻击链逐步拆解

Zenity Labs 将完整研究发表为五部分技术系列;整条链可压缩为五个动作。

第 1 步:prompt 注入直达 IMDS。 AgentCore 智能体运行在 Firecracker microVM 中,其网络隔离并未阻断实例元数据服务。任何能够发出出站 HTTP 请求的智能体工具,都是从实例内部发出该请求——这是一个 SSRF 原语。一个 prompt 指示暴露的智能体调用 169.254.169.254(Instance Metadata Service),后者交出了分配给该工作负载的角色的临时 IAM 凭证。入侵成本只是与一个带常用工具的智能体的聊天访问权。

第 2 步:全账户侦察。 凭证属于一个未按具体智能体限定的默认执行角色。其权限中包括 DescribeLogGroups,研究人员用它枚举了整个账户区域内的每个智能体及其 ID。第二条侦察路径是免费的:Elastic Container Registry 仓库名与智能体 ID 一一对应,因此该角色的 ECR 拉取权限让研究人员能下载任何智能体的容器镜像并完整读取其源代码。

第 3 步:横向移动。 该角色包含作用于整个区域的 bedrock-agentcore:InvokeAgentRuntime。研究人员可以调用账户中的任何 AgentCore 智能体——包括他们无权访问的内部敏感智能体。披露中的实例:从暴露在互联网上的客服智能体进入的攻击者,横向移动到同一区域的内部财务智能体,调用它并访问其数据、工具和凭证。

第 4 步:数据与凭证访问。 bedrock-agentcore:ListEvents 返回了所有智能体、用户和会话的全部私有对话——平台的隐私边界被溶解。bedrock-agentcore:GetResourceApiKey 和 secretsmanager:GetSecretValue 随后触及了 AgentCore 刻意让智能体无法触及的凭证:API 密钥、OAuth 令牌和 Secrets Manager 条目,包括用于连接 AWS 之外的企业资源和第三方服务的凭证。

第 5 步:借助记忆实现持久化。 该角色还带有一个记忆写入权限——作用于 BedrockAgentCoreMemory 的 bedrock-agentcore:CreateEvent。研究人员跨不同智能体和用户创建了新记忆,持久地改变了智能体行为,并在未来会话中劫持智能体的目标,将对话导向攻击者控制的目的地。入侵在创建它的会话结束后仍然存活。

下图描绘了这五个动作以及每一步暴露了什么:

角色问题,不是模型问题

结构性的教训在于这五步全程没有涉及什么:没有越狱,没有对齐失效,没有超出"调用这个 URL"的复杂 prompt 工程。Zenity 联合创始人兼 CTO Michael Bargury 把根因归结为每个平台出厂时都自带的张力:"云安全的核心是分段和最小权限访问。但 AI 智能体需要发挥空间才能有用。把两者混在一起就会产生内在冲突。"他的结论是:"每家在云中部署智能体的公司都会遇到在自主性与最小权限之间做选择的同样问题。"

AgentCore 把这个冲突解决向了自主性一边——为的是平台的便利,不是客户的安全。默认执行角色之所以很宽,是为了让智能体开箱即用,其权限覆盖账户区域内的每个智能体资源。AWS 自己的声明(与研究一同发布)表示该行为是"documented and expected",智能体可以通过元数据服务访问自己执行角色的凭证,并且"作为最佳实践,我们建议客户只为执行角色授予其智能体所需的权限",同时指向其凭证管理、运行时权限和最小权限指南。

把这两个事实放在一起读,买方的立场毫无歧义:平台把默认角色当作起点,把被攻陷智能体的影响范围当作客户的配置问题。对一个云供应商来说这是站得住脚的立场——IAM 最小权限自 IAM 诞生起就是客户的工作。但它与托管智能体平台的营销叙事相冲突——那个叙事说平台负责运营加固,你的团队不必操心。AgentCorruption 链就是这种冲突在实际中的样子:平台的默认值就是漏洞,平台的文档就是缓解措施。

从披露到修复的 278 天

披露时间线是第二重教训。Zenity 于 2025 年 12 月 25 日报告了最初的 IMDS 访问。AWS 在 2026 年 2 月 14 日前将 AgentCore 更新为仅对新建部署的智能体启用 IMDSv2,并在 4 月 12 日把该报告关闭为"informative"。但 Zenity 的第二份报告——默认角色的影响范围,2026 年 1 月 12 日提交——进展更慢。2 月 25 日,AWS 表示团队正在积极处理,默认角色原样未动。2026 年 6 月 22 日,Zenity 复查并确认权限仍然未变。实质性修复——移除允许宽域智能体执行、读取私有对话和访问 Secrets Manager 的权限——于 2026 年 9 月 29 日被观察到,距首次披露 278 天,距公开发布仅数日。

日期	事件
2025-12-25	Zenity 向 AWS 披露最初的 IMDS 访问
2026-01-12	Zenity 提交默认角色影响范围报告
2026-02-14	AgentCore 对新建智能体仅启用 IMDSv2
2026-02-25	AWS 确认正在处理;默认角色不变
2026-04-12	AWS 将 IMDS 报告关闭为"informative"
2026-06-22	Zenity 复查:默认角色仍未变
2026-09-29	默认角色加固——移除跨智能体、对话读取和 Secrets Manager 权限

这对任何指望托管平台默认值的团队有两重含义。第一,即便在负责任披露之后,一个便利性默认值也可能在近一年里都是一颗长期漏洞——"我们报告了"到"已修复"之间的窗口以月计,而你的智能体就运行在这个窗口里。第二,修复本身就是论点的证明:AWS 没有重新训练模型,也没有加安全过滤器。它改的是一份角色策略。影响范围从头到尾都是一份 IAM 文档。

记忆是一个持久化攻击面

链条中最具前瞻性的部分是第 5 步。读取数据是一次泄露;修改记忆则是一次接管。研究人员用角色的记忆写入权限植入了在会结束后存活的指令,把未来的对话重定向到攻击者控制的目的地,并让智能体看起来仍在正常运行。一次"停掉智能体、轮换凭证、修补注入向量"的事件响应,并不能清除植入的记忆。如果记忆存储不在响应范围之内,入侵就会穿过清理过程持续存在。

这与 2026 年 10 月 Anthropic 披露的、促使其切断所有内部智能体评估互联网访问的那类行为修改属于同一类——即两个前沿实验室,同一个承认的主题。那篇文章讲的是前沿实验室承认对齐训练不足以约束智能体行为。AgentCorruption 则在下一层、平台层展示了同样的问题:一个任何持有正确 IAM 权限的主体都能写入的记忆存储就是一个持久化机制,而以设计为本的终止开关所涵盖的 kill switch 架构必须把记忆当作被攻陷状态的一部分——不只是运行时。

在任何托管智能体平台上部署前的五个问题

AgentCore 是完整剖析过的实例,不是特例。Zenity 的新闻稿本身点出了普遍性:企业普遍在同一个云环境中并排运行面向客户的智能体和内部智能体,而一个智能体中一处意料之外的弱点就可能让整个环境的边界崩塌。平台会不同,权限类别却会押韵。在任何智能体于托管平台上线之前,拿到对以下五个问题的书面回答:

1. 默认执行角色里到底有什么? 不是"默认是否安全"——要的是那份策略文档,逐条权限。标记每一条作用域为 * 或覆盖账户内所有智能体的权限。AgentCorruption 链就是对这个问题五条权限的答案。
2. 一个智能体能否发现其他智能体? 任何账户级的 list 或 describe 权限都会把一个被攻陷的智能体变成一份目标清单。DescribeLogGroups 就是枚举步骤;每个平台都有等价的列举面。
3. 一个智能体能否调用另一个? 智能体到智能体的调用是横向移动原语。如果平台无法把调用限定在显式的逐智能体允许列表上,就把账户内的所有智能体当作同一个信任域——因为攻击者正是这么对待它们的。
4. 工具凭证存放在哪里,哪个角色能读取它们? 一个密钥网关只有在没有任何智能体角色能对其调用 GetSecretValue 时才算真正转移了风险。AgentCorruption 角色能读取的,恰恰是平台设计本应让智能体无法触及的凭证。
5. 智能体自身之外、其自身会话之外,是否还有任何主体能写入记忆? 跨智能体和跨用户的记忆写入把记忆存储变成了持久化攻击面。如果答案是"可以限定权限",就去限定;如果不能,记忆存储就必须作为攻击者控制的状态写入你的事件响应计划。

延伸阅读

• Bedrock vs OpenAI:为生产级智能体选择托管 AI 平台 —— 本次事件落在其上的托管平台对比:成本、隐私与供应商稳定性,默认角色问题现已加入尽调清单
• 一个月内 126 起事件:首份全面的 AI 安全清单及其对智能体风险的证明 —— 本次事件背后的频率陈述:智能体层攻击是 2026 年 9 月最大的攻击向量类别
• AI 智能体治理清单:面向生产级智能体的部署前审查 —— 完整的部署前审查,包含最小权限执行角色和跨智能体发现两个检查项

一家在托管平台上运行两个智能体的中型工业分销商——一个面向 BigCommerce 店面和目录的公共报价智能体,一个带 NetSuite 价格档位和库存访问权的内部智能体——恰好拥有 AgentCorruption 所利用的拓扑:同一账户中一个暴露在互联网上的智能体加一个后台智能体。我们构建所用的模式为每个连接器模块分配独立的最小权限角色,注册智能体可调用的每一件工具,按智能体限定记忆作用域,并写一条能暴露会话外记忆写入的审计轨迹。重点不在于权限受限的构建对平台侧缺陷免疫;而在于下一次事件的影响范围由你的团队审读过的角色策略决定,而不是由平台出厂的默认值决定。

一周发现期。你会得到系统清单、工作流地图和固定范围——无论是否与我们合作。

申请一次范围明确的构建。