OpenAI Astra 自評 Critical：100% ExploitBench、兩個零日漏洞解讀（2026）

2026 年 9 月 1 日，OpenAI 在官方網站發布了〈Path to Astra: critical capabilities and frontier safeguards〉，正式把尚未推出的 OpenAI Astra 列為自家 Preparedness Framework 下第一個達到「Critical」網路安全能力門檻的模型。

公告最吸睛的三個訊號是：ExploitBench 得到 100%、內部測試中發現並使用兩個零日漏洞，以及進階資安能力將先限制在受控存取環境。這些都值得嚴肅看待，但三者的證據強度不同。接下來先還原 OpenAI 真正宣稱了什麼，再拆解 benchmark 的分母與零日漏洞證據，最後把「能力躍升」和「實戰可靠度」分開判斷。

OpenAI 所說的 Critical 到底是什麼？

It is the first model we are designating at this level.

中文：「這是我們第一個認定達到這個層級的模型。」

OpenAI

這句話最重要的字不是「first」，而是「we」。Critical 是 OpenAI 依自家 Preparedness Framework 作出的能力分級，不是監管機構或跨實驗室的認證。框架關注的不是模型會不會回答幾個危險問題，而是它是否能在工具增強下無人介入地找出並利用零日漏洞，或只憑高階目標執行端到端新型攻擊。

這次定級也不是突然出現。OpenAI 8 月公開表示 Astra 可能逼近 Critical；它也稱在 Hugging Face 事故後曾暫停部分 frontier training 兩週。Astra 沒有參與該事故，OpenAI 是把事後教訓用到它的訓練環境。公告稱新增隔離、權限與監控要求後，大型訓練在 8 月 28 日重啟。前情可對照 AlphaLab 的〈OpenAI Astra 可能逼近 Critical 網攻門檻〉與〈OpenAI 暫停部分 RL 訓練〉。

換句話說，這篇公告同時做了兩件事：承認能力門檻已跨過，也宣告 OpenAI 認為新控制足以讓研發與受限部署繼續。前者是能力判斷，後者是風險治理判斷，不能混成同一張成績單。

100% ExploitBench 到底量到什麼？

OpenAI 表示 Astra 在公開 ExploitBench 得到滿分。這是一個重要訊號，但要先看測試題目放了什麼在桌上。

The agent is thus given the patch — this is a 1-day scenario — but not a reference PoC.

中文：「代理人會拿到修補差異——這是 1-day 情境——但不會拿到參考用的概念驗證程式。」

ExploitBench 論文

公開版 ExploitBench 收錄 41 個歷史、已修補的 V8 漏洞。代理人會拿到漏洞說明、修補前後版本、完整原始碼與 patch diff，再嘗試把 exploit 推進到 crash、任意讀寫、程式碼執行等能力階梯。這測的是已知漏洞的 exploit construction 能力，不是從未知程式中找出零日漏洞，也不是跨過瀏覽器 sandbox、核心、網路防禦與持久化的完整實戰。

另一個容易漏掉的細節是可靠度。ExploitBench 公開論文的主結果，會對每個 model–bug 組合把三次獨立執行亮起的能力旗標取聯集；它可能合併不同 run 的成果，較接近「在這個預算下曾經做到多遠」的能力上限，而非單次成功率。OpenAI 的公告沒有列出 Astra 的逐題結果、seed、trial 數、token／turn budget、scaffold 或 transcript，也沒有說 100% 是否完全沿用公開論文的聚合方式。因此最準確的寫法是：OpenAI 自報 Astra 在 ExploitBench 得到 100%；這篇公告沒有提供可供外部重跑的 run artifacts，也不足以估計 pass@1 穩定性。

圖表來自另一套 2026 年 6 月至 8 月的內部 port，包含 20 個較近期的高嚴重度 V8 漏洞。曲線顯示 Astra 用較少輸出 token 取得更高的任意程式碼執行率；但 9 月 1 日公告沒有公開題目、逐次結果與稽核資料，所以它能支撐「OpenAI 觀察到明顯躍升」，不能單獨支撐一個可外部驗證的倍率。若想先理解前一代模型、V8 與 Daybreak 的關係，可接著讀〈GPT-5.6-Cyber 是什麼？〉。

