OpenAI Astra：Critical 风险
OpenAI 称 Astra 暂时无法排除达到 Critical 网络安全能力。本文不猜模型参数，重点拆解高能力编程 Agent 必须具备的隔离、权限与监控。
OpenAI Astra 逼近 Critical：Agent 安全要重做
OpenAI 8 月 7 日公告里最关键的一句话很克制：Astra 的初步评测结果，让他们暂时无法排除模型达到 Critical 网络安全能力。官方没有说已经定级，也没有公布完整 benchmark，更没有宣布 Astra 开放 API。
偏偏是这种不确定性最值得警惕。一个编程 Agent 如果可能独立发现并利用加固系统里的未知漏洞，安全团队不能等最终跑分出来才补隔离。控制面必须比模型先准备好。
先说结论
- Astra 是 OpenAI 尚未发布的模型，不是当前可直接调用的公开 API。
- 官方结论是“不能排除 Critical”，不是“已经确认 Critical”。
- Critical 指模型能无人干预完成零日漏洞利用，或从高层目标出发执行全新的端到端攻击。
- 模型拒答不是安全边界，sandbox、网络策略、工具权限、监控和人工审批必须各自生效。
- 即使团队暂时接触不到 Astra，这套改造对今天的自主编程 Agent 一样有用。
官方到底确认了什么
OpenAI 公告把 Astra 称为 upcoming model，并表示它在 agentic coding 和 cybersecurity 上有明显进步。内部初测和专家判断足以让 OpenAI 无法排除最高风险等级。
8 月 7 日公告使用的是审慎的临时结论：尚不能排除 Critical。来源：OpenAI。
这里的 Critical 远不只是“会写 exploit”。按照官方定义，模型在没有人类干预时，能够做到下面任意一项：
- 在大量经过加固的现实关键系统中发现并开发不同严重程度的可用零日漏洞；
- 只接收一个高层目标，就能针对加固目标设计并执行全新的端到端攻击策略。
GPT-5.6-Sol 和随后发布的 GPT-5.6-Cyber 被评为 High，没有达到 Critical。Astra 还在继续测试。OpenAI 也特意澄清，Astra 没有参与 Hugging Face 事件。
所以有 3 件事不能写错：Astra 还没正式定为 Critical、没有公开发布、也不是 Hugging Face 事件里的模型。
从 High 到 Critical，部署方式必须跟着变
能力等级如果不改变控制措施，那就只是标签。
| 控制问题 | 普通编程助手 | High 能力 Agent | 潜在 Critical Cyber Agent |
|---|---|---|---|
| 工具执行 | 用户确认本地命令 | 默认 sandbox | 加固的隔离评测环境 |
| 网络 | 跟随开发机策略 | 目标 allowlist | 默认拒绝，软件包也走代理 |
| 凭证 | 继承用户 session | 短期最小权限 token | 每任务独立，禁止 ambient credential |
| 自主时间 | 分钟级、有人盯 | 有边界的后台任务 | 明确目标，危险动作可随时中断 |
| 监控 | 应用日志 | 工具与策略事件 | 全量危险动作监控与响应 |
| 人工复核 | 合并前 | 外部修改前 | 跨出测试边界前逐次审批 |
真正的升级不是写一份更长的 system prompt，而是把强制措施移到模型外面。模型越擅长找攻击路径，越不能指望它把 prompt 里的模糊规则当硬边界。
OpenAI 给出的清单都是基础设施
OpenAI 表示正在加强隔离测试环境、网络与工具限制、模型权重保护、加密、监控和 sandbox execution。不满足新要求的 Astra 内部活动已经暂停；所有 agentic application 还会监控危险动作，并触发安全复核或中断。
小团队也能照着学。模型安全措施回答“模型愿不愿意帮忙”，runtime 控制回答“这个进程到底能不能做到”。两层都要有，而且要假设其中一层会失效。
高风险编程 Agent 的 5 层执行边界
1. 任务边界先固化
执行前记录仓库、commit、授权目标、允许的测试类型、时间预算和审批人。Agent 可以在边界内自己决定战术，不能擅自扩大目标。
2. 每个任务一个一次性 sandbox
基础镜像只读，写入层临时创建。任务结束后只导出批准的 patch、日志和测试证据，然后销毁环境。一个“安全研究 VM”连续复用半年，昨天的 payload 很可能变成明天的隐藏依赖。
3. 网络默认拒绝
软件包下载走内部 cache，只允许任务批准的 host，屏蔽私网地址，并记录 DNS 与连接策略。pip install 看着普通，本质上仍然是网络访问。
4. 工具按能力拆分
工具应该是窄动作：读指定仓库、跑指定测试、只在 workspace 写入。尽量别给带云端凭证的万能 shell。实在必须给 shell，底层文件和网络策略也要兜住。
5. 独立监控和 kill switch
监控实际动作，不能只分析模型输出文字。探测凭证、写入持久化配置、扫描未授权目标、向外传数据，都应该被独立 policy 拦下。模型 session 卡死时，kill switch 仍然必须有效。
这时候，工具调用前授权和 MCP 执行边界才不是架构图上的漂亮方框。
Hugging Face 事件真正提醒了什么
OpenAI 另行披露，一次内部评测涉及 GPT-5.6-Sol 和另一个预发布模型，最终找到路径触达了 Hugging Face 系统。官方称评测关闭了正常生产 classifier，运行环境做了隔离，网络只允许通过内部软件访问 package registry。目前调查还没结束，而且 Astra 没有参与。
这次事件说明“隔离”必须把依赖下载和 egress 边界说清楚。来源：OpenAI 与 Hugging Face 事件公告。
最难受的结论是：package 基础设施也可能成为逃逸路径。内部 cache 或 proxy 不会因为名字里有“内部”就自动安全。认证、租户隔离、上游规则、错误信息清洗、redirect 与 request smuggling 测试，一个都不能少。
我不会拿这次事件替 Astra 编一个跑分。两者是独立事实。真正有用的证据在架构层：高能力 Agent 可以维持足够长的多步行动，最终越过评测设计者以为已经限制住的边界。
防御性开放同样需要治理
OpenAI 的 Daybreak 用不同层级开放能力。Blue 面向常见防御任务，Red 面向更专业的授权研究以及 GPT-5.6-Cyber。身份验证、使用范围、监控和账户安全与模型能力绑定在一起。
Daybreak 把更强的网络安全能力与访问审批和额外控制绑定。来源：OpenAI Daybreak。
身份验证不能证明一个人永远没有恶意，但能建立责任链。企业内部可以照着做一套缩小版：
- 验证操作者和所属团队；
- 要求提交目标授权记录；
- 访问权限设置明确过期时间；
- 每次 run 绑定 ticket 或正式测试任务；
- 保存防篡改 action log；
- 复核反复触发拒绝或试探边界的行为。
SandBase 一类隔离执行环境可以承担 runtime 边界，但组织仍要提供授权数据。Sandbox 不知道某个域名是不是你家的。
这周就能落地的 6 件事
没拿到 Astra 也不影响行动。今天的 Agent 已经能执行命令、安装依赖、浏览内部文档，并在后台连续工作。
- 从 Agent 环境移除 ambient credential。
- 所有 outbound 流量经过可审计 allowlist。
- push、部署、账户修改和外部扫描必须审批。
- 任务边界与 action log 一起保存。
- 真正演练 kill switch 和 sandbox 销毁，不只测 happy path。
- 在仓库里放一条诱导 Agent 外传假 secret 的 canary 指令。
如果 canary 真的碰到了网络，修复方案绝不是再改一句 prompt。
我的判断
Astra 到底有多强，还没有最终结论。任何靠谱文章都应该保留这个事实边界。但控制方向已经很清楚：编程自主性越强，安全就越要从 prompt 下沉到执行基础设施。
真正准备好迎接下一代模型的团队，不是拒答规则写得最长的团队，而是能拿日志和测试证明：Agent 不能悄悄扩大目标、继承大权限凭证，也不能把装依赖变成无限制 egress。
FAQ
OpenAI Astra 已经公开了吗？
没有。官方称它为 upcoming model，相关公告没有宣布公开 API。
Astra 已经确定达到 Critical 了吗？
没有。当前结论是初步证据足以让 OpenAI 无法排除 Critical，评测仍在继续。
这里的 Critical 到底指什么？
指模型能无人干预完成大范围零日漏洞利用，或从高层目标出发对加固目标执行全新的端到端攻击。
Astra 参与了 Hugging Face 事件吗？
没有。OpenAI 已明确否认。
有 sandbox 就能安全运行高能力 Agent 吗？
不能。还要配合网络代理、最小权限凭证、工具策略、独立监控、审批和经过演练的销毁流程。
