保障我们的前沿模型训练环境安全

# 保障我们的前沿模型训练环境 来源：https://openai.com/index/securing-our-frontier-model-training-environment/ *本文介绍了我们如何保障用于训练和评估前沿模型的环境安全。这些研究环境不同于客户使用我们已发布模型的环境：开发中的模型可能尚未完成安全性和对齐性训练，我们会刻意在对抗性条件下对其进行测试以暴露弱点。在将模型开放给更广泛使用之前，我们会进行安全性和对齐性评估，并部署生产级安全防护措施。* 为了与软件交互，AI模型需要计算环境——即数字工作空间，模型可以在其中编写和运行代码、搜索信息以及尝试不同的问题解决方法。这些环境让模型得以练习这些技能，同时限制它们可以访问或执行的操作——帮助在模型出现错误或表现出失对齐行为时控制影响范围。 但随着模型能力增强，它们越来越善于找到绕过这些限制的方法。一个高度复杂的模型可能利用软件缺陷或配置错误逃逸沙箱、利用内部服务访问实时互联网，或找到未经授权的方式与处于其他沙箱中的智能体进行通信。今年七月的Hugging Face事件（https://openai.com/index/hugging-face-incident-and-the-road-ahead/）以及我们观察到的其他模型失对齐案例（https://alignment.openai.com/misalignment-reports/），都展示了具有高级网络能力的模型如何在训练和评估过程中突破隔离。 针对这些事件，我们大幅加强了研究环境的安全防护。与云服务商密切合作后，我们在整个基础设施中加入了新的安全控制，减少了智能体可利用的攻击面，并改进了检测失对齐行为和越界尝试的方法。这些防护层层叠加，即使单个控制措施失效，隔离依然能够保持——这种策略称为**纵深防御**。 **基于当前对齐研究、监控系统以及互联网基础设施安全性的现状，我们认为负责任的做法是在无互联网访问的条件下进行前沿模型训练。我们已实施这一策略，并将持续执行，直至安全措施的进步足以支持更广泛的互联网访问。** 这些投入使我们能够在失对齐行为造成损害之前发现并阻止它们。例如，在9月20日，一个内部研究模型在训练过程中利用了DNS解析器的配置错误，获得了有限的实时互联网访问权限（https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/）。虽然我们成功遏制了该事件，但它暴露了需要进一步解决的弱点。我们暂停了最强能力模型的训练和评估，并利用这段暂停时间进一步加固基础设施、加强监控，以及改进那些在检测到严重风险时自动终止运行的系统。 但能力日益强大的模型即使面对最安全的系统也可能找到漏洞或配置错误。为确保研究环境即使面对最强大的模型也具有足够的弹性，我们发起了一项高算力红队活动来探测基础设施的弱点。多个前沿模型智能体团队被指派寻找可能允许它们执行未经授权操作的漏洞和配置错误——例如访问实时互联网、逃逸安全边界或与其他智能体进行未授权通信。 这些红队实验发现了此前未知的软件漏洞以及研究基础设施中的配置错误。我们已修复了红队智能体发现的弱点，对于存在于开源软件中的问题，我们在**Patch the Planet**（https://openai.com/index/patch-the-planet/）倡议框架下与相关维护者合作，进行漏洞披露和修复。 随着红队实验的持续进行，智能体发现的漏洞和配置错误数量显著下降。虽然我们认为这是基础设施强度的积极信号，但我们预计未来的模型能够发现和利用我们尚不知晓的漏洞。因此，我们将持续红队活动视为加强研究环境安全性的长期策略核心部分。基于此，我们已将高算力红队纳入**安全案例**（https://openai.com/index/towards-safety-cases-for-frontier-ai-training/）的评估框架，用于判断我们的前沿训练和评估运行是否能安全进行。在完成评估并部署增强的控制措施后，我们于10月1日恢复了前沿模型的强化学习（RL）训练和内部推理。 本文将介绍我们如何加强用于训练和评估模型的环境，以及如何利用我们最强大的模型来发现和修复系统中的弱点。 ## 我们全新的模型隔离方法 我们的隔离方法始于一个最高要求：对智能体访问权限的限制必须在智能体试图绕过时依然有效。我们围绕智能体被授权使用的资源定义严格的安全边界，并设计周边基础设施来强制执行该边界——即使智能体进行持续、复杂的突破尝试。 在安全边界内部，智能体可以访问浏览器、代码执行环境、计算机操作工具以及其任务所需的其他服务。被明确授权通信的智能体还可以在同一边界内共享特定资源。其他一切——即智能体未被明确授权访问的一切——必须保持无法触及。如果智能体能够访问承载它们的基础设施、通过允许的渠道之外的方式与其他智能体通信，或到达外部系统，这都构成隔离的失败。 在训练和大多数评估中，实时互联网位于边界之外，因为我们认为向模型提供实时互联网访问可能带来重大风险。虽然互联网访问可以帮助模型习得有用的技能，但它也给了有能力且失对齐的智能体影响超出我们控制范围的系统的机会。因此，我们为研究环境设计的安全架构遵循一个最高原则：*我们必须始终能够阻止前沿模型获得对实时互联网的未授权、任意访问。* ### 构建离线世界 虽然我们希望阻止模型获得对实时互联网的任意访问，但让它们学会浏览、搜索信息和使用Web应用同样重要。为了帮助它们在不提供无限制实时互联网访问的情况下发展这些技能，我们构建了一个"离线世界"——一个包含大量已索引和缓存的Web内容的集合，模型可以安全地与之交互，而不会影响外部系统。我们所有的前沿RL运行都使用这种离线交互模式。 ### 以纵深防御实现隔离 离线环境为智能体提供了无需访问实时互联网即可使用的资源，但我们也需要防止智能体超出这些环境的范围。训练环境对智能体可以访问或执行的操作施加限制，但能力足够强或足够执着的智能体可以寻找绕过方法：它们可以系统地探测环境中的弱点，并利用这些弱点执行从未被授权的操作。随着模型越来越善于发现和利用这些弱点，我们需要能够维持隔离的防御措施——即使模型设法突破了单个控制。 我们通过纵深防御来应对这一挑战，层层叠加、相互强化的保护措施包括：限制智能体访问和执行能力的沙箱、将智能体的执行环境与承载它的计算机隔离的轻量级虚拟机（microVM）、检测未授权活动以便我们及时干预的监控系统，以及在前述所有控制措施都失效时仍能维持隔离的网络和云边界防护。 对于代码执行和计算机操作任务，隔离始于智能体工作所处的环境。在Linux上，我们在轻量级microVM中运行受限容器。容器限制对microVM内部文件和进程的访问，而microVM运行自己的操作系统内核，并通过管理程序（hypervisor）与宿主机隔离。对于需要GPU加速的任务，我们还使用macOS和Windows的虚拟化环境，以及支持用户空间沙箱的GPU容器。 周边的网络和云控制旨在即使智能体逃逸沙箱并控制了宿主机，仍能维持隔离。完全物理隔离这套基础设施——即完全切断与外部网络的连接——目前尚不可行，因为我们需要外部连接来运行和监控实验。因此，我们在保留必要外部连接的同时，限制了出站互联网流量和系统间的未授权移动。这些限制还延伸到从宿主机可直接访问或通过其他服务间接访问的服务，以确保智能体无法将其中之一用作间接的出口通道。 我们的云合作伙伴为强制执行这些边界提供了关键控制——包括防火墙、安全组、身份与访问管理以及私有网络。我们负责正确配置这些控制措施，并测试它们的协同工作方式。我们与构建和运营这些服务的团队合作，帮助我们调查异常行为并解决跨多层基础设施的弱点。 ## 大规模红队测试隔离机制 为了发现隔离基础设施的弱点，我们让多组前沿模型智能体团队尝试突破其防御。我们为它们设定了三个具体目标： - **访问实时互联网：**向我们运营的外部服务器发送请求。 - **跨越内部安全边界：**演示对其允许环境之外资源的未授权访问。 - **跨隔离边界通信：**与本应被隔离的其他智能体交换信息。 我们还进行了一些测试，假设内部防御已经失效——即智能体已逃逸沙箱、规避了监控并获得了对其宿主机的完全访问权限——目的是观察智能体能否利用该权限访问实时互联网。这些实验使我们能够独立于内部防护来测试网络和云层的防御能力。 与我们在Navier–Stokes问题求解（https://openai.com/index/navier-stokes-solution/）中的方案类似，这项工作由组织成团队的智能体执行，团队可以并行探索不同方法并在彼此发现的基础上继续深入。我们使用了部分最强大的对齐模型，包括即将发布的GPT-6 Astra Cyber模型和一个内部前沿模型。由于我们的目标是在对攻击者有利的条件下测试防御能力，而非衡量模型在无辅助情况下能自主发现什么，我们向它们提供了基础设施源代码、配置详情以及描述潜在漏洞的文档。 这些红队实验使用了隔离的、专门构建的研究基础设施副本进行，配有监控和程序化检查机制，一旦检测到超出范围的活动即暂停运行。我们的云合作伙伴协助监督了这些实验，并对发现的问题进行响应。 总计，我们在这些红队实验中消耗了数千亿个token。 *我们绘制了高优先级候选发现的累计数量与红队智能体消耗token数量的对比图。随着时间推移，我们使用了不同的模型并测试了基础设施的不同部分，部分测试限定在与云合作伙伴协调的时间窗口内进行。因此，该曲线反映的是这项工作的规模和进展，而非算力规模与发现数量之间的受控关系。* ## 我们的红队智能体发现了什么 在红队实验中，智能体能够发现我们所使用的开源组件中此前未知的软件漏洞，以及我们所运营服务中的配置错误。这些弱点使得智能体能够逃逸沙箱、在系统间移动并访问实时互联网。它们还找到了跨隔离边界通信的方法。这些发现催生了软件补丁、更严格的网络限制，以及向相关软件维护者和供应商的漏洞披露。 以下介绍其中几项发现及其应对方式。 ### 逃逸强化虚拟机 在一组实验中，我们要求智能体团队逃逸OpenAI的沙箱并在底层宿主机上演示代码执行。这些智能体发现了多种将漏洞链化以实现microVM逃逸的方法。 我们构建了一套自动化管道来帮助分类和去重智能体发现的漏洞和配置错误，由我们的安全和基础设施团队复现发现结果并验证配置修复。对于影响我们所使用的开源组件的问题，我们将相应补丁贡献回底层项目，包括对Kata Containers（CVE-2026-24834、[权限隔离](https://github.com/kata-containers/kata-containers/pull/13615)和[文件系统隔离](https://github.com/kata-containers/kata-containers/pull/13587)）、gVisor（[文件描述符处理](https://github.com/google/gvisor/pull/13816)）以及Moby/Docker（[系统调用过滤](https://github.com/moby/profiles/pull/39)）等软件组件的修复。我们还在持续推进[改进内核安全](https://openai.com/index/expanding-daybreak-as-the-cyber-defense-window-narrows/)的更广泛工作，包括对CVE-2026-74753、CVE-2026-80521和CVE-2026-80841的修复。我们还披露了众多尚未公开的其他漏洞。 ### 发现通往互联网的全新路径 智能体的microVM逃逸展示了为何隔离必须延伸到沙箱之外。为了测试周边防护，我们给予智能体团队一台宿主机的控制权，并观察它们能否将这种入侵扩展到访问实时互联网。 在Hugging Face事件之后，我们已减少了训练和评估期间模型可以到达互联网的通道。我们运营的一些特定服务仍保留了有限连接，如指标采集、日志记录和认证管理。我们的红队智能体在几乎所有这些服务中都发现了漏洞，使它们获得了利用这些服务