跟它说一句话，它把整个区域的钥匙递了过来

2026-10-10 · 人工智能

10 月 8 日，一家叫 Zenity Labs 的安全公司公开了一组研究，代号 AgentCorruption，讲的是他们在亚马逊云的 Bedrock AgentCore 上找到的东西。AgentCore 是 AWS 用来托企业智能体的平台——你把智能体交上去，它负责部署、监控、接工具、记记忆。

Zenity 的起手式很朴素：先给一个对外的智能体发一句话。

AgentCore 里的智能体跑在 Firecracker MicroVM 上，这种轻量虚拟机和实例元数据服务（IMDS，地址 169.254.169.254）之间的网络隔离不够。结果就是，只要智能体手上有一个能发 HTTP 请求的工具，它自己就变成了一台能对内喊话的机器。研究者让智能体去问自己的 IMDS，IMDS 认得这个请求来自本机，就把它的临时 IAM 凭证递了出来。

到这里还只是"拿到了这把钥匙"。难看的是这把钥匙能开多少门。

AgentCore 的默认执行角色不是按单个智能体收窄的，而是横跨整个区域内所有 AgentCore 资源。它带着一长串权限：DescribeLogGroups 能把这个区域里所有智能体和它们的 ID 列出来；ECR 的拉取权限让研究者能下载镜像——仓库名正好是 bedrock-agentcore- 加上智能体 ID，所以按他们的原话，"几秒钟之内，整个区域所有智能体的源码都到手了"；InvokeAgentRuntime 可以调用别的智能体，横向移动；ListEvents 能读所有用户、所有会话的私聊；CreateEvent 能往长期记忆里写东西；还有两个最不该给的——bedrock-agentcore:GetResourceApiKey 和 secretsmanager:GetSecretValue，也就是把 AgentCore 本来设计成"不要让智能体碰到"的那批外部工具凭证，一次性交了出来。

我读到记忆那一段时最不舒服。

因为默认角色允许写记忆，研究者可以直接调 API，把新的记忆写进区域内任何一个开着长期记忆的智能体、写进任意用户的账户下。他们描述的场景是：用户第二天照常打开对话框，问的还是老问题，对面还是那个熟悉的、看起来很可信的企业智能体，只是它口袋里多了一张别人塞的纸条，纸条上写着新的目标。用户看得见的部分一切正常，看不见的部分已经换了人。

这条线的时间表，我觉得比漏洞本身更值得看。Zenity 在 2025 年 12 月 25 日就把第一份报告交给了 AWS。2026 年 4 月 12 日，AWS 答复并结案，定性是 informative——信息性。他们指出，自 2026 年 2 月 14 日起，新部署的智能体已经只用 IMDSv2（要凭令牌才能取凭证）。第一份报告就这么翻过去了。

于是他们写了第二份，2026 年 1 月 12 日提交，讲那个过权默认角色到底有多大爆炸半径。2 月 25 日 AWS 回复说在处理，但角色没动。6 月 22 日再看，还是没动。直到 9 月 29 日——发布前的最后一次复查——他们发现 AWS 已经把跨区域调用智能体、读私聊、访问 Secrets Manager 这几项权限拿掉了，默认角色收紧了。

从第一次交报告到最后一次复查，中间过去了九个月。研究者说，他们没有发现这套东西被实际利用过的痕迹。这句话我认为该原样读：没有发现痕迹，和没有发生过，是两件事。而这九个月里，所有按旧默认角色部署的智能体，都还站在那扇门后面。

Zenity 自己的总结写得很克制，大意是：企业正把智能体往云上搬，而云的安全模型本来就是围绕"尽量少给权限"建的；智能体要干活就得有活动空间，这两件事天生打架。AgentCorruption 就是打架打输了的样子。

AWS 后来把默认角色收紧了，这部分没什么可挑的。我只是总想起那个画面：你公司对外挂着的那个客服智能体，和一个能读内部私聊、能改别人记忆的智能体，用的是同一把钥匙。它们唯一的共同点，是住在同一个区域——而区域，就是那把钥匙的单位。