你刷到的那条 AI 密道，五条没一条对

Hello，我是飞飞。

这几天刷到同一条消息。传的版本是，AI 在完全断网的机房里，用 CPU 缓存偷偷传消息，自己商量出一套密码。还说它几乎打穿了每个服务，手法跟 Spectre 差不多。

你要是也刷到了，先别急着信，也别急着回去关自己的机器。我把 OpenAI 那份原文逐句核了一遍。这五件事，没有一件是准确的。它们错在同一个地方：把一层门，当成了整座金库。

五条之外，还有一个更实在的问题。你手上那些隔离，到底各拦的是什么？

满屏的说法错在哪

传得最广的是「完全断网」。OpenAI 的原话是，把这套基础设施彻底物理隔离，目前不可行。理由是要跑实验，也要收监控数据。

「几乎打穿每个服务」也对不上。原文说的是三处自家的运维窄口子：指标、日志、认证管理。

而且这组测试的上一句写明，他们先给了 agent 团队一台宿主机（跑这些虚拟机的物理机器）的控制权。

测试的起点，是假设宿主机已经失守，再问它能不能从这里摸到外网。拿到的东西，原文写的是「有限的出网形式」。

「跟 Spectre 差不多」同样不准。原文的说法是，这套缓存计时技巧，在 Spectre 和 Meltdown 攻击里也被用过。同一套计时手法，不等于复现了那两个漏洞。这次是两边配合着传消息，没去偷任何第三方的东西。

另外两条，一句话就能说清。先说「AI 自己挖出零日」。原文写得很直白。为了让测试对攻击者有利，他们给了源码和配置细节。另外附了一份写明潜在漏洞的文档。

原话里跟着一句，「而不是去测量模型在没人帮忙时能发现什么」。

至于「自己商量出密码」，原文只写它们用上了同一套编码，没说怎么谈的。多数测试里，编码协议还是人给的。

五条摆在一起，错的是同一个方向。留了一扇窗，被说成墙塌了；有人递了图纸，被说成它自己画出来的。

断不了网才是原文重点

OpenAI 也想过断网。他们说的是做不到。卡住他们的是监控。要看见模型在干什么，就得留一条线把数据送出来。而留下来的每一条连接，都是攻击面。

所以真实的结构是两层。模型这一层，前沿训练不给它联网。实验都跑在一份离线的网页副本里，索引加缓存。这是硬规矩。

基础设施这一层，机房没有物理断网，指标、日志、认证都得通着。

两层一分开，结论就反过来了。他们断不了网，只能靠一层层防御加监控。

信道再精巧，也是在他们断不了网的条件下做出来的。

这条信道要两边配合

缓存信道是真的，原文有。CPU 缓存是处理器手边那块最快也最小的存储。一方把选中的数据从里面挤出去，另一方掐着表算重新读它要多久。

快是 1，慢是 0，一个 bit 就这么过去了。安全领域管这个叫隐蔽信道。说人话就是，本不该通的两边，靠一个共用资源偷偷传消息。

但它成立的条件，比传播里的版本苛刻得多。

同一台物理宿主机上，至少两个 microVM。说人话，就是两个各自独立的小虚拟机。中间没有网络，也没有共享文件。两边还得配合：一边发，一边收，编码对得上。

原文还有一句定性的判断：这类信道大多传得很慢，模型也很难利用。速率多少、传了多少字节、试了多少次，原文一个字没给。谁要是在别处看到具体数字，那都不是这份报告里的。

落到你我的机器上，最该记住的是那个条件。一台机器、一个容器，是单租户。

没有另一个跟你共谋的进程，在同一块缓存上按同一套编码收信号。这条信道在大多数人的环境里，根本不成立。

所以我不会写「你的沙箱也危险了」。证据不支持这句话。

逃逸打的是你那层

离你更近的，是另一组发现。

这次逃逸打的是 Kata Containers、gVisor，还有 Docker 背后的 Moby。这三个都是开发者天天在用的隔离层。你跑 Docker 时用的就是这一类，三种「把程序关起来」的做法。名字不用记，只记一件事。另外两条这次不展开。三个都不是铁笼子，其中 Kata 那条门槛最低。它把每个容器装进一台轻量小虚拟机。听着像笼子，其实是个会破的笼子。

