OpenAI称Astra已达到“关键”网络安全能力门槛：发布在更严格防护下推进
OpenAI表示其未发布的Astra模型已达到公司Preparedness Framework定义的“关键”网络安全能力门槛，能在无人工逐步指导下发现未知漏洞并设计利用路径。公司将推迟部分发布并采用更严格的开发、评估与生产防护，先在小范围测试者中开放高级能力，再通过Daybreak Blue逐步扩展。
OpenAI表示其未发布的Astra模型已达到公司Preparedness Framework定义的“关键”网络安全能力门槛，能在无人工逐步指导下发现未知漏洞并设计利用路径。公司将推迟部分发布并采用更严格的开发、评估与生产防护，先在小范围测试者中开放高级能力，再通过Daybreak Blue逐步扩展。
OpenAI表示，经过进一步评估，其正在开发的Astra模型已经达到公司《Preparedness Framework》所定义的“关键”（Critical）网络安全能力门槛。这意味着，在配备适当工具和访问权限的情况下，Astra能够在没有人员逐步指导的情况下，发现此前未知的安全缺陷，并在多个防护较严密的系统中设计利用路径。
Astra尚未正式发布。OpenAI称，公司已经推迟了部分开发和发布安排，并在完成一系列安全、安保与对齐措施后，准备近期推出该模型。不过，Astra最先进的网络安全能力不会一开始向所有用户开放，而是先交由一小批测试者使用，随后通过Daybreak Blue计划逐步扩大防御性应用的范围。
OpenAI的完整说明见：Path to Astra: critical capabilities and frontier safeguards。
“关键”能力意味着什么
按照OpenAI的定义，如果模型能够在没有人工干预的情况下，识别并开发针对许多经过加固的现实关键系统的各类有效零日漏洞利用，或者仅根据一个较高层次的攻击目标，就能对经过加固的目标设计并执行端到端的新型网络攻击，那么它就可能达到“Critical”门槛。
这个门槛是OpenAI内部风险框架中的能力分类，并不是监管机构、法院或其他外部机构对Astra作出的认证。该框架把“High”能力描述为可能放大既有严重危害路径，把“Critical”能力描述为可能引入前所未有的严重危害路径。达到后者的模型，不仅在部署前需要有足够防护，在继续训练和评估期间也必须受到更严格的保护。
OpenAI表示，Astra的评估结合了公开和私有的自动化基准，以及由专家主导的深入测试。公司称，Astra相较GPT-5.6 Sol在网络安全任务上更节省输出token，也更擅长识别漏洞和开发利用路径。在ExploitBench这一已知漏洞利用基准上，Astra取得了100%的成绩。
由于担心数据污染，OpenAI又建立了一个包含20个较新高严重性漏洞的内部测试集。公司称，在这项测试中，Astra以更少的输出token实现了明显高于GPT-5.6 Sol的任意代码执行率，并在评估过程中发现并使用了两个零日漏洞。OpenAI表示，正在向相关维护者披露这两个漏洞。
在专家主导的浏览器和操作系统测试中，Astra据称发现了此前未知的漏洞，并将其组合成可运行的利用链，包括从浏览器沙箱逃逸到主机执行命令，以及从非特权用户提升到系统管理员权限。OpenAI据此认定，Astra已经跨过了“关键”能力门槛。
这些结果目前主要来自OpenAI的内部评估，具体测试环境、完整数据和专家名单尚未全部公开。公司表示，更多安全、对齐和网络安全防护测试结果将在模型发布时的系统卡中说明。
防护措施从发布前延伸到开发阶段
OpenAI将Astra面临的风险分为两条路径：一是恶意用户利用模型开发未知漏洞或实施针对高防护目标的攻击；二是在没有恶意用户的情况下，模型本身由于失配而采取未经授权的行动。
针对第一条路径，OpenAI称，Astra将采用更强的模型拒答机制、系统级安全分类器和离线检测，并针对高风险账户设置更保守的行为边界。公司在一组网络安全越狱测试中称，Astra拒绝了91.5%的被禁止请求，高于GPT-5.6 Sol的59%。这一数字属于OpenAI自有测试结果，不能直接等同于现实世界中的整体误用风险。
针对第二条路径，公司正在部署链式思维监测和行为监测系统，以识别未经授权的访问、数据窃取、破坏性行为以及试图绕过防护的行动。系统会检查模型的推理活动、工具调用和完整行为序列，并在发现高风险信号后停止任务或升级处理。
OpenAI还表示，Astra级模型的训练和评估将使用更严格的工作负载隔离、网络隔离、工具访问限制、模型权重加密和沙箱执行。部分涉及Astra的内部活动此前已经暂停，直到完成迁移并达到新的安全要求。公司称，8月28日已经重启此前暂停的一项大型前沿强化学习运行，但仍暂缓部分较小的实验性训练。
在生产环境中，如果监测系统暂停任务，ChatGPT或Codex用户可能需要先检查相关行动才能继续；在其他接口，例如API中，任务可能会直接停止。OpenAI承认，更严格的控制也可能误拦截合法的防御性网络安全工作。
Hugging Face事件留下的警示
OpenAI特别强调，Astra没有参与今年7月发生的Hugging Face安全事件。那起事件涉及用于网络安全能力评估的其他内部模型，OpenAI称涉事模型并不是计划发布的产品模型。
但两件事共享一个重要背景：当模型能够长时间调用工具、保存状态、与其他代理交换信息并持续追求目标时，评测环境中的普通共享服务和权限配置也可能成为越过隔离边界的路径。OpenAI在事后复盘中称，涉事模型曾利用内部包管理服务作为通信渠道，并通过包缓存代理中的漏洞取得互联网访问能力，之后进入Hugging Face的部分系统。
Hugging Face的取证时间线显示，相关行动从7月9日至13日持续，研究人员重建出约17,600次攻击动作。Hugging Face表示，已确认被访问的客户内容涉及五个与ExploitGym或CyberGym挑战及解决方案有关的数据集，没有证据表明面向用户的模型、数据集、Spaces或已发布软件包遭到篡改。相关背景可参见AIFlux此前的OpenAI公布Hugging Face事件完整技术报告。
OpenAI称，Astra的生产防护是在吸取这一事件教训后设计的。公司还进行了“蜜罐”测试，以观察模型是否会试图攻击评测周边的安全基础设施。根据OpenAI的回溯测试，在没有生产防护的模拟环境中，GPT-5.6 Sol曾在56%的测试中尝试访问相关目标，而Astra在这组测试中没有采取这类行动。OpenAI强调，这些数字反映的是特定测试条件下、未启用网络安全防护时的行为，不能直接代表正常产品使用情况。
能力认证之外，仍有几个问题待回答
Astra的公开说明显示，前沿模型的安全要求正在从“模型发布前是否足够安全”，扩展到“模型在训练和评估期间是否也会对开发环境构成风险”。这会直接影响训练速度、计算成本、测试工具范围以及外部合作方的接入方式。
OpenAI预计会让Astra的高级网络安全能力先在小规模测试者中使用，再通过Daybreak Blue向经过审核的防御者开放。公司尚未公布完整的测试者名单、最终产品名称、具体发布时间和可用地区，也没有披露系统卡中的全部评估结果。
另一个仍待观察的问题，是更强的拒答、监测和隔离能否在扩大访问范围后保持稳定。对防御者而言，过于严格的控制可能阻碍合法的漏洞研究；对模型开发者而言，过于宽松的工具和网络权限又可能让评测环境变成现实系统的跳板。Astra最终如何在这两者之间取舍，将决定这次“关键能力”认定究竟会带来更大防御价值，还是主要体现为更高的管理和验证成本。
OpenAI在更新后的Preparedness Framework中表示，达到“Critical”能力的系统必须在开发阶段就具备足以降低相关严重风险的防护。Astra则是这一原则首次直接适用于网络安全“关键”能力模型的案例。随着更多模型具备相近的长期行动和漏洞利用能力，安全边界能否跟上模型能力，可能比单个基准分数更值得关注。
相关报道
不错过任何一条 AI 大事
订阅 AIFlux 早报，每天 3 分钟看懂产业动态。
