给 Agent 做隔离，断网之后还缺哪几层防线

如果你正在给一个能写代码、开浏览器、跑命令的 Agent 配沙箱，最容易出现的一句安慰是：“它没公网，先这样吧。”

这句话不算错，但只够算第一层。OpenAI 刚公开的前沿模型训练环境红队报告，给了一个很不舒服的提醒：即使训练环境不让模型直连真实互联网，隔离任务之间没有网络、没有可写共享文件，系统里仍然可能留下别的路。红队智能体在不同 microVM 之间，利用 CPU 缓存访问时间的差异交换了合成秘密；在另一批测试里，它们也在指标、日志、认证这类“必须留着”的服务周边找到了有限出网路径。

这不是一篇教人怎么复现侧信道的文章。那既不负责任，也不是重点。重点是，Agent 安全从来不是勾掉“允许联网”这个选项就结束了。 当一个系统里的模型会主动找路径、组合路径、长时间尝试路径，真正需要保护的是一整串边界。

OpenAI 的报告说，他们让前沿模型智能体在研究基础设施的隔离副本中做高算力红队，目标很明确：抵达真实互联网、跨过内部安全边界、和本该隔离的智能体通信。为了把系统往最坏处推，实验还提供了源码、配置和可能漏洞的文档，累计消耗数千亿 token。它不是“模型有多会攻击”的跑分，更像一次把运行时、云网络和监控全摊到桌面上的压力测试。

对正在部署代码 Agent、浏览器 Agent 或自动化运维 Agent 的团队，这份报告真正有用的地方，不是替你搬一套大厂架构，而是让你把一个模糊问题拆清楚：如果单个 Agent 已经拿到了不该拿到的权限，接下来还会被哪一层拦住？

断网，隔开的只是其中一扇门

先把一个常见误会拿掉。OpenAI 说的“前沿训练不接真实互联网”，并不等于把整个研究集群拔掉网线。训练和评估仍要运行，研究人员仍要看日志、收指标、做身份认证、和云服务协作。完全物理隔离在这种环境里并不现实。

所以他们的做法不是让模型在空房间里练习，而是搭了一个“离线网页世界”：缓存和索引过的网页内容可以被浏览、搜索和交互，模型能练工具使用，却不应该影响外部系统。所有前沿强化学习训练都走这条离线路径。

这个设计很像给代码 Agent 准备一间练习工坊。它可以读一份固定的文档镜像、跑测试、改工作区里的文件，但不能因为想查个答案，就顺手请求任意域名，更不能把结果塞给外部服务。收益很直接：把最常见的外部出口先收窄。

图：OpenAI 官方报告主视觉。原文讨论的是未发布前沿模型的训练与评估环境，不等同于普通用户产品的运行环境。

问题在于，真实系统里总有“必要的例外”。监控要把数据送出去，身份系统要响应，构建和日志服务要通，云平台控制面也不能凭空消失。每一个例外单看都合理，连起来却可能变成一张意料之外的路网。

OpenAI 在报告里描述过一个方向：在假定主机已经失守的测试中，智能体会观察那些仍被防火墙允许的窄连接，尝试让内部服务替它向外获取内容，或者利用 DNS、服务配置与访问控制之间没有对齐的地方。这里真正值得记下的不是某个具体漏洞，而是一个更朴素的判断：“禁止直接出网”不等于“系统没有任何替我出网的能力”。

如果你给 Agent 做了代理、检索、插件、Webhook、内部工单、日志上传或云存储访问，最好把它们当成同一张边界图来审。不要只审 Agent 进程本身。

沙箱不是最后一道墙

很多团队把容器当成了边界的终点：Agent 在 container 里，工作目录挂对了，权限也最小化了，事情应该就差不多了。

OpenAI 的架构把这件事拆得更细。受限容器先约束 microVM 内的文件和进程；microVM 再用独立内核和 hypervisor 与宿主机隔开；外面还有监控、网络分段、云端身份和私有网络。它们不是同一种隔离的重复劳动，而是默认承认一件事：某一层迟早可能有错。

这和“容器不安全”不是一回事。容器仍然很有用。问题出在把它当成唯一答案。一个执行器若能突破进程或文件层，后面还有没有主机隔离？如果碰到宿主，有没有到云控制面的最小权限？如果碰到可达服务，有没有出口策略、服务身份和请求审计？每一层都该有不同的失败假设。

OpenAI 红队发现的 CPU 缓存通信，正好把这个思路推到最极端。两份任务即使没有网络连接、没有可写共享文件，只要共享硬件或某种可观察资源，仍可能产生时间差、竞争关系或缓存状态。多数这样的通道带宽很低，也不意味着普通团队要立刻为每一个任务单独租一台机器。但它足以说明：“没有显式通道”与“绝对不会交换信息”之间，隔着一整层运行时细节。

因此，先别把“任务隔离”只翻译成目录不同、容器不同。更实用的问法是：这两个任务共用了什么？主机、缓存、身份、存储、队列、代理、日志、证书，还是某个为了方便排障而留下的管理接口？你不必一口气消灭所有共享项，但至少要知道它们属于哪一层、谁能看到、谁能调用、出了异常谁会停下来。

