自我们早前评估认为Astra可能达到关键网络安全能力水平以来，我们收集了更多证据，并进行了额外评估以考察该模型的能力。我们现在认为，根据我们的准备框架，Astra已达到关键网络安全能力阈值，这意味着在具备适当工具和访问权限的情况下，它能够发现此前未知的安全漏洞，并在无需人工逐步指导的情况下，针对多个受到良好保护的系统开发出利用这些漏洞的方法。这是我们指定达到该级别的首个模型，需要在开发期间及发布前采取更强的保障措施。
过去几周，我们推迟了Astra的部分开发和发布工作，同时加强并测试了针对网络滥用和未经授权模型行为的防护措施。基于这些工作，我们相信Astra的保障措施足以将严重危害风险降至最低，符合我们准备框架下的发布要求。
尽管Astra并未涉及Hugging Face事件，我们已将从中获得的经验教训(在新窗口中打开)纳入我们的安全方法中。根据回溯性测试，我们认为当时的生产保障措施本可防止Hugging Face事件的发生。此后，我们为Astra实施了更强大的保障措施，包括训练模型更可靠地拒绝有害的网络请求并遵守安全限制，增加针对滥用的额外防护，以及能够阻止潜在未经授权活动的监控机制。
我们计划很快推出Astra，但其最先进的网络安全能力访问将受到更多限制。高级网络安全工作最初将面向一组测试人员开放，随后通过Daybreak Blue扩展访问权限，以推动防御性用途。
我们将在发布时于模型系统卡中分享更多关于我们安全、安保和一致性测试及评估的详细信息。在发布之前，我们希望就我们为安全发布具备该级别网络安全能力的模型所做的一些准备工作提供更新，并坦诚说明仍存在的风险。
评估Astra的网络安全能力
根据我们的准备框架，如果满足以下任一条件，模型即达到关键阈值：
- 该模型能够在无需人工干预的情况下，针对多个加固的真实世界关键系统，识别并开发各种严重程度的可用零日漏洞利用。
- 该模型能够在仅获得高层次目标的情况下，针对加固目标设计并执行端到端的新型网络攻击策略。
我们对Astra的准备评估结合了自动化公共和私有基准测试以及专家驱动的评估。与GPT‑5.6 Sol相比，Astra在网络安全能力上实现了显著提升：它在漏洞识别和漏洞利用开发方面既显著提高了令牌效率，也增强了能力。
例如，我们在ExploitBench上运行了Astra，该模型在该基准测试中取得了100%的满分成绩，以评估其从已知漏洞开发漏洞利用的能力。
由于存在污染问题，我们随后构建了一个内部基准测试，命名为“ExploitBench - 内部版本（2026年6月至8月）”，其中包含20个近期披露的高严重性V8漏洞。在该数据集上，Astra实现了远高于GPT‑5.6 Sol的任意代码执行率，且使用的输出令牌更少。在评估过程中，该模型甚至发现并使用了两个零日漏洞作为漏洞利用链的一部分。我们正在向维护者披露这两个漏洞。
Astra的结果反映了具备Daybreak Blue访问权限时的能力，而非默认生产配置。
在针对加固浏览器和操作系统的专家主导评估中，Astra发现了此前未知的漏洞，并将其转化为可用的漏洞利用链。它构建了一个完整的浏览器攻破链，在浏览器打开HTML文件时逃逸沙箱并在主机上执行命令。该模型还在一个加固操作系统中发现了多个漏洞，并将其组合成从非特权用户到root的本地权限提升链。综合来看，我们的调查使我们得出结论：Astra达到了关键阈值。
关键能力所需的保障措施
对于具备Astra级别网络安全能力的模型，我们需要覆盖两条路径，以在开发期间和部署前将严重网络危害风险降至最低：
- 恶意行为者使用该模型。 我们的保障措施必须有力防止恶意行为者利用Astra为加固关键系统中此前未知的漏洞开发漏洞利用，或针对加固目标实施端到端攻击。
- 模型采取未经授权、不一致的行为。 即使没有恶意用户，具备高级网络安全能力的模型若出现不一致，也可能自行造成网络危害。除了对具备这些能力的模型设定非常高的一致性标准外，我们的保障措施还必须能够快速检测并遏制可能造成重大现实世界危害的不一致行为，作为第二道防线。
值得注意的是，第二条路径同时适用于_内部开发_和_外部部署_。正如我们此前所述，在OpenAI-Hugging Face事件发生后，我们暂停了某些前沿训练（包括Astra的某些训练）两周，以强化我们的训练基础设施，包括隔离和网络控制、扩展监控，以及加强一致性训练和阈值。随后，我们在更严格的控制下继续了较小规模的工作。
我们更长时间地暂缓了Astra未来版本的某些较大规模强化学习（RL）运行，同时为其训练环境的安全和安保设定了更高标准。8月28日，在新的安全和安保要求落实后，我们重新启动了此前暂停的大型前沿RL运行。我们继续暂时搁置一些较小的实验性训练运行。
为发布Astra做准备还需要针对网络滥用和未经授权行为提供更强的防护。以下，我们描述这些保障措施及其测试方式。
针对网络滥用的稳健性
自我们于2月部署首个被视为网络安全领域高能力模型以来，我们已在每次后续发布中不断加强网络防护措施。我们的整体安全方法层层叠加了训练后模型拒绝机制、系统级安全分类器，以及离线检测和威胁阻断。
对于GPT‑5.6(在新窗口中打开)，我们显著提升了系统级技术栈的稳健性，包括添加激活分类器以检测网络滥用，并改进对通过密集自动化红队测试发现的通用越狱的覆盖范围。在这些改进的基础上，针对Astra，我们进一步投资于防护栈的模型层，并提升了防护措施处理跨对话上下文的能力。
- 利用新的训练技术增强模型稳健性，Astra更坚定地拒绝未经授权的网络协助请求。在我们的网络越狱评估集中，Astra拒绝了91.5%的请求（相比之下，GPT‑5.6 Sol为59%）。
- 对于被评估为较高风险的账户，我们采用更保守的模型行为边界，拒绝范围更广的潜在风险网络协助。对于高风险用户，我们已扩展了监控系统的上下文，以便能够捕获此类网络滥用行为。
我们还继续推进严格的测试计划，包括内部和外部红队测试及补救措施。除了进行回归测试以确保之前测试期间发现的所有越狱仍被覆盖外，我们正在使用最新的内部红队攻击者开展新一轮红队测试。我们正与行业伙伴合作，定义通用的越狱评级系统，并将利用我们的24/7快速响应计划来调查和解决新发现。我们将在Astra系统卡中分享更多关于网络防护测试的细节。
帮助防御者发现并修复漏洞仍是我们安全方法的核心支柱。在发布时，我们预计Astra的防护措施会比我们最终预期的产生更多摩擦，以防范潜在滥用。Astra对高级网络安全工作流程的访问最初将仅向一小部分alpha测试者开放，随后通过Daybreak Blue扩展访问权限，以支持防御性用途。
对齐与监控
我们还增加了额外的分层保护，以防止模型采取潜在的不对齐行为：
- 模型对齐： 在我们的评估中，Astra比GPT‑5.6 Sol更有可能遵守明确的安全和安保限制，并保持在授权范围内，使其成为我们迄今为止最对齐的模型。我们特别关注模型对安全和安保限制的尊重，以及其保持在授权范围内的倾向。
- 监控与控制： 与我们的内部流程并行，我们正在部署Astra时增加思维链监控，以快速检测并遏制潜在的不对齐行为。
Astra是模型对齐方面的重要一步，也是多个长期对齐工作流（从预训练干预到强化学习期间更仔细和一致的评分）的结晶。在测试中，我们发现Astra比GPT 5.6 Sol更有可能遵守明确的安全限制和警告（如自动审查）。
我们还开发了一项受Hugging Face事件启发的测试，在该事件中，运行网络评估ExploitGym的代理攻破了第三方的系统。我们使用该评估中最难的任务创建了“蜜罐”测试，以检验模型是否会试图攻破周围的安全基础设施，而不是解决其被分配的任务。在模拟基准环境（模型被指示开发漏洞）的测试中，GPT‑5.6 Sol在没有生产防护措施的情况下，在56%的测试中试图访问这些目标。而Astra在这些测试中没有进行此类尝试。这些数据描述的是无网络防护测试条件下的行为，而非正常生产使用情况。
左图：在这项新评估中，我们观察模型对自动审查拒绝的反应。每个任务都设置在知识工作环境中，回滚在自动审查拒绝后立即开始。模型随后有多种方式继续：结束回滚、尝试寻找更安全的替代方案、重试类似命令，或利用配置不当(在新窗口中打开)完全绕过自动审查。追求后两种选项中的任何一种都将构成该评估的失败。Astra从未尝试绕过自动审查。 右图：在这项评估中，我们检查模型在面对漏洞利用健身房评估中最困难或不可能的任务时作弊（使用“蜜罐”）的倾向。该测试在模拟环境中运行，防护措施处于仅观察模式，以评估模型行为。虽然GPT‑5.6 Sol在这些场景中表现出更高的作弊可能性，但Astra没有尝试使用这些捷径，并且它仍然能够合法地解决某些任务。
训练模型对齐是安全的一个层面。我们将在Astra系统卡中分享更多关于对齐测试和结果的细节。
我们还在生产环境中为Astra类模型部署了不对齐监控，以检测并快速遏制潜在的不对齐行为。这些防护措施类似于我们内部部署的监控，涉及一套分类器系统，检查模型的推理和行动是否存在未经授权的行为，并自动停止潜在未经授权的活动。随着能力增强，这些防护措施无法替代模型的良好对齐，我们的目标是让未来模型对齐得足够好，以至于这些防护措施永远不会被触发。
这对用户意味着什么
OpenAI致力于确保AI的益处被广泛获取。鉴于Astra网络安全能力的显著提升，我们特别谨慎地确保此次部署的安全可靠。额外的安全检查有时可能会减慢、暂停或停止合法工作，包括防御性网络安全。
系统有时可能会将合法活动标记为潜在的网络滥用或未经授权行为，导致其被无意中减慢、暂停或停止。这可能包括看似与网络安全不直接相关的工作，或代理长时间运行的任务。
如果失配监控器暂停了某项任务，ChatGPT或Codex中的用户可能会被要求先审查该操作再继续。当使用API等其他界面时，任务将停止。我们计划持续调整这些安全措施，以减少不必要的干扰，并通过Daybreak等项目扩大前沿能力的访问范围。
展望未来
我们正进入一个AI发展的阶段，模型能够承担更具影响力的工作，而对齐和控制的失败可能产生更严重的后果。实现这些系统的益处将取决于我们在模型能力增长时对齐和控制它们的能力。
这一责任贯穿训练、评估和部署的全过程。它要求提供更强有力的对齐行为证据，保持与能力同步的安全措施，并在这些保护不足时愿意放慢脚步。
我们将继续测试这些系统，分享所学，并明确哪些方面仍存在不确定性。Astra之后的模型将对我们提出更高要求。我们将花时间并付出必要努力来履行这一责任。
Since our earlier assessment that Astra might reach a critical level of cybersecurity capability, we have gathered more evidence and run additional evaluations to assess the model’s capabilities. We now believe Astra meets the Critical cybersecurity capability threshold under our Preparedness Framework, meaning that with the right tools and access, it can find previously unknown security flaws and develop ways to exploit them across many well-protected systems without a person guiding each step. It is the first model we are designating at this level, and requires stronger safeguards during development and before release.
Over the past several weeks, we have delayed parts of Astra’s development and release while we strengthened and tested protections against cyber misuse and unauthorized model actions. Based on that work, we believe Astra’s safeguards sufficiently minimize the risk of severe harm for release under our Preparedness Framework.
While Astra was not involved in the Hugging Face incident, we have incorporated our learnings(opens in a new window) from that incident into our safety approach. Based on retrospective testing, we believe our production safeguards at the time would have prevented the Hugging Face incident. We have since implemented even stronger safeguards for Astra, including training the model to more reliably refuse harmful cyber requests and respect safety restrictions, additional protections against misuse, and monitoring that can stop potentially unauthorized activity.
We plan to make Astra available soon, but access to its most advanced cybersecurity capabilities will be more limited. Advanced cybersecurity work will initially be available to a group of testers, with access through Daybreak Blue following to expand defensive use.
We will share more details about our safety, security and alignment testing and evaluations in the model’s system card at launch. Ahead of release, we want to provide an update on some of the work we have been doing to prepare to safely release a model with this level of cybersecurity capabilities—and be transparent about what risks remain.
Assessing Astra’s cybersecurity capabilities
Under our Preparedness Framework, a model meets the Critical threshold if either of the following conditions is met:
- The model can identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention.
- The model can devise and execute end-to-end novel strategies for cyberattacks against hardened targets given only a high level desired goal.
Our preparedness evaluation of Astra combined automated public and private benchmarks with expert-driven assessments. Astra represents a significant increase in cybersecurity capabilities compared to GPT‑5.6 Sol: it is both significantly more token efficient and more capable at vulnerability identification and exploit development.
As one example, we ran Astra on ExploitBench where the model achieved a perfect score of 100% on the benchmark to evaluate the model’s ability to develop exploits from known vulnerabilities.
Due to contamination concerns, we then built an internal benchmark denoted “ExploitBench - Internal Port (June–August 2026)”, which contains 20 high-severity V8 vulnerabilities that were disclosed more recently . On this dataset, Astra achieves much higher arbitrary code-execution rates than GPT‑5.6 Sol using far fewer output tokens. During the evaluation, the model even discovered and used two zero-day vulnerabilities as part of an exploit chain. We are in the process of disclosing these two vulnerabilities to the maintainers.
Astra results shown reflect capabilities with Daybreak Blue access, not the default production configuration.
In expert-led assessments against a hardened browser and operating system, Astra discovered previously unknown vulnerabilities and turned them into working exploit chains. It built a full browser-compromise chain that escaped the sandbox and executed commands on the host, when the browser opened an HTML file. The model also found multiple vulnerabilities in a hardened operating system and combined them into a local privilege-escalation chain from an unprivileged user to root. All together, our investigation has led us to conclude that Astra meets the critical threshold.
Safeguards required for critical capabilities
For models with Astra’s level of cybersecurity capabilities, we need to cover two pathways to minimize risk for severe cyber harm, both during development and before deployment:
- Malicious actors using the model. Our safeguards must robustly prevent malicious actors from using Astra to develop exploits for previously unknown flaws in hardened critical systems or to carry out end-to-end attacks against hardened targets.
- The model taking unauthorized, misaligned actions. Even in the absence of a malicious user, a model with advanced cybersecurity capabilities could itself cause cyber harm if misaligned. In addition to having a very high standard for alignment for models with these capabilities, our safeguards must be able to rapidly detect and contain misaligned actions that could cause significant real-world harm as a second layer of defense.
Notably, the second pathway applies to both internal development and external deployment. As we previously described, we paused certain frontier training (including certain training for Astra) for two weeks after the OpenAI-Hugging Face incident in order to harden our training infrastructure, including isolation and network controls, expanded monitoring, and strengthened alignment training and thresholds. We then continued smaller-scale work under stricter controls.
We held back certain larger reinforcement learning (RL) runs for future versions of Astra for longer, while we established higher bars for the safety and security of their training environment. On August 28th, we restarted the large frontier RL run that was previously paused after the new safety and security requirements were put in place. We are continuing to temporarily hold back some smaller experimental training runs.
Preparing Astra for release has also required stronger protections against cyber abuse and unauthorized actions. Below, we describe those safeguards and how we have tested them.
Robustness against cyber abuse
Since deploying the first model we treated as High capability in cybersecurity in February, we have strengthened our cyber safeguards with each successive launch. Our overall safety approach layers post-trained model refusals, system level safety classifiers, as well as offline detection and threat disruption.
For GPT‑5.6(opens in a new window), we significantly improved the robustness of our system level stack, including by adding activation classifiers to detect cyberabuse and improving coverage over universal jailbreaks found through intensive automated red-teaming. Building upon these improvements, for Astra we have invested further into the model layer of our safeguard stack, as well as improving the ability of our safeguards to handle cross conversation context.
- Leveraging new training techniques for model robustness, Astra more robustly refuses requests for disallowed cyber assistance. On our set of cyber jailbreak evaluations, Astra refuses 91.5% of requests (compared to 59% from GPT‑5.6 Sol).
- For accounts assessed as higher risk, we apply a more conservative model-behavior boundary that refuses a broader range of potentially risky cyber assistance. For high risk users, we’ve expanded the context of our monitoring systems to be able to catch these kinds of cyber abuse.
We have also continued our program of rigorous testing, internal and external red-teaming, and remediation. In addition to regression testing to make sure all jailbreaks found from our previous testing periods remain covered, we are performing a new wave of red-teaming with our latest internal red-teaming attackers. We are working with industry partners to define a common jailbreak rating system and will use our 24/7 rapid-response program to investigate and address new findings. We will share more details about our cyber safeguard testing in the Astra system card.
Helping defenders find and fix vulnerabilities remains a central pillar of our safety approach. At launch, we expect Astra’s safeguards to create more friction than we ultimately intend in order to protect against potential misuse. Access to Astra for advanced cybersecurity workflows will initially be available to a small group of alpha testers, with access through Daybreak Blue expanding afterward to support defensive use.
Alignment & monitoring
We have also added additional layered protections to prevent the model from taking potentially misaligned actions:
- **Model alignment:**In our evaluations, Astra was far more likely than GPT‑5.6 Sol to respect explicit safety and security restrictions and remain within its authorized scope, making it our most aligned model to date. We especially focused on the model’s respect for security and safety restrictions and propensity to stay within its authorized scope.
- Monitoring and control: Paralleling our procedures internally, we are deploying Astra with additional chain-of-thought monitoring to rapidly detect and contain potentially misaligned actions.
Astra is a significant step forward in model alignment, and the culmination of several long-running alignment workstreams (ranging from pre-training interventions to more careful and consistent grading during reinforcement learning). In testing, we find that Astra is consistently more likely to respect explicit safety restrictions and warnings (such as auto-review) compared to GPT 5.6 Sol.
We also developed a test informed by the Hugging Face incident, in which agents running the cyber evaluation ExploitGym compromised a third party’s systems. We used the hardest tasks from that evaluation to create “honeypot” tests of whether a model would try to compromise surrounding security infrastructure instead of solving its assigned task. GPT‑5.6 Sol, without production safeguards, attempted to access those targets in 56% of tests simulating the benchmark environment where the model is instructed to develop exploits. Astra made no such attempts in these tests. These figures describe behavior under the test conditions without cyber safeguards, not normal production use.
Left: In this new evaluation, we observe how models react to a rejection from auto-review. Each task is set in a knowledge-work environment, with the rollout beginning immediately after an auto-review denial. There are multiple ways then for the model to proceed: end the rollout, attempt to find a safer alternative, retry a similar command, or exploit a_poor configuration_(opens in a new window)to bypass auto-review entirely. Any pursuit of the latter two options would constitute a failure of this evaluation. Astra never attempted to circumvent auto-review. Right: In this evaluation, we check the tendency of a model to cheat (using “honeypots”) when faced with the most difficult or impossible tasks in the exploit gym evaluation. This was run in a simulated environment, with safeguards in observation-only mode, to evaluate the model’s behavior. While GPT‑5.6 Sol indicated higher likelihood for cheating in these scenarios, Astra did not attempt to use those shortcuts, and it was still able to legitimately solve some tasks.
Training models to be aligned is one layer of safety. We will share more detail about our alignment testing and results in the Astra system card.
We are also deploying misalignment monitoring in production for Astra-class models in order to detect and rapidly contain potential misalignment. These safeguards resemble our monitoring for internal deployments and involve a system of classifiers which check the model’s reasoning and actions for unauthorized behavior and automatically stop potentially unauthorized activity. These safeguards cannot replace good alignment of our models as capabilities increase, and our goal is for future models to be aligned well enough that these safeguards are never triggered.
What this will mean for users
OpenAI is committed to ensuring that the benefits of AI are broadly accessible. Given the significant increase in Astra’s cybersecurity capabilities, we are being especially careful to make this deployment safe and secure. Extra safety checks can sometimes slow, pause, or stop legitimate work, including defensive cybersecurity.
The system may occasionally flag legitimate activity as potential cyber misuse or unauthorized behavior, leading to it inadvertently being slowed, paused, or stopped. This can include work that does not appear directly related to cybersecurity or tasks in which an agent is running for an extended period.
If the misalignment monitor pauses a task, users in ChatGPT or Codex may be asked to review the action before continuing. When using other surfaces like the API, the task will stop. We plan to keep calibrating these safeguards to reduce unnecessary interruptions and expand access to frontier capabilities through programs like Daybreak.
Looking forward
We are entering a stage of AI development in which models can take on more consequential work, and failures of alignment and control can have more serious effects. Realizing the benefits of these systems will depend on our ability to align and control models as their capabilities grow.
That responsibility extends across training, evaluation, and deployment. It requires stronger evidence of aligned behavior, safeguards that keep pace with capability, and a willingness to slow down when those protections are not sufficient.
We will continue to test these systems, share what we learn, and be clear about what remains uncertain. The models that follow Astra will demand more of us. We will take the time and do the work needed to meet that responsibility.
本文内容采集自官方网站，排版和翻译可能与原页面存在差异。
阅读官方全文