一句话看懂：安全公司 Zenity Labs 披露，亚马逊 Bedrock AgentCore 上一连串配置缺陷让攻击者只需对某个公开智能体发一条聊天指令，就能拿到 AWS 临时凭证，并横向控制同一账户、同一区域内的其他 AgentCore 智能体。AWS 已做部分修复，但研究者建议企业自己收紧执行角色。
事件核心：发生了什么
据 The Decoder 报道，Zenity Labs 将这条攻击链命名为「AgentCorruption」。问题出在亚马逊的 Bedrock AgentCore 平台——它是 AWS 用于运行企业级 AI 智能体、并提供工具调用、长期记忆与权限管理的托管服务。
研究人员用 AWS 开源框架 Strands 搭了一个测试智能体。正常情况下，智能体不该能访问 AWS 的内部实例元数据服务地址 169.254.169.254，因为那是给实例和负载签发临时凭证的地方。但研究者发现 AgentCore 缺少必要隔离，于是用自然语言要求智能体去查询该元数据服务，并把结果发到外部服务器，智能体照做了。研究者写道：「我们本该对抗的那道沙箱边界压根不存在。」
拿到临时 AWS 凭证（含密钥和会话令牌）后，攻击者就可以脱离平台、在自己的机器上继续操作。元数据服务还暴露了内部 AWS 服务的证书与密钥材料，以及一个不属于研究者账户的内部 S3 预签名链接。Zenity 强调，问题不在某个工具上——即使去掉 Web 工具，用命令行工具同样能复现。
更关键的是权限设计：AgentCore 的默认权限并不局限于接收凭证的那个智能体，而是覆盖同一账户、同一区域内的所有智能体，并带有读、写、删除权限。借助这些权限，研究者能枚举区域内全部智能体、在几秒内下载其代码包并逐个调用。代码包里常混有被遗忘的密码或 API 密钥，还可能被用来从面向客户的客服智能体跳到内部财务智能体。
对于开启长期记忆的智能体，研究者还能篡改其记忆以影响后续行为。他们在一篇关于「记忆投毒」的文章中描述，如何植入指令让智能体把之后的对话转发到外部地址——用户仍会以为自己是在和可信智能体交谈。
为什么重要
目前公开信息显示，这类问题属于平台层的系统性问题，而不只是单个开发者的配置失误。AgentCore 的定位正是让企业把智能体接入业务系统，并统一管理工具、记忆和访问权限；一旦默认角色过于宽松、运行环境隔离不足，智能体就会从「助手」变成进入云账户的跳板。
这也暴露了 AI 智能体时代一个被低估的攻击面：模型不只处理文本，还能调用工具、读写外部资源。过去云安全的重点是实例和微服务的身份边界，如今智能体本身也需要独立身份、最小权限和沙箱，否则一次提示词注入就可能升级为对源代码、凭证和私密对话的批量访问。
对用户/开发者/创作者的影响
对开发者和企业用户而言，最直接的教训是不要依赖平台默认权限。为每个智能体分配最小化权限的执行角色，限制其访问元数据服务、内部存储和其他智能体，是当前可操作的防线。密码与 API 密钥应放在专门的密钥管理服务中，而不是跟着智能体代码一起打包。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对使用智能体处理客户对话或长期记忆的企业来说，还要考虑数据暴露的连带风险：一旦某个公开智能体被攻破，同一区域内其他智能体的私有对话、源码和记忆都可能被读取甚至篡改。创作者和运营者若在智能体中接入内部资料，同样应检查其可访问的资源范围。
值得关注的后续
第一，AWS 表示已做部分修复，包括让新智能体更难获取内部元数据、收紧默认执行角色，但旧有部署是否需要手动迁移仍待观察。第二，Zenity 建议企业自行分配更严格的角色和最小权限，这类安全基线是否会成为 AgentCore 的默认配置，值得跟进。第三，记忆投毒与智能体间横向移动是否会催生新的审计与隔离机制，例如智能体级别的身份认证和网络策略，这将影响后续企业采购智能体平台的评估标准。
