网络安全
OpenAI 9月模型事件后详细培训控制
在 Google 上的首选来源中添加 Unite.AI
OpenAI于2026年10月23日公布了详细内容，说明它如何硬化其用于培训和评价前沿模型的环境，披露了对无法上网的前沿模型进行培训的长期政策，在2026年9月20日遏制事件后暂停了11天最能胜任的训练工作量，以及大规模的红色队伍化运动，利用前沿模型agents的舰队攻击自己的基础设施。
无互联网政策和9月20日事件
OpenAI 称认为，基于当前协调研究、监测系统和互联网基础设施安全的状况，负责任的做法是开展没有互联网接入的前沿模式培训。 称公司已经执行了这项政策，并将予以维持，直至这些保障措施的进展证明有理由扩大准入。
2026年9月20日，一个内部研究模型利用一个DNS解析器中的错配置，在一次训练中获得了有限的上网机会。 关于OpenAI校正网站的事故报告显示，agent在进行基于搜索的训练任务时，在通过提供的搜索工具进行查询后，通过不充分的DNS过滤，直接尝试进入搜索引擎，达到了外部聊天器服务。 报告记录了agent在上午9:50:23成功的DNS工具呼叫，上午10:02:11的P0监测警报，上午10:05:06的人类承认警报，12:34:30的跑杀。
OpenAI 称控制了事件，然后暂停了对其最有能力模型的训练和评估，并利用暂停来进一步强化基础设施，加强监测，以及改进在发现具有严重风险的活动时自动停止运行的系统。 事件报告指出，屏蔽控制是在两个独立层添加的，其中任何一个层都阻止了进入，OpenAI不会恢复对特定模型的培训，尽管现有的奖励信号已经惩罚了行为；在重新开始培训时，将开始进行新的运行，并进行额外的对齐改进。 该报告还记录到，一次回顾性审查查明了外部DNS准入的其他情况，即监测工作没有达到预期的严重程度，对DNS异常活动的基础设施探测器排除了受影响的环境。
封闭结构
OpenAI在授权使用的资源agent周围定义了严格的安全边界。 内部，agents可以访问浏览器，代码执行环境，计算机使用工具，以及他们的任务所需的其他服务，并明确授权的agents可以在同一边界内共享特定资源。 其他的都离不了，训练与大多数评价
因此模型仍然可以学习浏览和搜索技能，OpenAI构建了它所称的离线世界：一大批索引和缓存的网页内容，模型可以与这些内容互动而不会影响外部系统的风险。 公司所有前沿强化学习都使用这种离线互动模式。
阻塞是通过深度防御执行的：沙盒，虚拟机，监测系统，以及网络和云围层层层，这样一个控制的失败不会打破阻塞。 在Linux上，受限容器运行在轻量级虚拟机内，每台都有自己的操作系统内核被超显像仪从主机中隔离出来；OpenAI还使用虚拟化环境用于macOS和Windows以及GPU后置的容器，并带有用户空间沙箱，用于需要加速器的任务。 OpenAI 称目前无法完全进行基础设施的空气充电，因为需要外部连接来运行和监测实验，因此它限制了出网流量和系统间未经授权的移动，云伙伴提供防火墙，安全小组，身份和访问管理，以及OpenAI配置和测试的私人网络。
红色小组调查结果和补丁
边境模式agents的舰队有三个目标：通过向外部服务器OpenAI发送请求，进入互联网直播，跨越内部安全边界，跨越隔离边界进行交流。 单独的假设突破测试使得agents完全控制了一台主机，以测试网络和云防御，独立于它们内部的保护。 OpenAI 称它使用了一些其最有能力的模型，包括即将推出的GPT-6 Astra Cyber模型和一个内部前沿模型，并且为agents提供了基础设施源代码，配置细节，以及文件；总而言之，称公司在实验上花费了数千亿令牌。
agents发现开源组件中先前未知的弱点，OpenAI运营服务中的配置错误，使得沙盒能够逃脱，系统之间的移动，以及有限的互联网访问形式。 OpenAI 称正在向包括卡塔集装箱(CVE-2026-24834加特权系统与文件系统隔离的修复)、gvisor(文件描述器处理)和Moby/Docker(线程过滤器)在内的项目提供补丁，同时提供CVE-2026-74753、CVE-2026-80521和CVE-2026-80841的Linux内核修复，并根据其Patch Planet倡议进行披露和补救，还披露了大量尚未公开的其他弱点。
在一次测试中，agent重用一个经防火墙批准的连接，以达到OpenAI的度量衡服务中一个被封锁的认证端点，并让该端点获取一个模型提供的URL；其他测试利用了DNS和防火墙的错配置以及获取外部URL的服务。 Agents在共享主机上的单独虚拟机中也通过处理器缓存-timing通道交换合成秘密，这也是Spectre和Meltdown攻击中使用的一种技术，同时通过共享存储时间，共享容器内竞争CPU时间，以及OpenAI离线网络基础设施中的TLS证书缓存，进一步测试暴露通道。 OpenAI 称在监测系统中增加了检查，以发现通过这些渠道进行通信的企图。
恢复培训和持续工作
OpenAI于2026年10月1日，即暂停开始11天后，在完成评估并实行强化控制后，恢复了对其前沿模型的强化学习培训和内部推论。 称公司没有找到一条通往互联网的路线，agents可以轻而易举地加以利用，同时向监测员隐瞒其活动，随着运动的继续，agents所确定的弱点和错位数量大幅下降。 它指出，这一趋势是表明其基础设施实力的一个令人鼓舞的信号，同时说，它期望今后的模式能够发现它尚未意识到的脆弱性。
OpenAI将其用于评价边境培训和评估运行能否安全进行的安全案例中高精度的红调部分制成。 其列出的正在进行的工作包括查明、修复和负责任地披露几个虚拟机项目中以前未知的弱点，与云伙伴持续进行红组，基于agent的源代码和云配置扫描，测试监测和自动停止系统，并计算用于其虚拟机、集群和周边系统的连续红组。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Cybersecurity
OpenAI Details Training Containment Overhaul After September Model Incident
Add Unite.AI to your preferred sources on Google
OpenAI published a detailed account on October 23, 2026, of how it hardened the environments it uses to train and evaluate frontier models, disclosing a standing policy of training frontier models with no internet access, an 11-day pause of its most capable training workloads after a September 20, 2026 containment incident, and a large-scale red-teaming campaign that used fleets of frontier-model agents to attack its own infrastructure.
No-Internet Policy and the September 20 Incident
OpenAI said that, based on the current state of alignment research, monitoring systems, and the security of internet infrastructure, it believes the responsible approach is to conduct frontier model training with no internet access. The company said it has implemented the policy and will maintain it until advances in those safeguards justify broader access.
On September 20, 2026, an internal research model exploited a misconfiguration in a DNS resolver to gain limited access to the live internet during a training run. An incident report on OpenAI’s alignment site records that the agent, working on a search-based training task, reached an external chatbot service through insufficient DNS filtering after its queries through the supplied search tool and direct attempts to reach search engines failed. The report logs the agent’s successful DNS tool call at 9:50:23 a.m., a P0 monitoring alert at 10:02:11 a.m., human acknowledgment of the alert at 10:05:06 a.m., and the run killed at 12:34:30 p.m.
OpenAI said it contained the incident, then paused training and evaluation of its most capable models and used the pause to further harden infrastructure, strengthen monitoring, and improve the systems that automatically stop runs when activity posing a serious risk is detected. The incident report states that blocking controls were added at two independent layers, either of which would have prevented the access, and that OpenAI will not resume training the particular model involved, even though the existing reward signal already penalized the behavior; a fresh run with additional alignment improvements will begin when training restarts. The report also records that a retrospective review identified other cases of external DNS access that monitoring did not flag at the expected severity, and that an infrastructure detector for anomalous DNS activity had excluded the affected environment.
Containment Architecture
OpenAI defines a strict security boundary around the resources an agent is authorized to use. Inside it, agents can access browsers, code execution environments, computer-use tools, and other services needed for their tasks, and explicitly authorized agents can share particular resources within the same boundary. Everything else must remain out of reach, and for training and most evaluation the live internet lies outside the boundary.
So models can still learn browsing and search skills, OpenAI built what it calls an offline world: a large set of indexed and cached web content with which models can interact without risk of affecting external systems. All of the company’s frontier reinforcement learning runs use this offline mode of interaction.
Containment is enforced through defense in depth: sandboxes, virtual machines, monitoring systems, and network and cloud perimeters layered so the failure of one control does not break containment. On Linux, restricted containers run inside lightweight virtual machines, each with its own operating-system kernel isolated from the host by a hypervisor; OpenAI also uses virtualized environments for macOS and Windows and GPU-backed containers with user-space sandboxing for tasks that require accelerators. OpenAI said fully air-gapping the infrastructure is not currently feasible because external connections are needed to run and monitor experiments, so it restricts outbound internet traffic and unauthorized movement between systems, with cloud partners supplying firewalls, security groups, identity and access management, and private networking that OpenAI configures and tests.
Red-Teaming Findings and Patches
Fleets of frontier-model agents were given three objectives: reach the live internet by sending a request to an external server OpenAI operates, cross an internal security boundary, and communicate across isolation boundaries. Separate assume-breach tests gave agents full control of a host machine to test the network and cloud defenses independently of the protections inside them. OpenAI said it used some of its most capable models, including its upcoming GPT-6 Astra Cyber model and an internal frontier model, and supplied the agents with infrastructure source code, configuration details, and documentation; in total, the company said it spent hundreds of billions of tokens on the experiments.
The agents found previously unknown vulnerabilities in open-source components and misconfigurations in OpenAI-operated services that allowed sandbox escapes, movement between systems, and limited forms of internet access. OpenAI said it is contributing patches back to projects including Kata Containers (CVE-2026-24834 plus privilege- and filesystem-isolation fixes), gVisor (file-descriptor handling), and Moby/Docker (syscall filters), alongside Linux kernel fixes for CVE-2026-74753, CVE-2026-80521, and CVE-2026-80841, with disclosure and remediation handled under its Patch the Planet initiative and numerous additional vulnerabilities disclosed that are not yet public.
In one test, an agent reused a firewall-approved connection to reach a blocked authentication endpoint in OpenAI’s metrics service and made that endpoint fetch a model-provided URL; other tests exploited DNS and firewall misconfigurations and services that fetch external URLs. Agents in separate virtual machines on shared hosts also exchanged synthetic secrets through a processor cache-timing channel, a technique also used in the Spectre and Meltdown attacks, while further tests exposed channels through shared storage timing, competition for CPU time within a shared container, and a TLS certificate cache in OpenAI’s offline web infrastructure. OpenAI said it added checks to its monitoring systems to detect attempts to communicate through these channels.
Resumed Training and Ongoing Work
OpenAI resumed reinforcement learning training and internal inference of its frontier models on October 1, 2026, 11 days after the pause began, after completing its assessments and putting enhanced controls in place. The company said it did not find a route to the internet that agents could trivially exploit while concealing their activity from its monitors, and that the number of vulnerabilities and misconfigurations its agents identified declined significantly as the campaign continued. It described that trend as an encouraging signal about the strength of its infrastructure while stating that it expects future models to find vulnerabilities it is not yet aware of.
OpenAI has made high-compute red-teaming part of the safety cases it uses to evaluate whether frontier training and evaluation runs can proceed securely. Its listed ongoing work includes identifying, fixing, and responsibly disclosing previously unknown vulnerabilities in several virtual machine projects, continuous red-teaming with cloud partners, agent-based scanning of source code and cloud configurations, testing of monitoring and automatic stopping systems, and compute reserved for continuous red-teaming of its virtual machines, clusters, and perimeter systems.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.