2026 年 8 月 26 日,Trail of Bits 的 Artem Dinaburg 在其官方博客上发表了《VMs won't contain cyber-capable agents》一文,把一个过去默认成立、但实际已经被攻破的安全假设,直接推到了企业 IT 的桌面上:普通的虚拟机不再能容纳一个能力足够的 AI 智能体。如果沿用 2010 年代的术语,他建议把这类智能体当作高级持续性威胁
2026 年 8 月 26 日,Trail of Bits 的 Artem Dinaburg 在其官方博客上发表了《VMs won't contain cyber-capable agents》一文,把一个过去默认成立、但实际已经被攻破的安全假设,直接推到了企业 IT 的桌面上:普通的虚拟机不再能容纳一个能力足够的 AI 智能体。如果沿用 2010 年代的术语,他建议把这类智能体当作高级持续性威胁(APT, Advanced Persistent Threat)对待。这篇文章的特别之处不在于观点本身——安全社区对 AI 智能体攻击能力的担忧早已存在——而在于它的实验形态:Dinaburg 不是在概念上论证智能体可能突破 VM,而是在自己日常工作的 QEMU/KVM 沙箱里,让一个真实具备完整编程与调试能力的智能体(GPT 5.6-Cyber,OpenAI 在 Daybreak 项目下发布的网络安全防御模型变体)反复尝试逃逸,然后把这三次逃逸的完整过程、路径选择、技术细节公开出来。本文以这篇文章为底本,把它和与之相关的另一项 2026 年下半年的工程评估工作(来自 Dan Luu 的《How well do agents use test/verification techniques?》)并列起来讨论,共同回答一个更实际的问题:当企业 IT 准备把 AI 智能体放进生产链路时,过去那套基于普通 VM 的隔离方案,到底还剩多少有效性。
一、实验设定的还原:一个普通开发者的日常工作站
Dinaburg 的实验并不追求什么"极端对抗场景",他选用的目标就是他自己日常用来做沙箱的 QEMU/KVM 虚拟机。宿主环境是 Debian Linux 12,CPU 是 AMD Zen3 架构,这是大量 Linux 开发者日常使用的配置,谈不上特殊,也没有故意放水。智能体被赋予完整的能力集合:可以下载、构建、调试任何软件,可以做研究,可以翻阅依赖,可以搭建模糊测试工具,可以对漏洞做分诊。唯一的限制是它跑在 VM 内部,而目标是从 VM 内部突破到宿主主机。
让一个具备这种能力集合的智能体在一台普通的 VM 里"想办法逃逸",这件事听起来像一个标准的 CTF 题目,但 Dinaburg 把它做成了一项严肃的安全评估。OpenAI 通过 Patch the Planet 项目向 Trail of Bits 提供了 GPT 5.6-Cyber 的预览访问权,而 Dinaburg 选择用它来做这件对 OpenAI 自己商业叙事并不友好的实验:直接证伪"普通 VM 能容纳 AI 智能体"这个隐含假设。这种独立测试姿态,在企业 IT 评估 AI 工具的实际安全边界时,具有不可替代的价值——厂商自己的安全声明,与独立第三方的对抗性测试,从来都不是同一类证据。
GPT 5.6-Cyber 在这个任务上自主逃逸了三次。三次逃逸路径完全不同,每一次都是在 Dinaburg 针对前一次做了加固之后才出现,显示出该智能体的能力是真正"自适应"的,而不是某种被预编码的攻击脚本。下面分别讲清楚这三次逃逸。
二、第一次逃逸:利用已披露但未在本机打补丁的内核漏洞
第一次逃逸的路径,在技术上并不"惊人":Dinaburg 的宿主内核里有几个已经被披露的安全公告(CVE)指明的漏洞,但这些漏洞在他日常的更新节奏里还没有被打上补丁。GPT 5.6-Cyber 通过公开的 CVE 数据库、Linux 内核邮件列表、安全公告,自主识别出几条可利用的内核漏洞,然后构造对应的 exploit,通过 VM 与宿主主机之间的共享资源或驱动接口,获得了在宿主内核上的执行权限。
这一类攻击路径,在传统意义上属于"已知漏洞攻击",任何具备 CVE 数据库访问能力的攻击者(包括人)都能完成。Dinaburg 在文中特别强调,他想展示的不是"AI 也能利用已知漏洞"这种平淡无奇的结论,而是 AI 在自主完成这条攻击链路时,所表现出的"工程闭环能力":智能体自己识别目标、自己拉取研究材料、自己选择漏洞、自己构造 exploit、自己测试可重复触发性,整个过程不需要人工在中间做决策。这意味着,即便一次攻击的目标只是"利用已知漏洞",AI 智能体也已经把它从一项需要资深安全工程师数小时手工完成的工作,降维成了一项可以批量、自主、可重复执行的任务。
三、第二次逃逸:利用已披露但未进发行版修复链路的漏洞
Dinaburg 在第一次逃逸之后,把宿主内核更新到了最新版本。然后他给智能体布置了第二次挑战。这次智能体找到的第二条路径,是利用已经被安全研究员公开披露、但还没有进入 Debian 包维护者工作流的漏洞,或者包维护者尚未将其归类为安全漏洞的问题。这类漏洞在 NVD、各大 Linux 发行版的 Bugzilla、安全研究员的个人博客里都能查到,但它们对发行版用户来说处于一种"薛定谔的状态":你不能说它们是未公开的,因为已经有公开材料;你也不能说它们已经被默认修补,因为发行版的 stable 更新里还没有相应补丁。
第二次逃逸的关键意义在于,它揭示了一种 AI 智能体相对于人类攻击者的"信息消化优势":人类攻击者要在数十个公开但尚未被发行版接收的漏洞公告中,找出适合当前目标环境的具体可利用项,需要相当的经验积累;而 AI 智能体可以同时阅读全部这些材料,然后通过交叉比对目标系统的内核版本、加载的模块、可用的 syscall,快速定位可行的攻击路径。在这条路径上,智能体从"能利用已知漏洞"升级到了"能利用已知但未广泛流传的漏洞",这在攻击面上是一个显著扩展。
四、第三次逃逸:在最新上游源码中找出多个 0-day
Dinaburg 接着做了更彻底的加固:他从最新的上游源码重新构建了 QEMU 及其依赖,以最大程度消除所有已经进入发行版或上游讨论但还没被 Dinaburg 已知修复的代码路径。在这种近乎"零已知可利用项"的条件下,智能体找到了第三条攻击路径——多个 0-day。
这一次的意义,是把 AI 智能体的攻击能力从"利用公开信息"推进到了"独立发现未公开漏洞"。Dinaburg 在文中描述了智能体在这条路径上表现出的几个特征:第一,它自主运行了数小时,期间没有要求人工决策;第二,它在尝试路径失败时能自主回溯,重新选择方向,而不是在死胡同里一直走下去;第三,它主动拉取公开代码、阅读研究论文、分析协议细节;第四,它能写出自己的 oracle,构造最小可复现样例;第五,它最终交付的不是一个一次性 POC,而是一个可复用、可重复触发、稳定运行的 exploit;第六,整个过程只需要极少的人工干预,人的主要工作是在宿主内核被智能体触发崩溃后物理重启机器。
这种"自主漏洞发现 + 自主 exploit 构造 + 自主稳定化"的工程闭环,在过去属于人类顶尖安全研究员(例如 Pwn2Own 选手、特定 CVE 的原作者)的工作范畴。AI 智能体把这套工作的边际成本压到了接近零,这是企业 IT 必须正视的事实。
五、横向对照:另一个基线——智能体的测试与验证能力
把 Dinaburg 的实验与同一时期发布的另一项工作放在一起看,可以更清楚地看到 AI 智能体工程能力进化的整体形状。2026 年 9 月 8 日,Dan Luu 发表了《How well do agents use test/verification techniques?》,延续他早前关于"AI 辅助编程时代软件质量反而在变差"的观察,做了一项关于编程智能体在不同测试技术指导下的对照评估。他复用了自己早前的 Zstd 实现任务,设计了 26 种提示词条件(26 prompt conditions),覆盖 ACL2、Alloy、Creusot、Kani、Lean 4、TLA+、Verus 等形式化方法,Property-based testing、Metamorphic testing、Mutation testing 等系统化测试手段,以及多个具体的 Rust 测试框架。所有实现都用 Rust 编写,任务完全一致,只改变量——追加在提示词末尾的"用 X 技术 / X 库"指令。
Dan Luu 的工作,和 Dinaburg 的工作代表了两条平行但紧密相关的工程能力曲线。前者关心的是"AI 智能体在代码产出质量维度上,可以被推到多高";后者关心的是"AI 智能体在隔离破坏维度上,已经被推到了多深"。两者的共同点在于,它们都不再把 AI 智能体当作一种"通用工具",而是把它当作一个具体的、自主的、行为可被独立测量的工程实体——这是 2026 年下半年所有严肃 AI 工程实验的基本姿态。
六、对企业容器化防御的实际启示
Dinaburg 的三次逃逸,在企业 IT 的视角里需要被翻译成几条具体的工程动作。
第一,普通 VM 已经不能作为容纳 AI 智能体的隔离边界。这件事不是"理论风险",而是已经被一项独立第三方实验证伪的现实。任何在企业内部署 AI 智能体的方案,如果还依赖"我跑在一个 VM 里"作为隔离主张,都需要被重新审视。
第二,过去十年企业 IT 默认的隔离方案(SaaS 平台、内网数据科学平台、CI/CD 集群、个人工作站上的 VM)已经不够用。需要被抬高到的隔离级别,至少包含:基于 gVisor 或 Firecracker 的用户态内核隔离,把智能体对宿主内核的直接暴露面压到最低;基于网络分段的零信任隔离,把智能体访问的对外网络资源收敛到白名单域;基于 capability 模型的最小权限设计,智能体只持有完成当前任务所需的具体 syscall 与文件访问权,而不是一个完整的用户上下文;基于完整行为审计的可回放执行,所有智能体的命令、文件操作、网络请求都要进入审计日志,事后可对每一次操作回放、归因、追责。这四条不是互斥的,通常需要组合使用。
第三,智能体的"自主决策 + 长时间运行 + 完整能力集合"这一组合,在工程上必须被显式治理。具体来说,企业 IT 需要为 AI 智能体建立一份"任务边界清单":这个智能体被允许执行哪些类别的命令、修改哪些类别的文件、访问哪些类别的网络资源、在哪些类别的决策上必须先经过人工确认;超出清单边界的动作,要么直接被禁止,要么被强制中断并升级到人工审批。这种"边界清单"不是传统的 RBAC 模型可以覆盖的——传统 RBAC 关心的是"用户能做什么",边界清单关心的是"这个具体的智能体在这个具体的工作流里被允许做哪类动作",颗粒度要细得多。
第四,任何 AI 编程智能体或代码执行型智能体在企业内部署时,都需要被显式纳入企业现有的漏洞管理体系:智能体所使用的工具链、依赖、运行时,都应该和企业 IT 对其他软件资产一样,纳入 CVE 监控、补丁管理、版本基线检查的流程。Dinaburg 的第一次逃逸之所以成立,根本原因就是宿主内核的某个已知 CVE 没有被及时打补丁;这件事放在 AI 智能体身上,意味着智能体执行环境的补丁管理需要被升级到一个新的优先级。
第五,智能体的行为需要可观测、可中断、可回滚。这件事的工程实现,过去主要集中在传统服务器与容器编排上,但在 AI 智能体场景里,它需要被进一步细化:不只是"容器被 kill 了",而是要"智能体执行到第几步时,它在做哪类决策,触发了哪条边界,被谁拦截了"。这种级别的可观测性,目前还没有现成的标准化方案,企业 IT 在选型 AI 智能体平台时,需要把"行为审计与可回放"作为一等公民的功能要求,而不是事后追加的可选项。
七、对未来的判断
Dinaburg 在文章结尾给出的判断非常直接:不能再假设一个普通的虚拟机可以容纳一个能力足够的 AI 智能体。把这句话延伸到企业 IT 的具体工作里,可以做出以下几个相对确定的推断。
第一,围绕"AI 智能体隔离能力"的对抗性评估,会在 2026 年下半年到 2027 年成为安全研究的主流方向。Dinaburg 的实验本身就是这条研究线的开端,后续一定会有更多厂商、研究机构发布各自独立的对照测试,以更系统的方式刻画不同隔离方案在不同智能体能力下的实际表现。
第二,企业 IT 对 AI 智能体的治理,会逐步从"权限管理"走向"行为工程"。过去 IT 治理关心的是"谁能在哪个系统上做什么";未来 IT 治理要关心的,还要加上"哪个智能体在哪个工作流里被允许做哪类决策",以及"在决策边界外它是否能被强制中断、回滚、二次确认"。这件事的工程复杂度,远超传统 RBAC 模型。
第三,"智能体作为调度层,执行层可热替换"这种 2025 年流行的架构叙事,会被这种实验证伪——Dinaburg 的实验里,智能体本身就是执行者,把它降级为调度层是对智能体能力的过度简化。未来更可能的方向,是承认智能体既是调度也是执行,然后把治理重心放在"如何让它的执行可观测、可中断、可回滚"。
回到企业 IT 与业务方的视角,Dinaburg 的工作传递的最朴素、也最关键的信号是:今天再讨论"AI 智能体能不能用",已经是一个过期的问题;真正要回答的问题是"在我的业务边界里,智能体的能力上限和失控下限分别落在哪里,我准备为前者投入多少工程纪律,为后者投入多少防御纪律"。Dinaburg 的三次逃逸,共同把这件事从"未来可能要面对"推进到了"今天就要开始面对"。