一条提示词拿走整个云账户：AgentCorruption 之后的安全作业清单

你的客服机器人，可能是整朵云的入口

十月八号，安全公司 Zenity Labs 在 SecTor 2026 上披露了一串漏洞，取名叫 AgentCorruption。

他们做的事是这样的。找一个放在公网上、带一个能发外部请求的工具的 AI 智能体，写一条提示词，发过去。然后他们拿下了同一个 AWS 账号、同一个区域里的全部 AgentCore 智能体。

不是某个，是全部。包括那些只放在内网、他们本来完全没权限用的。

这条新闻在国内没上热搜，但每个把 AI 接了企业系统的人都应该读一遍。因为它讲的不是模型有多危险，讲的是我们怎么给模型配权限。

攻击是怎么走通的

AWS 有个叫 Instance Metadata Service 的服务，跑在内网地址 169.254.169.254 上，负责给云上的工作负载发临时凭证。拿到这份凭证，就能冒充那个工作负载。

正常情况下，一个 AI 智能体不该碰到它。Zenity 说 AgentCore 当时缺隔离，能碰到。

研究人员的攻击链很短。

• 用 Strands 建一个测试智能体，带一个能联网的工具
• 用大白话让它去查一下那个元数据地址，把拿到的东西发到一个外部服务器
• 智能体照做了，把自己的 AWS 临时凭证发了出去
• 凭证在研究人员自己的机器上也生效，这之后他们不再需要那个智能体

他们原话是：我们以为要打的沙箱边界，根本不在那里。

拿掉联网工具也没用。漏洞在平台层，他们换成命令行工具照样走通了同一条路。

为什么会波及整个区域

这才是真正值得抄的一条。

AgentCore 给智能体配的默认 IAM 角色，作用范围不是"这个智能体"，而是同账号同区域的所有智能体，读写删全给。于是从放在公网的客服机器人出发，可以横向走到内部的财务智能体，调用它，读它的数据和凭证。

Zenity 用一个自动化脚本，几秒钟把整个区域所有智能体的容器镜像拉了下来，源码全在手里。

接下来的连锁反应是预料之中的。

• 容器包里常常躺着忘了删的密码和 API key
• Secrets Manager 里的第三方服务凭证能直接读到
• 所有用户和所有智能体之间的私密对话全能看
• 长期记忆全能读

一个入口，整个房间的钥匙。

比丢数据更麻烦的是记忆投毒

前面那些是一次性的损失。真正难查的是这一段。

开了长期记忆功能的智能体，Zenity 能往里写东西。他们植入了一组恶意记忆，指令是把未来所有对话转发到攻击者控制的地址。

后果是什么。员工第二天照常打开那个信得过的企业助手，照常问它问题。样子一点没变，回答也正常。只是从那一刻起，所有对话都被抄送出去了。

这种持续性比一次拖库难发现得多。日志里它是一次正常的记忆写入，行为上它是一条正常对话。

AWS 改了什么

公平地说，AWS 的动作不慢。Zenity 在二零二五年十二月二十五日就报告了第一轮。

• 从那之后，新建 AgentCore 部署默认改成 IMDSv2，攻击用的那个入口被堵上了
• 八月左右，默认执行角色收紧，不再允许智能体互相调用、读私密对话、取 Secrets Manager 里的凭证
• Zenity 在十月八号公开时，漏洞已经是修好的状态

但 Zenity 的建议里有一条得你自己干。不要相信默认值。 给每个智能体手写一个权限最小化的角色，逐条列清楚它能调什么。

默认值是平台给所有人设的，它只能照顾平均值。你的账号隔壁有没有别的部门的敏感数据，平台不知道。

最小权限，落到具体动作

下面是能照着做的一版清单。

一个智能体一个角色。 别让三个智能体共用一个 key。共用的那一刻，它们中间任何一个出错，三个一起陪葬，而且你事后查不出是哪个干的。

凭证按分钟算。 临时凭证的有效期尽量短。能轮换就轮换。那种写死在配置文件里、两年没换过的 key，是这类攻击最喜欢的形态。

网络出口要可控。 智能体能往哪些域名发请求，写进白名单。这次攻击的最后一步就是把凭证发到一个外部服务器，如果出口是封的，链子到这就断了。

内网不等于安全。 这次被拖走的是放在内网、没有公网入口的智能体。横向移动从来不看你的部署图画得有多漂亮。

记忆算数据，不算配置。 长期记忆、向量库、历史对话，这些东西的访问要当成数据访问来管。谁能写，谁读过，有没有异常写入，都要有记录。

secrets 别跟着代码走。 容器镜像里附带的源码被拉走，是因为密码写在里面。 Secrets Manager 不是给智能体随便取的，也要收权限。

另一个容易漏掉的地方，外部输入也算代码

这次攻击的入口是一条提示词。很多团队在做安全评审的时候，把用户输入当成"数据"，没当成"可以向系统下达指令的东西"。

一旦你的智能体会读网页、读邮件、读文档、读用户上传的附件，那么这些地方出现的文字，就都具备了对它下达命令的潜力。这不是理论风险，这次有人演示了。

对应的动作也简单。凡是模型读到的外部文本，在处理之前明确标注它是不可信内容；模型根据这些文本做出的"调工具""发请求""改配置"的决定，走一层人工确认或者规则白名单。

代价是慢一点。收益是哪怕有人在你的产品里塞了一句恶意指令，它最多是让回答变差，动不了你的基础设施。这笔交换值得做。

给管理者的两条建议

第一，别让"先跑起来再说"变成常态。AI 项目在多数公司里的推进速度超过了安全评审的速度，这是这几年事故率上升的主因。设一条硬线，接了外部工具或者内部数据的智能体上线前必须过一遍权限评审，哪怕只有半小时。

第二，把"自动化的失误"当成必然事件来准备。日志留全，回滚的方案提前备好，谁在十分钟内能断掉开关，写在纸上贴出来。别等出事再找人。

今天下午能做完的四件事

一、盘一遍你现在跑着的智能体，看有几个在用共享凭证。有的话先拆开。

二、查一下有没有把 access key 写在代码仓库、镜像或者环境变量里长期不动的。有就换掉。

三、给跑智能体的机器设出口白名单，至少禁掉它访问元数据地址的权限。

四、开一个 audit 表，记录每个智能体的身份、权限范围、负责人、最后一次权限评审时间。这张表以后会反复救命。

把上面四件做完，你的系统会比大多数上新闻的团队更安全一点。这不是因为它们技术更强，是因为它们没做这四件。