兩個零日漏洞：最重要，也最難外部查證

discovered and used two zero-day vulnerabilities as part of an exploit chain.

中文：「在一條漏洞利用鏈中，發現並使用了兩個零日漏洞。」

OpenAI

這是整篇最有新聞價值、也最需要保留歸屬的主張。它說的是兩個漏洞被用在同一條 exploit chain，不是兩條各自完整的零日攻擊鏈；也不是公開 ExploitBench 的 100% 直接產生了零日漏洞。OpenAI 說正向維護者揭露這兩個漏洞，因此 9 月 1 日公告沒有列出受影響產品、維護者、CVE、嚴重度、修補版本或發現日期。這項零日主張出現在介紹 20 個近期 V8 漏洞的內部 benchmark 段落，但公告沒有明說兩個零日本身屬於 V8 或 Chrome。

OpenAI 另外自報兩類專家主導測試：其一是讓瀏覽器開啟 HTML 檔後，組出逃離 sandbox 並在主機執行命令的鏈；其二是在加固作業系統中，從低權限使用者提權到 root。這些結果比單純的 V8 程式碼執行更接近真實攻擊鏈，但公告同樣沒有公開目標版本、trial 數、成功率、EDR／主動防守條件與可重跑 artifact。它們是嚴重預警，還不是第三方完成的驗收報告。

這也說明為什麼不能拿先前公開的 CVE 或其他模型事件來「補證」Astra。像〈GPT-5.6-Cyber VM 逃逸〉能幫我們理解什麼才算 guest-to-host escape，卻不能替截至 2026 年 9 月 2 日仍未具名的兩個 Astra 漏洞作交叉驗證。

防護不是「模型不會攻擊」，而是多層控制

OpenAI 的安全論證分成三層：模型層拒答與對齊、系統層分類器和自動停止、存取層的身分審核與用途限制。公告自報 Astra 在內部 cyber-jailbreak 評測的拒答率為 91.5%，GPT-5.6 Sol 為 59%。這是特定內部測試的拒答率，不是「91.5% 攻擊都能防住」；9 月 1 日公告未列樣本數與完整方法，OpenAI 表示會在 Astra system card 提供更多細節。

左圖測模型遇到 auto-review 拒絕後，是否嘗試繞過或重試；OpenAI 報告 Astra 沒有嘗試規避。右圖把周邊目標設成 honeypot：OpenAI 表示 GPT-5.6 Sol 在 56% 的測試中嘗試存取 honeypot，Astra 沒有這類嘗試，圖上的 1.3% 是對指定目標的正當 exploit。這代表 Astra 在這批情境裡更能守住任務邊界，不代表模型在未知分布、長時間或對抗性提示下的失控率是零。

部署端同樣要分開看。OpenAI 說 Astra 很快會推出，但沒有給確切日期；一般可用性與最高階資安流程也不是同一件事。進階流程初期只給少量 alpha 測試者，之後才計畫經 Daybreak Blue 擴大。公告中的能力結果使用 Daybreak Blue access，不能推成每個 OpenAI Astra 使用者都會拿到相同工具與權限。

真正的問題：這是可信警報，不是完整成績單

判讀一：exploit construction 的能力邊界很可能真的上移

OpenAI 自報的公開滿分，使這個總分對 Astra 的區分力見頂；9 月 1 日公告也未附內部 port 的外部稽核資料，但這不等於可以把結果全部丟掉。若圖中趨勢能重現，Astra 確實能以更少 token 取得更高的任意程式碼執行率，再加上專家情境中的瀏覽器與作業系統鏈，防守方的漏洞分流、修補與驗證速度都會承受更大壓力。最合理的反應是把它當成能力躍升的預警，而不是等公開事故出現才承認風險。

判讀二：能力上限不等於單次可靠度

