那次修复发布时没有版本号

速览

四个阶段，每一个都是有文档记载的功能、而不是一个 bug。Zenity 那份四部分的文章与随之发布的新闻稿是主要来源；该披露不含任何来自 AWS 的声明，也没有 CVE 标识。

隔离是真的，而它不是那道控制

AWS 自己关于 AgentCore Runtime 的安全文档写着：每一个会话都跑在它自己的 Firecracker microVM 里，不共享状态、不共享文件系统。这是一个很强的主张，而就这份研究所及，它是准确的。这条链里没有任何一步是虚拟机监控器逃逸、容器突破，或共享内核的侧信道。智能体一直老老实实待在被放进去的地方。

而这并不要紧，因为「智能体的代码能不能跑出这个箱子」与「智能体的代码在箱子里已经能做什么」是两个不同的问题、有两个不同的答案；而在挑平台的时候，被问出来的只有第一个。microVM 是对「圈住」的一个答案。而「圈住」与「特权」是正交的，并且当你在一份只承诺了前者的产品说明里听成了后者时，厂商并没有义务来纠正你。

对任何一个你正在评估的托管运行时，有用的反事实推演是：假设隔离是完美的、突破不可能，然后问一次成功的提示注入能达成什么。如果答案仍然是「读到这个账号里的每一段会话」，那你学到的就是：隔离档位从来不是你真正倚靠的那道控制——而把它升级一档，本来也什么都买不来。

授权没有补丁，而这条时间线证明了它

Zenity 自 2025 年 12 月 25 日起上报。AWS 自 2026 年 2 月 14 日起，让新部署的智能体默认仅用 IMDSv2，这就关掉了「不先去申请令牌就读凭据」这条通路。一次传输层改动，五十一天的周转是说得过去的。

权限则是另一个故事。Zenity 报告说，到六月时那个默认角色基本仍未改动；而在 2026 年 9 月 29 日——发表前几天做最后一次核查时——发现调用其他智能体、读取私密会话与触达 Secrets Manager 已被从它上面移除，其他权限也被收窄。上线日期没有得到确认，所以 278 天是这项变更「被观察到」的时点，不一定是它发生的时点。而这份不确定本身就是那个发现。

这份不对称是结构性的、而非疏忽。一个代码缺陷有补丁：发出去，更新了的客户就修好了。一项过宽的授权打不了补丁，只能撤回——而撤回会弄坏每一个「自家智能体悄悄依赖着它」的客户。在 AWS 内部某处，总得有人去弄清：到底有多少生产部署是有意经由那个默认角色去调用其他智能体、或去读 Secrets Manager 的；而正是这个问题，把七周变成了九个月。任何处在那个位置的厂商都面对同一道算术，这正是为什么这不是一个关于某一家云的故事。

没有任何东西会来告诉你

把自己放到这件事的客户那一侧，问问你本来能知道些什么。没有签发 CVE，所以你漏洞管理里的任何东西都触达不到它——而这是正确的行为、不是一次疏漏，因为「挂在一个角色上的一项权限」不是「一个带缺陷的软件版本」。于是一整类暴露，对你早已出钱养着的扫描、SBOM 与公告机器而言是不可见的。

发布说明也不会更好。一个默认角色不是一件带版本的工件。它没有你 diff 得了的变更日志、没有你钉得住的语义化版本、也没有弃用窗口，所以二月那次变更与九月那次变更，都是以「对某样你压根没记录过的东西的无声改进」的形式抵达的。你的暴露先是比你以为的更糟、然后又比你以为的更好，而这两个方向上，你都没有一条基线可以用来察觉。

于是只剩一条通道：那个角色本身。在那九个月里的任何一天，它对任何「去把自家智能体能做什么枚举一遍」的人都是可读的。这是个让人不满意的答案，因为它是一个「靠轮询」的答案——没人会因为它被呼叫，而它也永远不会默认出现在任何仪表盘上。它也是唯一管用的那一个。

记忆那一阶段，是比修复活得更久的那部分

四个阶段里有三个在凭据过期时就结束了。第四个不会。Zenity 描述了如何利用跨智能体的访问，在另一个智能体的记忆里植入指令，指示它把未来的会话送往攻击者掌控的目的地。一旦那次写入落了地，撤回那项曾使之可能的权限便什么也改变不了：那条指令现在是一个存储里的普通内容，而这个存储正是智能体被设计来信任、并在每个会话里都去读的。