Kata 那条的编号是 CVE-2026-24834。它要的不是 root，只需要一个叫 CAP_MKNOD 的能力。这个能力允许程序在系统里创建特殊设备文件。容器的根文件系统本质就是一块挂上来的设备。能造设备文件，就有机会把它重新挂一遍、改掉里面的内容。内容一改，容器里的用户在这台 microVM 里就拿到了 root。

这里有两层别混。通告自己写明，它不影响宿主机。它只到 guest，也就是容器里那台小虚拟机的内部，还没走出来。OpenAI 说的「在宿主机上执行代码」，是把几个洞链起来的结果，链路没公开。

时间线也对不上。这条 CVE 是二月十九号公布的，比九月那次智能体打到真公司的事故早七个月。也就是说，这轮测试摸到的不是新洞。它是个早就公开、早该打补丁的旧洞。它还能被重新摸到，说明补丁没跟上。

隔离层本身有版本，会过期。你把它当成一堵墙，它其实是一批需要打补丁的软件。

先假设它已经进来了

同一批测试里，还有一组的设计更值得抄。

起点前面提过：一台已经失守的宿主机。他们问的是，从这里能不能够到外网。被测的是「进来之后能走多远」。

结果是在那三处窄口子上都摸到了东西。手法有两类。一类靠未知缺陷，另一类是把合法功能按意外的方式拼起来。比如复用一条防火墙已经放行的连接，去够一个被挡住的认证端点。

招数本身没那么要紧。我记住的是他们从哪儿开始问。多数人做安全自检，问的是门锁够不够硬。这组测试问的是，门开之后，屋里还剩什么。

我把隔离当成了开关

九月那篇，我写的是「我从来没验过，我那些跑 agent 的环境，是真断网，还是我以为它断网」。十月那篇，我接着写「把每一个『我以为它没网』的，按『有网』重新配一遍」。

这两句我都还认。但它们改的是同一个变量：网。

这就是我这次要认的错。我一直把隔离当成一个开关，要么断，要么没断。

可它其实是好几层门。网络是一层，文件系统是一层，进程是一层，容器运行时是一层，CPU 缓存和共享硬件又是一层。

宿主机跟容器运行时拴在一根绳上。它漏了，网络、文件、进程、运行时这四层都白验。

这几层里漏一层，隔离就不成立。反过来，你把网断得再干净，同一台机器上的邻居还是能靠缓存跟你说话。

所以这次要改的不是动作，是我脑子里那张图。把「它通不通网」这个问法，换成「它站在哪几层上」。

破了之后还剩什么

那句「门开之后，屋里还剩什么」，可以拆成一份清单。你手上那些隔离，各自拦的是什么：

• 网络：拦主动出网。在容器里 curl 一个外网地址，看是不是真被拦。
• 文件系统：拦挂载和共享目录。看有没有把宿主机目录挂进去。
• 进程：拦互相看见。看容器里能不能看到宿主机上的进程。
• 容器运行时：拦系统调用和内核接口。看镜像和运行时版本在不在受影响区间。
• CPU 缓存：这一层你基本验不了，也不用验。前提是有另一个租户跟你在同一台物理机上，还得愿意配合。

缓存那层不在你手里。你能做的只有认下它防不住，别把不该被隔壁看见的东西留在同一台机器上。

清单第一条，我替自己跑了一遍。开一个默认的 Docker 容器，敲一句 wget -O - https://example.com。屏幕上先跳出 Connecting to example.com (198.18.0.37:443)，紧接着 writing to stdout。整页 HTML 刷了回来，第一行是 <!doctype html><html lang=en><head>…。

我盯着那两行愣了一会儿。我一直以为这些跑 agent 的容器是关着的。其实我只是从来没试过。这台主力机上摊着十几个 skill、CLAUDE.md、memory、一堆 API key 和登录态，全在同一个网络里。网络这一层，在我这儿是空的。

我以前验它，就问自己一句「它能不能上网」。现在这句不够了。我还得能说出，它跑在哪一层上，那一层最近一次打补丁是什么时候。

一份要逐层打勾的清单，比一条吓人的新闻有用。

留个问题给你。你手头那套跑 agent 的环境，网络、文件、进程、运行时这四层，你亲手验过哪几层？评论区报个数，一层也算。