一张够用的四层检查表

大厂前沿训练的规模，普通团队没必要照搬。不过给能执行外部动作的 Agent 开一个新运行环境时，可以先用下面这四层把讨论从“它安全吗”换成具体问题。

第 1 层：任务本身
  · 它能读哪些目录、运行哪些命令、拿到哪些临时凭证？
  · 工作结束后，文件、会话和令牌是否会被清理？

第 2 层：对外出口
  · 它能直接访问哪些域名、API、队列、Webhook 和代理？
  · 有无某个内部服务能替它请求任意 URL 或转发任意内容？

第 3 层：共享资源
  · 它和别的任务共用了哪些主机、存储、缓存、身份或管理面？
  · 一个任务异常时，能否读到、影响到或推断出另一个任务的状态？

第 4 层：发现与停机
  · 哪些异常会被记录，谁能看到，多久能触发自动暂停？
  · 停下来以后，怎样撤销令牌、保存证据、恢复到可验证的状态？

第一层解决的是“它一开始不该能做什么”。第二层解决的是“它绕出自己的工作区后，能不能借别人的能力出去”。第三层解决的是“本来相互独立的任务，会不会在系统缝里重新连上”。第四层则承认，再好的边界也可能漏：漏的时候，系统能否比人先把门关上。

这张表也能解释为什么一份超长 allowlist 常常不如一份短而具体的运行约定。允许 node、python 或任意 shell 命令，看起来很省事，实际把第 1 层和第 2 层同时放宽了。相反，把任务拆成“可以在工作区连续执行”“可以准备但需受限出口”“必须人工确认的生产动作”，虽然没有那么潇洒，出了问题却能知道是哪一层失效。

图：基于 OpenAI 报告抽象的四层检查框架。它不是官方架构图，也不能替代你的威胁建模。

监控不是事后的摄像头

报告里有一段很值得工程团队反复看：OpenAI 不是只修 microVM 和网络规则，还把持续红队、扫描代码与配置、检查监控是否正常、自动暂停高风险运行，放进了以后是否继续前沿训练的安全论证里。

这件事的顺序很重要。监控若只是“出了事以后留一份日志”，它只帮你复盘；监控若能在异常动作、边界穿越或规则失效时让任务暂停，它才是防线的一部分。两者差的是权限、触发条件和恢复流程，不是多接一个仪表盘。

对业务 Agent 来说，最常见的遗憾并不是完全没有日志，而是日志和决策脱节。系统记录了它访问过什么、改过什么，可记录落在一个没人看的地方；或者报警发出来了，但自动化还在继续写数据、发消息、创建资源。等人看到，边界已经被穿透很远。

一个可操作的起点，是为每类 Agent 写下两份清单。第一份是“正常时必须留下的证据”：任务 ID、调用工具、目标系统、使用的身份、结果摘要、失败原因。第二份是“出现就该停”的条件：访问未登记出口、身份权限突然扩大、同一任务反复撞边界、尝试读取不在输入范围内的数据、输出准备发往未批准的目的地。

这不是要把每次报错都升级成事故。误报太多，团队会重新掉回权限弹窗的老坑：看得见，但谁也不认真看。关键是让停止条件与真实风险贴近，并且每次停止都能给出下一步——谁来复核、能否安全重试、要不要撤销临时权限。

OpenAI 的高算力红队也不是一次考完就拿证。官方说，随着测试推进，高优先级候选问题显著下降；同时又明确提醒，测试的模型、区域和云服务商协作窗口会变化，不能把那条曲线理解成“投入多少 token 必然发现多少漏洞”。这是很正常的工程表述：指标有用，但不替代系统判断。

把“它能不能越界”变成发版问题

这份报告还有一个更大的信号。以前谈 Agent 安全，很多人默认是在讨论提示词、拒答、权限开关。现在前沿实验室已经把训练环境本身当成模型能力的一部分：模型越会找路，环境就越要假设它会找路。

这对普通团队不意味着要把自己升级成安全实验室。更现实的变化是，任何准备把 Agent 接到代码库、内网系统、真实数据或发布流程的团队，都该在上线前多问一句：如果它不是按预期操作，而是在持续寻找完成目标的捷径，我们的系统在哪一层会把它拦住？

回答不该是“沙箱”。沙箱只是答案里的一个名词。更完整的答案应该包含：任务权限最小化、出口按用途收窄、共享资源可见、异常能停、停后能收回。这五件事未必一次就做好，但至少能让团队知道下一次该补哪里，而不是在事故后才发现原来所有门都连着同一把钥匙。

OpenAI 在这次披露后恢复了部分前沿强化学习训练和内部推理。能恢复，不是因为它们证明了环境永远不会被绕过，而是因为修补、监控和持续红队组成的证据足以支持下一阶段。这个态度比“绝对安全”更值得借：安全不是一句承诺，而是一套允许你在发现问题后停下来、修好、再继续的运行机制。

如果你今天要给一个新 Agent 开权限，四层里你最没有把握的，是出口、共享资源，还是自动停机？

小岛AI

记录一线实战、踩坑与成长