一个提示词，就足以让攻击者从单个暴露的 AI Agent 出发，接管同一 AWS 账户下的全部 Agent。

发生了什么

据 The Decoder 报道，Zenity Labs 的研究人员在 Amazon Bedrock AgentCore 上发现了一个提权路径：只要账户与区域内存在一个可被公开访问的 Agent，攻击者就能借助一个提示词实现横向移动，最终控制该账户与区域内的所有 AgentCore Agent。

问题的根源不在提示词本身，而在权限边界。研究显示，这些 Agent 能够不受限制地访问 AWS 的一个内部接口，而该接口的用途正是签发临时云凭证。换句话说，Agent 天然握有一把通往云账户核心权限的钥匙，且没有足够的隔离来阻止它被诱导使用。

AWS 在收到报告后已修复该问题，并大幅收紧了 Agent 的默认权限。

为什么重要

这起事件的价值不在于攻击手法有多复杂，而在于它暴露了 AI Agent 落地过程中一个被反复低估的结构性问题：Agent 不是普通应用，它是一个会自主调用工具、执行多步操作的执行体。

传统云安全模型假设调用方是确定性的代码，权限可以按最小必要原则静态划定。但 Agent 的行为由自然语言驱动，输入即控制流。当 Agent 同时具备「可被外部输入影响」和「可访问高权限内部接口」两个条件时，提示词注入就不再是内容层面的骚扰，而是直接等价于凭证窃取。

更值得警惕的是横向移动的规模。单个 Agent 被攻陷并不稀奇，但一个 Agent 能触达同账户同区域内的所有 Agent，意味着 Agent 之间共享的运行时环境、角色信任关系和凭证分发机制，正在成为新的攻击面。AgentCore 这类托管平台把部署门槛降到极低，也把配置失误的代价同步放大。

影响与看点

对开发者而言，最直接的提醒是：不要把 Agent 的默认权限当作安全边界。托管平台给出的开箱即用配置，往往为了降低上手难度而预留了过宽的权限，默认值不等于安全值。上线前应显式审查 Agent 可访问的接口范围，尤其是任何与凭证、元数据、角色扮演相关的内部端点。

对平台方而言，这再次说明 Agent 运行时的隔离设计需要独立于传统 IAM 模型重新思考。临时凭证的签发接口不应被 Agent 直接触达，或者至少需要额外的、无法被提示词绕过的上下文约束。

对使用方而言，公开可访问的 Agent 应被视为暴露在互联网上的服务端点，而非内部工具。一个对外可交互的 Agent，其风险等级等同于一个对外开放的 API。

我的判断是：随着 Agent 从演示走向生产，提示词注入会从「模型安全问题」逐步归类为「云基础设施安全问题」。这次漏洞被快速修复是好事，但它更像一个开端——Agent 权限模型的标准与最佳实践，目前仍处于空白状态。