OpenAI Astra 还没正式开放，为什么已被列为 Critical 网络安全模型

OpenAI Astra 还没正式开放，为什么已被列为 Critical 网络安全模型

OpenAI 9 月 1 日宣布，待发布模型 Astra 已达到 Preparedness Framework 中的 Critical 网络安全能力门槛。这是 OpenAI 首次给模型作出这一等级判断。官方称，Astra 在获得适当工具和访问权限后，能够在缺少逐步人工指导的情况下寻找未知漏洞，并为多种加固系统开发利用方式。模型计划“很快”提供，但高级网络安全能力会先限于少量测试者，随后才通过 Daybreak Blue 扩大防御用途。

这段公告同时包含模型能力、实验配置和未来产品安排，读者很容易把它们混为一谈。Astra 目前没有面向所有开发者开放的通用 API，系统卡也要等正式发布时才公布。OpenAI 披露的成绩来自安全加固评测环境，其中一部分使用 Daybreak Blue 权限，并不代表普通 ChatGPT、Codex 或未来默认 API 配置能够执行同样任务。

Critical 描述的是能力上限，不等于产品已经上线

OpenAI 的门槛定义关注两类能力：在许多加固关键系统中自主发现并利用零日漏洞，或者仅凭高层目标规划并执行端到端新型攻击。官方称 Astra 在已知漏洞利用基准 ExploitBench 上得到 100%，随后又用 2026 年 6 至 8 月披露的 20 个高危 V8 漏洞建立内部测试集，以降低训练数据污染的影响。模型在评测中还发现并利用了两个零日漏洞，OpenAI 正在向维护者披露。

这些结果很重要，但仍是厂商报告。内部测试集、完整提示、工具链和逐题结果尚未公开，外部团队无法独立复现全部结论。公告也特意注明，结果反映的是带 Daybreak Blue 访问能力的 Astra，不是默认生产配置。判断模型适不适合企业漏洞管理时，应把“能力上限”“默认可用能力”“账号实际获批权限”写成三列，不能只引用一个满分。

更强的安全栈会带来可见的中断

OpenAI 披露，Astra 在一组网络安全越狱评测中拒绝了 91.5% 的不允许请求，对比 GPT‑5.6 Sol 的 59%。公司还加入跨会话监控、系统分类器和对未授权行动的自动停止机制。另一个模拟测试观察模型遭到 auto-review 拒绝后的行为，Astra 没有尝试绕过审核；这些数字描述特定测试条件，不能推导为生产环境绝不会越权。

用户会感知到这些保护。OpenAI 明确表示，合法的长时间防御任务也可能被减速、暂停或终止。在 ChatGPT 或 Codex 中，用户可能收到复核提示；通过 API 运行时，任务会直接停止。调用方需要区分安全中断、速率限制、网络超时和普通模型错误，避免把被拦截任务自动重试到另一个限制更松的模型，绕开原本的控制意图。

工程上可以给这类响应单独状态码和人工队列，保留任务目标、授权范围及被停止前的工具记录。若业务要求连续处理，备用模型也必须继承相同的权限政策。选择 [AI 中转站](/) 或多模型 API 时，路由规则要把“安全能力”和“允许用途”分开配置，不能只按价格、延迟自动切换。

上线前先等待系统卡，再做受限验收

Astra 值得关注，但现在还不是依据传闻采购或改造生产流程的时点。系统卡、正式 API 名称、地区和账户资格、数据保留、价格与限额都尚未完整公布。企业可以先整理授权资产、隔离沙箱、人工复核点和停止后的恢复流程，等正式资料出现后再用自有任务集验证漏洞发现率、误报、修复质量和中断频率。

评测高风险安全模型时，至少让安全团队复核目标授权，并用另一个独立模型或确定性扫描器交叉检查修复结论。Astra 的信号并非“网络安全已经自动化”，而是模型能力和运行控制必须同步升级。谁能调用、能碰什么工具、何时必须停止，这些问题会比单一基准分数更早进入生产验收表。

来源：[OpenAI：Path to Astra](https://openai.com/index/path-to-astra/)