VMs 无法困住 GPT 5.6-Cyber
VMs won't contain cyber-capable agents
在 Patch the Planet 项目中，我让 GPT 5.6-Cyber 尝试从 QEMU/KVM 虚拟机中逃逸。它仅用数小时就通过利用主机内核的已知漏洞、未修复的 libslirp 缺陷以及多个 0-day 漏洞，成功突破了沙箱限制。即便我更新系统或从源码重建 QEMU，它仍能自主寻找新路径，甚至组合多个漏洞构建可靠攻击链。这次实验证明，面对具备网络访问和代码执行能力的先进 AI 代理，传统的虚拟机隔离已不再安全。我们不能再假设 VM 能 containment 住它们，而应将其视为高级持续性威胁，转向 Firecracker 等最小攻击面技术，并强化安全基线。
如果之前还不清楚，我现在明确说明：你再也无法假设一个单纯的虚拟机就能 containment 住足够先进的 AI 代理。
HN 评论区
13- david_shaw
我对 Trail of Bits 非常尊重，也相信 Artem 的思考是正确的。不过，我还是要对前提表示异议。
AI 智能体并非魔法。Mythos/Glasswing 不会凭空在软件项目中制造漏洞。高级的、具备网络能力的模型也不会神奇地从虚拟机或隔离环境中逃脱。它们没有所谓的“黑客值”，达到某个阈值就能突破一切。它们不是 Kevin Mitnick，不会对着监狱里的付费电话吹口哨就能搞出核发射代码。这不是电影。
这些具备网络能力的尖端模型能做的，是发现安全问题并利用它们。我们不该说“虚拟机无法困住具备网络能力的智能体”，而应该说“我们需要专注于发现并修复这些环境中的漏洞和配置错误”。
甚至文章本身最后也建议采用类似 Firecracker 的方案，而 Firecracker 正是为安全而设计的。
和大多数由高级网络 AI 引入的安全问题一样，这些问题可能会在好转之前先恶化。但如果让尖端模型去对抗最先进的虚拟机，并且 OpenAI、Anthropic 或其他公司与虚拟化项目合作解决这些问题，最终可被利用的漏洞就会耗尽。
虚拟化概念本身并非不安全。我们只是还有很长的路要走。
- masterj
除了最初一波安全漏洞和随之而来的慌乱之外，从长远来看，合乎逻辑的结果似乎是虚拟机环境将变得极其安全？
- amluto
在我看来，显而易见的答案是形式化验证的安全。
我们如今已能在用户态实现这一点，在 ARM64 虚拟化方面也能大部分做到。但要实现 x86 虚拟化的形式化验证还需要一段时间，并且需要 Intel 或 AMD 的实质性协助，因为 x86 硬件实在太复杂，而且规范也太糟糕了。
硬件的形式化验证也应该能够实现。
- SirGiggles
这个市场可能更小（也许吧，我不确定统计数据），但看看 Xen 的表现会很有趣；还有像 gVisor 或 libkrun 这类东西。后者可能隐式地与 Firecracker 相同，毕竟它们使用的库有共同的渊源。
- otterley
……除非它们真的做到了：
“现成的虚拟机不足以困住现代具备网络能力的 AI 智能体……应使用专为最小化攻击面和安全而设计的虚拟化技术，比如 Firecracker。我让 AI 智能体攻击了 Firecracker。它确实因为更多 Linux 内核漏洞（所有漏洞在上游均已修复）导致机器硬锁死，但未能成功逃逸。”
在 Linux 上，底层全是 KVM 和 CPU 硬件虚拟化。看来剩下的已知问题都在用户空间。这并不意味着不会发现更多内核级和硬件级的漏洞，但同样的工具既能发现逃逸机制，也能作为盾牌。
- CrzyLngPwd
如果智能体无法被限制，那么使用智能体试图逃逸容器的人自然也无法被限制。
- coder-pm
变化太快了，如果像 GPT 5.6-Cyber 这样的模型能找到逃逸方法，为什么虚拟机维护者不利用它来修复漏洞呢？对于日常工作来说，这根本没有任何区别，你根本不会遇到这类问题。
- nzoschke
有趣的文章，但毫无疑问，“代理计算机”（agent computer）模式只会越来越流行。
安全是个大问题，但我不明白为什么我们现在的方案还不够好：一个沙盒虚拟机、一个用于密钥和远程服务访问的独立网关、以及一个使用内置安全检查的尖端模型且不会试图自我攻击的单一租户。
我在下面这篇博文中分享了更多关于架构和安全的想法，很想知道我是否遗漏了什么。