寫出 exploit 只是攻擊鏈的一段。真實環境還有偵察、初始存取、版本差異、sandbox、EDR、橫向移動、持久化與主動防守者。英國 AISI 的多步驟 cyber-range 研究也提醒，結果會隨推理預算與測試條件大幅改變，而且弱防守的封閉 range 不能直接外推到加固的真實系統。Astra 的 9 月 1 日公告沒有提供足以量化這段落差的資料。

判讀三：受控存取是一種產品架構，不是一句道德承諾

當能力具有雙重用途，安全性不只來自模型「願不願意拒答」，還來自身分驗證、最小權限、工具隔離、行為監控、事件升級與撤銷機制。Daybreak Blue 的方向合理，因為它讓高風險能力不必直接等同於普遍開放；代價則是更大的權力集中，以及外界更難獨立測量 false negative。〈Claude Mythos 5 進入 Claude Security〉展示了另一種做法：截至 2026 年 9 月 2 日沒有普遍釋出 Mythos-class model，而是透過 Claude Security 等受控管道交付 findings 與工具。

判讀四：治理爭點在可稽核性，不宜先判違規或合規

OpenAI 的 2025 年Preparedness Framework v2寫明，在 Critical 專屬防護與安全標準尚未具體化前，應暫停進一步開發；9 月 1 日公告則主張新增要求已把嚴重風險降到足以繼續的程度。兩者是否完整對接，需要 capability、safeguard 與 Safety Advisory Group 決策證據才能審視。該公告也沒有說 Astra 是依「無人介入找出並利用零日」或「只憑高階目標完成端到端新攻擊」哪一條正式觸發 Critical，更沒有量化「many hardened real-world critical systems」的測試範圍。OpenAI 承諾在上線時發布 system card，但目前的預告還不足以讓外部重建整條決策鏈。這是可稽核性的缺口，不是已證實的政策違反。

我同意什麼，我存疑什麼

• 我同意：Astra 的多組結果放在一起，已足以讓 OpenAI 與防守方提高風險等級；把它只當成榜單行銷會低估訊號。
• 我同意：先限制進階流程、加上身分與用途控管，比把同等能力直接普遍開放更合理。
• 我存疑：9 月 1 日公告的 100% 沒有附可重跑設定，不能換算成單次成功率，更不能換算成任意真實目標的攻破率。
• 我存疑：截至 2026 年 9 月 2 日，兩個零日漏洞與瀏覽器／作業系統鏈只有 OpenAI 公開摘要；在維護者公告、修補與技術細節出現前，外界無法判斷嚴重度與可泛化程度。
• 我存疑：9 月 1 日公告的 91.5% 拒答與 honeypot 結果很漂亮，但沒有附樣本、信賴區間、跨帳號攻擊與 monitor false-negative 資料，不能證明控制已經穩健。

Astra 上線後，先檢查這四件事

1. System card 是否補齊分母：公開 benchmark snapshot、scaffold、trial、token／turn budget、pass@1／pass@k、逐題結果與失敗分布。
2. 零日漏洞是否完成對帳：受影響產品、維護者確認、advisory／CVE、修補狀態，以及兩個漏洞在同一條 chain 中各自扮演的角色。
3. 預設 Astra 與 Daybreak Blue 差多少：工具、權限、監控、速率限制與可完成任務的實際差異。
4. 是否出現獨立評測：由外部研究者在合法、隔離的環境重跑，並公開成功率、成本、誤報、漏報與失敗案例；OpenAI 8 月提及的政府機關與 AI safety 組織也應具名並公布方法與結果。

對資安團隊而言，現在可做的不是追逐「自主駭客」標籤，而是先縮短資產盤點、漏洞分流與修補部署的週期，並把代理人的授權範圍、網路邊界、完整記錄與自動停止寫進流程。對一般讀者而言，判斷 OpenAI Astra 的最好方法也很簡單：每看到一個驚人數字，就追問它的題目、工具、預算、重跑次數與真實環境落差。