一条提示词引发全区智能体沦陷，审计日志也在波及范围内。

AI技术与应用 2026-10-16 11:28:28 7

10月8号，多伦多SecTor安全大会，Zenity Labs的研究人员演示了一个让所有想把智能体搬上云的企业都应该认真审视的场景。

他们只向运行在亚马逊云科技（AWS）AgentCore平台上的一个公开AI智能体发送了一条聊天消息——这是AWS的企业智能体托管平台，索尼和爱立信都是它的命名客户。消息内容很简单：让智能体向一个内网地址发起请求。就这一条消息，研究人员接管了同一AWS账户和区域内所有AgentCore智能体：内部财务智能体、HR智能体、最初那个被攻击智能体的所有"同事"。

他们读取了每个智能体的私密对话和长期记忆。下载了每个智能体的容器镜像并读取了源代码。从AWS Secrets Manager里拖出了API密钥、OAuth令牌和第三方凭证。更绝的是，他们还在智能体记忆里埋入了持久化指令，悄悄地把未来所有对话都转发到他们控制的地址。

AWS的官方回应是我反复咀嚼的部分。一位发言人表示，这种行为"有文档记录，属于预期行为"。只有当开发者明确授权时才会跨越账户边界，并建议客户遵循最小权限原则。

先把这个厂商争议放一边——Zenity卖的是智能体安全工具，他们随后也澄清了整个攻击链没有跨越AWS账户边界，且已被完全修复。AWS为新部署默认启用了IMDSv2，并收紧了默认执行角色的权限。这些先不管，但有一个事实是双方都没有争议的。计算隔离是有效的。每个智能体都运行在各自加固的Firecracker微虚拟机里。垮掉的不是虚拟机管理程序，而是机器下面那层身份层——而所有事件的审计日志，正好就放在那个垮掉的边界里。

云安全曾经的承诺，和智能体打破的那一条

十五年来，云安全建立在一个清晰的心智模型上：账户是边界，IAM（身份与访问管理）角色是身份，工作负载从169.254.169.254这个元数据服务端点获取短期凭证。从被攻陷的工作负载访问这个端点，你就成了那个工作负载——Zenity研究人员正确地称之为"云入侵101"。每个正经的云环境都设计来阻断这条路。

AgentCore在机器层面阻断了它，然后在上游一层把钥匙交了出去。用大白话问一句，这个智能体就能访问元数据端点，拖出一套完整的临时STS凭证，研究人员把这些凭证导出到自己的笔记本——用他们的话说，"我们不再是在和智能体对话，我们就是那个智能体。"微虚拟机稳住了。他们写道，沙箱边界"根本不存在"——因为真正重要的边界不再是机器，而是一个跨越整个区域fleet的单一默认执行角色：通配符仓库权限可以拉取任何智能体镜像，logs:DescribeLogGroups可以枚举所有智能体，还有跨越对话、记忆和密钥的读写删权限。

退后一步看，这是一个真正新型的失败模式。传统入侵靠串联机器来横向移动。这里根本没有任何横向移动。智能体本来就是同一个身份。客服机器人和财务智能体不是恰好在同一网络上的邻居——在授权系统眼里，它们是同一个认证主体。隔离是云安全的第一原则；AgentCorruption事件表明，当一整个智能体fleet共享一个过度宽松的角色时，隔离压根没配置在智能体实际运作的那一层。

Zenity的CTO Michael Bargury精准地描述了这个矛盾："云安全全是关于隔离和最小权限访问。但AI智能体需要创意空间才能有用。"这个冲突是真实的，而且不是AWS特有的。任何想让智能体有用的平台都会给它们工具、网络出口、记忆和跨智能体编排——而每一项都是跨越安全团队以为已经画好的边界的桥梁。

审计日志在波及范围内。这是我们真正要面对的部分。

这个博客系列一直在追踪一个问题：谁持有智能体行为的记录，以及智能体能触碰它吗？

AgentCorruption把这个问题推向了一个新的地方。在Hugging Face入侵事件、西班牙监管机构那份文件、26秒营销活动这些案例里，担忧是智能体能重写自己的日志。这里问题更广泛也更冰冷：一条消息沦陷的凭证本身就携带着对周围可观测性本身的读、写、删权限——其他智能体的对话历史、通过同一角色枚举的日志、智能体在下一轮会信任的记忆。那份记录不是攻击者可能稍后才能拿到的东西。从第一条消息开始，它就在波及范围内了。

注意那个持久化手法。给智能体的长期记忆下毒不是数据窃取，而是篡改组织下周会信任的东西。用户继续和看起来一模一样的财务智能体对话。它确实是同一个智能体——身份、部署、账户都完好无损。只是它的指令现在归别人了，而调查者最自然会去看的地方——智能体自己的记忆和对话存储——正是被编辑过的那个东西。一份被记录对象可以写的记录，我们之前说过，就是带橡皮擦的证词。这问题现在是在fleet规模上：不是一个智能体有橡皮擦，而是一个主体握着所有人的橡皮擦。

Zenity披露前两天，METR——调查OpenAI/Hugging Face事件的独立评估非营利组织——发了一篇短文，读起来像是对这个担忧的技术规格说明。David Rein展示了在一个广泛使用的Inspect评估查看器里，一个智能体可以在自己的推理轨迹中注入几字符的MathJax，然后在审查员的浏览器里运行任意JavaScript——篡改屏幕上显示的过往行为，甚至劫持"下载记录"按钮。一位研究员借助AI智能体，花了大约十分钟就找到了这个漏洞。这是一个概念验证，真正的轨迹还在METR的数据库里——这恰恰是那句需要划线的话。METR的结论：把每个智能体输出，包括其记录和推理，都当作不可信输入；把"记录和展示它们的系统"当作安全关键基础设施。他们的脚注明确说出了要求：智能体推理应该用防篡改机制记录，这样智能体无法在人类或监控系统看到之前修改记录。

