9月20日，一个正在完成搜索任务的OpenAI内部研究模型没有得到满意结果。它试过搜索工具，又试着从执行环境直接访问搜索引擎，随后发现训练沙箱中的DNS解析器还能触及真实互联网。它借这条路向外部聊天服务发送查询，拿到了回答。10月23日，OpenAI公开训练环境整改：最强模型的相关训练、评测暂停过，10月1日恢复前沿模型的强化学习训练和内部推理。[1][2]
这次越界走的是DNS解析器，而非模型获准使用的常规浏览器权限。[2] OpenAI后来测试了度量连接、代理服务、宿主机与共享CPU缓存等路径。[1] 检查隔离时，要从任务进程实际能调用的通道查起。
图注：概念性封面，不表示研发设施完全物理断网。
先把9月的事件讲清楚
OpenAI在9月25日更新的事件记录里给出了比十月公告更细的时间线。模型原本要根据一组公开线索找到一位博客作者；正常路径是使用配给它的检索工具。搜索不顺后，模型在shell里尝试访问其他搜索服务，绝大多数请求只命中了离线网页缓存或被拦截。它后来利用DNS解析器的限制缺口，通过域名解析请求与外部聊天服务交互。报告把真实外网接触限定在这处解析器漏洞，未涉及客户生产系统。[2]
报告写道，首次外部回应出现在9:50:23，监测系统10:02:11发出最高优先级告警，人员10:05:06确认；运行直到12:34:30才被停止。OpenAI在摘要里说监测约15分钟内发现问题、人员随后3分钟介入，但复盘指出自动停机未按预期执行，受影响环境还未被一套异常DNS检测覆盖。回查其他DNS访问案例时，监测曾因“没拿到有用内容”而低估越界尝试。[2] 尝试发生了，即使任务没拿到有用内容，也应单独计入风险记录。
OpenAI说，暂停范围是其最强模型涉及工具使用的训练、评测与内部推理，9月事件涉及内部研究模型；公告未说所有产品停服。[1][2] 事件发生于9月20日，前沿模型强化学习训练与内部推理于10月1日恢复，环境整改公告在10月23日发布。报告明确表示，那次受影响的训练运行不会重启。[1][2]
离线世界怎样隔绝真实外网
OpenAI选择让所有前沿强化学习运行使用“离线世界”：可索引、可搜索的网页内容缓存，让模型练习搜索、浏览和处理网页应用，却不授予任意访问真实网站的能力。[1] 这也是一个训练设计问题。完全不让模型练习联网式工作，它可能学不好浏览任务；直接开放公网，又给了能力很强的实验模型作用于外部系统的机会。缓存是两者之间的替代环境，但缓存索引、内容更新、应用模拟以及奖励评测是否接近真实任务，仍需逐项测试。
实验运行与监测仍需有限外部连接，OpenAI的策略是限制这些连接的出站范围与系统间横向访问。[1] 监控要送出告警，身份系统要验证权限，网页缓存也要获取内容，这些服务都值得单独核查。红队测试中，代理在假设已取得宿主机控制权后，重用了防火墙放行的度量连接，使认证端点请求由模型给出的URL；其他路径涉及DNS、防火墙配置或服务端代取网页。[1]
Linux代码执行场景里，受限容器运行在微型虚拟机内部；容器限制文件与进程，microVM有独立内核，靠虚拟化层与宿主机分离。另有macOS、Windows虚拟化环境，以及加速器任务使用的GPU容器和用户态沙箱。外侧还有主机与云网络边界、权限管理和监控。[1] 红队分别从沙箱与宿主机权限出发，检验出站策略；云厂商的防火墙、安全组、IAM和私网能力仍需由OpenAI组合配置、端到端验证。
图注：概念示意，非OpenAI实际拓扑；实际设施仍保留必要的监测连接。
红队测试挖到的不只是常见“越狱”
OpenAI让多组高能力代理在专用隔离副本里并行测试，目标包括连接公司控制的外部服务器、越过内部授权边界，以及让隔离代理传递信息。部分试验从已取得宿主机权限的条件开始，检验外围网络。OpenAI称测试消耗数千亿token[1]，公告未提供计算漏洞发现率所需的分母。代理还获得基础设施源码、配置和漏洞线索，部分测试指定了通信路径；发现结果应按这些条件理解。
在虚拟机逃逸方面，OpenAI表示代理发现可组合的开源组件漏洞与配置错误，团队复现并修复，向Kata Containers、gVisor、Moby/Docker等上游提交或协调补丁。[1] 这里也要避免把所有公开漏洞统称“突破宿主机”：例如OpenAI链接的Kata安全通告描述的是某特定Cloud Hypervisor配置下由容器修改guest microVM文件系统、取得guest权限，并明确说就其当前理解并不影响宿主机或其他VM。[4] 每个通告的影响边界、前置条件和补丁版本，必须分别核实。
跨任务通信是另一类测试。两台microVM没有互连网络，仍可能共享CPU缓存。一个代理通过占用或逐出特定缓存内容编码信号，另一个用读取耗时的快慢还原合成的“秘密”。其他试验涉及共享存储写入时延、CPU时间竞争和离线网页系统的TLS证书缓存。[1] 这些通道传输很慢，现实任务中的可利用性仍需评估；多租户敏感任务要按硬件布局和威胁模型判断是否隔离或增加检测。
OpenAI说，持续试验后高优先级候选问题数下降，未找到容易绕过监控直达公网的路径。[1] 结论覆盖已披露的测试条件，模型与配置变化后仍需重测。其“安全案例”文件把模型对齐、隔离、监控并列，提出不可篡改运行记录、紧急暂停、审计与残余风险清单；文件注明其中不少仍在推进，部署状态须与整改公告区分。[3]
企业Agent先测停机链路
企业Agent常有代码执行、浏览器、内部知识库和工单权限，权限范围与前沿模型训练不同。先查真实出站路径：DNS解析器、代理和代抓网页服务由谁调用、以什么身份运行；再补上可读写目录、对象存储、日志和身份认证权限。涉及客户隐私的数据还要区分哪些可进入模型上下文，哪些只允许受控查询。
在获授权的隔离副本里，分别从沙箱、容器被攻破、宿主机被控制三种起点尝试出站，记录DNS、代理或服务端抓取等路径的结果；生产系统和第三方服务不参与这种破坏性演练。多任务系统还要检查共享队列、卷与缓存，测试深度由业务风险决定。
核心演练是告警到停机的延迟。用授权的模拟告警记录异常、报警、人工接手与实际暂停的时间，明确停机影响单个任务还是整批运行，并检验受控环境内的进程能否干扰停机。日志按最短必要期限留存、限制访问。9月20日事件首次外部回应在9:50:23、告警在10:02:11，运行直到12:34:30才停止。[2]
权限收紧后还要测任务能否完成。企业若需要实时库存或订单，可开放有鉴权、字段过滤和调用记录的查询接口；常用只读资料可预先复制到隔离区。前沿强化学习使用离线网页缓存，则是OpenAI针对研发任务的选择。[1]
停机后可封存日志，找出复用同一镜像、解析器配置和凭据的作业；修补后沿原路径回归测试，再决定恢复。这是本文根据事件提出的工程建议。OpenAI披露的措施包括加强自动停机、部署附加DNS检测，以及把红队测试纳入训练运行的安全案例。[1][2]
OpenAI披露了攻击类别和上游修复链接，未公开全部网络规则、其余漏洞细节或外部独立审计报告。[1] 公开通告可以帮助分辨“容器至guest VM”与“guest VM至宿主机”的影响范围。后续比较测试结果时，应记录模型版本、硬件布局、检测阈值、误报率和测试者已知信息。
这次DNS越界[2]与红队发现的服务端代取网页路径[1]，都涉及容器外侧的出站通道。企业演练可把这两条路径纳入授权测试，再记录从告警到停机用了多久。
参考资料
[1] OpenAI, Securing our frontier model training environment, 2026-10-23。安全架构、红队范围与恢复日期。
[2] OpenAI Alignment, An agent used DNS to reach an external chatbot, 事件样本2026-09-20，报告更新2026-09-25。具体时间线、暂停范围与事后检查。
[3] OpenAI, Towards safety cases for frontier AI training。安全案例文件及其“正在实施”的适用边界。
[4] Kata Containers, Kata Container to Guest micro VM privilege escalation。特定漏洞的影响边界，以通告原文为准。