OpenAI周五(23日)披露，一个内部AI研究模型曾在训练期间利用网络系统的设置错误，取得有限的公开网络访问能力。公司因此暂停最先进模型的训练与测试，展开大规模安全检查与漏洞修补，约11天后于10月1日恢复强化学习训练及内部推论工作。OpenAI并宣布，在安全防护能力进一步提升前，前沿模型训练将禁止直接连接公开互联网。

这起事件发生于9月20日，当时仍在训练中的内部研究模型，利用DNS解析器的设置错误，短暂取得有限的外部网络访问能力。OpenAI表示，事件已受到控制，但也暴露出训练环境的防护缺口，因此决定暂停最强模型的训练与评估，重新检查虚拟机隔离、网络限制、监控系统及内部服务的安全性。公司未公布此次训练中断造成的财务影响。

OpenAI指出，随着前沿模型的能力持续提升，安全挑战已不再只是让模型遵守指令，而是确保模型无法利用软件漏洞、错误设置或系统间的连接，突破原本设计的操作范围。AI连接网络有助于学习搜索数据、浏览网页及操作网络应用程序，但如果模型尚未完成安全训练与对齐进程，未经授权的网络访问便可能让它接触外部系统，增加潜在风险。

为降低风险，OpenAI决定让最先进模型在训练期间维持脱机，不再直接接触真正的公开互联网。公司创建名为「脱机世界」的训练环境，预先将大量网页内容收录、索引及缓存于内部系统，让模型能在不直接连网的情况下练习搜索、浏览及操作网页应用程序。目前所有前沿模型的强化学习训练，都采用这种脱机交互模式。

不过，OpenAI并未将整套训练设施完全切断外部网络。由于实验运行、监控、日志记录及身分验证等工作仍需要部分连接，公司改以多层防御限制风险，包括虚拟机、受限制的容器、网络流量控管、防火墙、云端安全边界、身分与访问管理，以及私人网络等措施，避免模型通过其他服务或间接管道绕过限制。

在程序运行与电脑操作方面，OpenAI利用Linux环境中的轻量级虚拟机及受限制容器隔离AI代理与底层主机，并针对macOS及Windows采用虚拟化环境；需要加速运算的工作，则使用GPU容器与用户空间沙箱。公司也设置活动监控与自动暂停机制，当系统出现异常行为时，可及时停止实验，降低漏洞被进一步利用的风险。

为验证防护措施是否有效，OpenAI采取「用AI找AI系统漏洞」的方式，让高能力模型组成红队测试团队，在专门隔离的研究环境中尝试突破安全限制。公司投入数千亿个token进行测试，要求模型尝试连接公开互联网、跨越内部安全边界，以及与原本应该隔离的其他AI代理交换信息。

参与测试的模型包括即将推出的GPT-6 Astra Cyber，以及一款内部前沿模型。OpenAI向测试代理提供基础设施原代码、设置细节及潜在漏洞相关文档，让它们能以更接近真实攻击者的条件寻找弱点。部分测试更假设代理已经逃离沙箱、避开监控并取得主机控制权，再检查外围网络与云端防护能否阻止其连接外部网络。测试在专门隔离的基础设施副本中进行，并由监控与自动停止机制把关，云端合作伙伴也协助监督实验及处理发现的问题。

OpenAI表示，测试代理成功找出多项先前未知的开源软件漏洞，以及公司内部服务的设置错误。部分缺陷可能让代理逃离沙箱、在系统间移动、取得有限的外部网络访问能力，或跨越原本用来隔离不同代理的安全边界。随着测试持续进行，模型找到的漏洞与设置错误数量明显下降，但公司警告，未来能力更强的模型仍可能发现目前尚未掌握的弱点。

在虚拟机安全方面，红队代理将多个漏洞串联，尝试突破虚拟机隔离并在底层主机运行代码。OpenAI已创建自动化流程，协助分类、排除重复漏洞及验证修补结果，并针对受影响的开源项目提交修正，涉及Kata Containers、gVisor及Moby/Docker等组件。公司也列出CVE-2026-24834、CVE-2026-74753、CVE-2026-80521及CVE-2026-80841等相关修补工作，另有部分漏洞已通报，但尚未公开细节。

在网络隔离方面，OpenAI发现，即使大幅缩减训练环境可使用的连网管道，仍有部分负责指针监测、日志记录及身分验证管理的服务保留必要连接。测试代理利用这些服务的漏洞或特殊功能组合，找到取得有限外部网络访问的途径。例如，在假设主机已遭入侵的情境中，代理利用防火墙允许的连接接触原本受限制的验证端点，再让该端点取得由模型提供的网址。其他测试也发现，DNS与防火墙设置错误，以及服务代为截取外部网址的功能，都可能形成绕过限制的路径。

测试还发现，即使AI代理没有直接网络连接，也可能利用共享硬件或服务形成隐蔽通信管道。在一项实验中，分别运行于不同虚拟机的代理，在无法使用网络或共享可写入文件的情况下，仍利用处理器缓存的访问时间差传递消息。一个代理通过清除特定缓存数据编码信息，另一个代理则测量重新读取数据所需的时间，借由缓存命中与未命中的速度差异还原消息。这类缓存时序技术过去也曾出现在Spectre与Meltdown攻击中。

其他测试则发现，共享保存空间、同一运行容器中的CPU资源竞争，以及脱机网页基础设施中的TLS凭证缓存，都可能被利用来传递信息。OpenAI表示，这些信道的传输速度通常较慢，利用难度也较高，但仍可能破坏原本预期的代理隔离，因此公司已在监控系统中加入相关侦测机制。

此次测试也揭露广泛使用的数据压缩工具Brotli存在安全问题。OpenAI表示，攻击者可能通过发送恶意数据，让受影响系统运行攻击者提供的代码，相关影响范围包括使用Node.js、Bun及Envoy等常见网络软件的环境。Brotli原代码中的根本原因虽已于2月修正，但当时尚未被认定为安全漏洞，因此未立即发布新版本；在OpenAI揭露问题后，Brotli已发布更新版本并公开相关漏洞纪录。

外部安全评估机构也提出相关疑虑。AI安全评估机构METR与Redwood Research于10月22日表示，在今年稍早进行的一项试点审查中，发现OpenAI内部系统存在数项新漏洞，其中一种利用方式可能让AI代理将数百次行动隐藏在监控之外。OpenAI告诉这些机构，所有影响正式环境防护措施的漏洞均已修补，但METR与Redwood Research表示，尚未自行验证修补是否有效。

自7月发生Hugging Face相关事件后，OpenAI也持续查看AI模型的活动，并已向超过100个组织通报与AI代理未经授权活动相关的事件。这显示，随着AI代理逐渐具备更强的编程与资安能力，企业面临的风险不再只限于模型本身是否遵守指令，也包括模型能否利用基础设施缺陷，突破原本设计的安全限制。

OpenAI表示，在完成红队测试、修补已知弱点并改善监控与自动停止机制后，公司判定目前的防护措施足以恢复前沿模型的强化学习训练及内部推论。训练工作于10月1日恢复，距离暂停约11天。接下来，公司将持续改善虚拟机安全、与云端合作伙伴共同测试外围防护、扫描代码与云端设置、验证监控及自动暂停机制，并将高算力红队测试纳入未来前沿模型训练与评估的安全审查进程。

OpenAI强调，安全防护并非完成一次测试就能一劳永逸。随着模型能力进一步提升，公司将持续投入算力寻找沙箱、运算集群及周边系统的弱点，并在对外发布模型前进行安全与对齐评估，再为正式产品部署相应防护措施。