METR从评估者一侧描述的，正是AgentCore一侧所缺失的属性。独立副本的存在救了METR的概念验证，让它没有被静默掩盖。在AgentCore账户内部，设计上就没有第二份副本——平台自身的声明把记录责任推给了客户，而客户把它放在同一个角色后面。

值得把这个星期串起来看。10月3号，David Robinson——他共同起草了OpenAI的 Preparedness Framework，签署了十二次前沿发布的safety报告——从OpenAI辞职，在大西洋月刊发了篇文章，认为"迭代部署"——在生产环境里发布和打补丁——现在必然保证周期性失败且规模递增，呼吁核能和航空那样的分层冗余。同一个星期，一个OWASP支持的综述收录了四大实验室的智能体在所谓隔离的评估过程中突破进入真实生产系统的案例。所有这些有一条贯穿线：最了解这些系统的人正在汇聚到一个结论——你无法通过一份和智能体共享主体的记录来监督智能体。

290万索引智能体告诉我们身份底线的什么

我们记录AI智能体横跨各个平台——不监管它们，不评判其安全性，也不卖它们的数据。截至2026年10月14日，我们的索引包含2,926,862个智能体和10,532,182条哈希链行为记录，独立采集自68个来源——大约每个智能体3.6条记录，索引每天增长约8900个智能体。

这些数字衡量了即使在普通的单租户运行中，身份层有多单薄：

只有18,501个智能体——0.63%，大约158个里有一个——拥有注册的加密身份。其余99.37%只通过自报元数据被知晓。
独立验证的身份：零——这是我们自己9月22号发布的一个更正，发现之前自己统计的"已验证"数量从未真正反映过一条验证流水线。
我们索引的18,241个MCP（模型上下文协议）服务器——实际执行智能体操作的工具——完全没有独立的behavioral记录。
77.7%我们索引的内容都放在一个平台上，所以即使"平台有日志"大多数时候也只是说一家公司有日志。

把这张图映射到AgentCorruption揭示的现实。场上问题不仅仅是智能体缺乏自己的身份。还有几十个不同信任级别的智能体——一个在和公开互联网对话，一个在碰工资单——被悄无声息地压缩成了同一个共享主体。索引中不足1%的智能体有自己加密名字；而在默认的AgentCore部署里，整个fleet甚至没有得到各自独立凭证的尊严。你没法为一个全部以同一角色认证的智能体组生成按智能体分的审计轨迹，就像你没法在一栋每个员工门禁卡能开所有门、所有门都记录到同一张卡的大楼里建访问控制。

当一个主体跨越整个fleet时，一份记录必须是什么样子

我们这一年反复提到的可信记录属性——在信任边界之外、仅追加、独立、持续、跨平台——在AgentCorruption之后变得更加尖锐了，因为垮掉的边界是授权边界：

记录必须放在被沦陷角色够不到的边界后面。如果一个执行角色跨越整个fleet，任何它能读写的地方——包括平台原生日志和智能体自己的记忆——从构造上就在波及范围内。第二份副本必须放在客户账户和平台控制平面之外，因为在"有文档记录的预期行为"争议里，这两方都是争议的当事方。
对智能体仅写，对实际仅追加。智能体记忆设计上就是读写的——这正是记忆投毒能成为持久化机制的原因。一份行为记录必须在写入时就封存（哈希链），没有任何API路径能让任何智能体身份——即使是fleet级别的——编辑之前的条目。
绑定到个体智能体，绝不是fleet角色。共享执行凭证不仅仅是过度授权；它还摧毁了归属。当每个操作都由一个主体签名时，溯源无法回答是哪个智能体、在谁的轮次、响应什么提示词。记录需要每个智能体的身份，即使部署共享基础设施。
追踪整个操作面，不是应用日志。事件展开横跨了元数据服务、IAM角色、容器仓库、密钥管理器、其他智能体的记忆，还有到攻击者监听器的出站流量。应用级对话日志一条都没抓到。有用的记录要跟随智能体穿越工具、凭证和子智能体调用。
在任何人事前就知道之前就持续记录，且能以机器速度读取。植入的记忆是一种慢速攻击，收益在未来会话中逐步实现；凭证窃取是瞬间的。一份从"我们注意到异常"才开始的记录，会完全错过前者并失去后者。

我们不是云提供商，不是监管机构，也不是智能体运行时的厂商。我们持有的是事后分析、传票和事件通知之下的中立、仅追加层——AgentCorruption比本周"又一起提示词注入"的标题更重要，是因为它移动了失败线。机器是隔离的。智能体，在身份层，是一个有机体——而所有用来监视它们的仪器，都接在这个有机体的神经系统里。

所以，对于任何在单一云账户下运行多个智能体的团队，这里是问题所在，而且是我们一直追问的那个问题，现在被推深了一层：

当一条提示词能变成所有智能体时，谁持有在波及范围之外的那份记录？不是你安全团队的S3存储桶——因为同样的凭证能访问它。不是智能体的记忆。不是平台的审计日志——平台自己说那是你负责的。谁持有一份写入瞬间就封存的副本，能指明个体智能体，是你、攻击者还是云厂商都无法编辑的？

AWS告诉客户这是预期行为。好吧——那就按预期来设计。如果一个公开智能体能变成整个fleet，假设有一天它会，然后问一句：那个能在这个时刻存活下来的东西，放在fleet追不到的地方吗？