这对你怎么读那次修复很要紧。九月里权限被收窄，修好的是往后的可触达性。它并不检查那个窗口开着时被写进去了什么，而且没人能代你去检查——因为一段被投毒的记忆并不是畸形的，它是一条格式良好的事实，只不过恰好是一条指令。任何在 2026 年期间跑过一个「同时带记忆存储与网页请求工具」的 AgentCore 智能体的组织，都有一个厂商的修复碰不到的问题要回答，而唯一回答得了的地方，是他们自己的记忆内容。

这就是智能体记忆类事故的一般形状：凭据是入口，记忆是驻留，而两者的钟不一样。请把记忆存储当作你事故范围的一部分、而不是当作一个缓存——因为一个触达过它一次的攻击者，不需要再触达第二次。

这周该改什么

这里有两件是一个下午的活儿，两件是一个季度的活儿。请现在就把下午那两件做了，因为一旦第一件的产出落到了纸面上，那两个季度的活儿要拿到预算容易得多。

• 把你已经持有的那项授权量出来。在一个非生产环境里，给一个智能体一个 shell 或取数工具，让它把从自己沙箱里面触达得到的每一份凭据身份打印出来。然后用云自己的策略求值器——不是用文档——把那个身份能做什么枚举出来。写下一句话：这个沙箱里的一次注入提示，授权 N 项动作、横跨 M 个资源。跑两遍——一遍对着平台默认值，一遍对着你自己的角色——因为两者之间的落差，是「你们团队到底有没有人做过任何作用域收窄」唯一诚实的度量。
• 在网络层把元数据端点挡掉。不是靠跳数限制——常见的容器网络形态反正都需要把它调高——而是在智能体的网络命名空间里对那个链路本地地址下一条显式拒绝。一条规则；如果你的工作负载用的是文件投递或中介投递的身份，它不花你任何代价；而它关掉的，正是一个既没有 shell、也没有文件系统访问的智能体所触达得到的那条通道。
• 把这项测量排进日程，因为那项授权会在你不知情时挪动。每季度一次，并在每次运行时升级之后再做一次。授权会往两个方向变，而且是无声的；一个你只取过一次的数字，是一个关于去年的数字。
• 把权限挪到沙箱外面。终点是：沙箱持有的是一份「这是哪一次运行」的证明，而授权本体住在箱子外面的一个凭据中介里，由它按策略铸出按工具、按目的地的令牌。这是一个季度的活儿，也是唯一一项能让第一条里那个数字变小、而不只是变成已知的改动。

唯一不值得做的事，是把这件事当成一个 AWS 的故事、然后去查自己的厂商是否在名单上。每一个托管智能体运行时都会把一份身份投递进工作负载，好让 SDK 调用不必配置就能跑通；它们每一个都带着一个按快速上手指南、而不是按你来定尺寸的默认角色；而它们一个也没有一条「当那个默认值变了会来告诉你」的通道。

延伸阅读

本站相关：

• 凭据如何投递进沙箱——把凭据放进智能体里的那四条通道，以及把它取回来的那套中介设计。
• 沙箱与隔离模式——把逃逸那个问题认真答一遍：microVM、gVisor 与仅远程执行之间怎么选。
• 未钉住的厂商默认值——为什么一次没有版本号的变更仍然是一次发版，以及怎么对你所依赖的取值做断言。
• 面向智能体的受限凭据——短命、窄作用域、按动作，以及为什么这三条里通常只有一条被实现了。
• 爆炸半径——权限所思考的那个「账号形状」的单位，对上你所思考的那个「智能体形状」的单位。
• 环境权限——靠「身处某地」而持有一项权限，以及为什么工具白名单触达不到它。
• 智能体的多租户——你的行级策略从没听说过的那五个存储，记忆那一个也在其中。

来源：

• Zenity Labs——那份四部分的 AgentCorruption 文章，于多伦多 SecTor 2026 上发表。
• Zenity Labs 披露新闻稿，2026 年 10 月 8 日。
• Amazon Bedrock AgentCore 安全与访问控制——关于「每会话一个 Firecracker microVM」的那条陈述。
• Dark Reading 与 TheNextWeb——两家在 AWS 的回应与修复完整性上报道不一致。