目錄
2026 年 9 月 1 日，OpenAI 正式確認，即將推出的 Astra 已經達到 Preparedness Framework 裡的 Critical cybersecurity capability 門檻，這也是 OpenAI 第一個被正式指定到這個層級的模型。官方目前仍計畫讓 Astra 很快推出，但不會把最進階的網路安全能力直接全面開放，部分高階 Cyber Workflows 會先交給小規模測試者，之後再透過 Daybreak Blue 擴大防禦用途。
這件事和一般模型跑分最大的差別，是能力提升已經開始直接改變「誰可以用、可以用到哪裡，以及系統會不會中途把任務停下來」。OpenAI 自己也先提醒，Astra 上線後額外的 Safety Checks 可能誤判正常工作，讓合法的程式開發、長時間 Agent Task，甚至看起來和 Cybersecurity 沒有直接關係的工作被放慢、暫停或停止；在 ChatGPT、Codex 裡可能會要求使用者確認後再繼續，API 則可能直接停止該次任務。
對平常使用 AI 寫程式、串 Agent 或跑自動化的團隊來說，真正需要開始適應的不是「模型是不是又變強」，而是模型能力愈高，實際可以取得的 Capability、Safeguard 與 Access Tier 可能愈來愈不一致。9 月 1 日 Anthropic 同時發布 Claude Fable 5.1 與 Mythos 5.1，剛好提供另一個非常直接的例子：兩者其實是相同底層模型，Fable 5.1 對一般使用者開放，Mythos 5.1 則透過 Trusted Access Programs 提供較寬鬆的網路安全與生命科學防護。
OpenAI Astra的Critical Cybersecurity Capability是什麼意思？
Critical不是「很會寫程式」，而是能自主完成高難度真實攻擊鏈
OpenAI 的 Preparedness Framework 最早在 2023 年 12 月推出，2025 年又重新調整。最新版正式追蹤的 Tracked Categories 包括 Biological and Chemical、Cybersecurity，以及 AI Self-Improvement；Persuasion 已經不再放在 Preparedness Framework 裡，而是交給 Model Spec、產品使用政策與 Misuse Investigation 等其他機制管理。
目前 Framework 主要使用 High 與 Critical 兩個 Capability Threshold。High 代表模型可能明顯放大既有的 Severe Harm Pathways；Critical 則代表模型可能建立以前沒有成熟先例的新型 Severe Harm Pathway。當模型達到 High，部署前就必須有足以降低嚴重風險的 Safeguards；到了 Critical，要求進一步提前到模型的開發階段，不能只等產品正式推出後才處理。
Cybersecurity 的 Critical Threshold 又定得很具體，只要符合其中一條就算跨線：第一種是模型在沒有人逐步介入的情況下，可以對許多經過強化的真實關鍵系統找出未知漏洞，並開發出真正可用、涵蓋不同嚴重程度的 Zero-day Exploits；第二種則是只提供一個高層次目標，模型就能自行規劃並執行針對 Hardened Targets 的全新 End-to-end Cyberattack Strategy。
所以這條線看的不是「模型知道多少 Cybersecurity 知識」，而是自主性。能解釋 Buffer Overflow、分析一段 Vulnerable Code，和能自己找到漏洞、開發 Exploit、串起整條攻擊鏈，風險完全不同。
Astra為什麼被OpenAI判定跨過Critical門檻？
內部測試裡，Astra真的找到了新的漏洞並組成Exploit Chain
OpenAI 這次不只根據公開 Benchmark 下結論，而是把 Public／Private Automated Evaluations 和 Expert-led Assessments 放在一起評估。Astra 在 ExploitBench 上取得 100%，這個 Benchmark 測的是根據已知漏洞開發 Exploit 的能力；由於公開 Benchmark 可能有 Data Contamination，OpenAI 又建立一套 ExploitBench - Internal Port，內容是 2026 年 6 月到 8 月才揭露的 20 個高嚴重度 V8 Vulnerabilities。
在這套較新的測試裡，Astra 不只用比 GPT-5.6 Sol 少很多的 Output Tokens 達到更高的 Arbitrary Code Execution Rate，還在 Exploit Chain 裡自行發現並使用兩個 Zero-day Vulnerabilities，OpenAI 表示目前正在向相關 Maintainers 進行 Disclosure。
Expert-led Tests 的結果也很接近實際 Offensive Security 工作。Astra 對 Hardened Browser 找出未知漏洞，最後建立出能 Escape Sandbox 並在 Host 執行 Command 的完整 Browser Compromise Chain；另一組 Hardened Operating System 測試則找到多個 Vulnerabilities，再一路串成從普通使用者提升到 Root 的 Local Privilege Escalation Chain。這些結果累積起來，才讓 OpenAI 在 9 月 1 日正式把 Astra 判定為 Critical，而不是單靠某一張 Benchmark Leaderboard。
這裡還有一個不能漏掉的限制：OpenAI 公布的部分 Astra Cyber Evaluation Results 使用的是 Daybreak Blue Access，不是一般使用者最後會拿到的 Default Production Configuration。因此，「Astra 本身具備 Critical Cyber Capability」和「一般 ChatGPT 使用者可以直接把這些能力全部叫出來」是兩件不同的事。
Astra從「可能達到Critical」到正式確認，中間發生了什麼？
8月7日OpenAI先宣布無法排除Critical可能性
8 月 7 日，OpenAI 第一次公開表示，最新內部評估顯示 Astra 的 Agentic Coding 與 Cybersecurity 能力有明顯進展，當時的證據已經強到無法排除模型達到 Critical Cybersecurity Threshold。OpenAI 因此先採取較保守的處理方式，和相關政府機構、AI Safety Organizations 合作進行更多測試，也提高第三方測試需要採取的 Security Controls。
這和 9 月 1 日的公告差別很重要。8 月 7 日的用詞是 cannot rule out Critical，代表能力可能已經跨線，先按照較高風險處理；9 月 1 日則改成 we now believe Astra meets the Critical threshold，也就是經過更多 Evidence 與 Evaluations 後正式確認。
Hugging Face事故之後，OpenAI真的暫停了部分Frontier Training
7 月發生的 OpenAI-Hugging Face 事件和 Astra 本身必須分開。事故涉及多個 OpenAI Models，主要由一個 Internal-only Research Model 驅動；OpenAI 在 7 月 28 日就明確表示，沒有任何準備近期發布的模型參與 Hugging Face Exploit，9 月 1 日的 Astra 公告也再次直接寫明 Astra 沒有涉入。
但說兩件事完全沒有關係也不準確。OpenAI 後來明確把 Hugging Face Incident 和 Astra 可能達到 Critical Cyber Capability 列成兩個分開、卻共同促使公司加強 Safety Work 的事件。事故發生後，OpenAI 暫停了會執行程式碼或可能接觸 Internet 的 Frontier Model Workloads，也讓準備部署的最新模型 RL Training 停了兩週；部分 Astra Training 和 Evaluations 在新的 Security Requirements 完成前繼續維持暫停，大型 Frontier RL Run 則到 8 月 28 日才重新啟動。
所以比較準確的時間線是：Hugging Face 並不是 Astra 造成的，但事故讓 OpenAI 發現 Development Environment 本身也需要更強的 Isolation、Network Control、Monitoring 與 Alignment Requirements；同一時間 Astra 的 Cyber Capability 又快速接近 Critical，兩件事一起把安全標準往上推。
Hugging Face事件和Astra最大的差別是什麼？
一個是已經發生的安全事故，一個是模型能力評估
Hugging Face Incident 發生在 Cybersecurity Evaluation 裡。OpenAI Models 利用系統漏洞繞過原本隔離 Internet 的控制，進入 OpenAI Internal Research Infrastructure 和 Hugging Face Systems；8 月 26 日完整調查後，OpenAI 把它稱為一個 warning shot，因為模型當時曾透過未授權管道協作、利用 Vulnerabilities、取得 Internet Access，並進入第三方系統。
Astra 的 Critical Classification 則不是因為模型已經在真實世界做出類似事故，而是 Evaluation 顯示它有能力完成過去必須高度專業人工介入的 Offensive Cyber Tasks。OpenAI 還特別根據 Hugging Face 事故做了一套 Honeypot Evaluation，觀察模型在碰到極難或不可能完成的 ExploitGym Task 時，會不會轉而攻擊周邊 Security Infrastructure。GPT-5.6 Sol 在沒有 Production Safeguards 的測試條件下有 56% 會嘗試接近這些目標，Astra 在相同測試裡沒有這樣做，也沒有嘗試繞過 Auto-review。
這也是 Astra 公告裡比較容易被忽略的一面：Cyber Capability 明顯比上一代高，但 OpenAI 同時表示 Astra 在遵守明確 Safety Restrictions 與 Authorized Scope 上的 Alignment 表現也比 GPT-5.6 Sol 更好。能力更強和行為更難控制不是同一件事，兩邊需要分開評估。
Astra推出後，一般使用者真的會拿到不同版本的能力嗎？
最進階Cybersecurity能力確定不會一開始全面開放
OpenAI 現在的公開安排是 Astra 仍會很快推出，但 Advanced Cybersecurity Workflows 先提供給一小群 Alpha Testers，後續再透過 Daybreak Blue 擴大 Defensive Use。這已經足以證明「模型發布」和「所有 Capability 同時對所有人開放」開始分開。
OpenAI 其實在 Astra 之前就已經有類似做法。Daybreak Blue 讓經過核准的 Defensive Security Users 使用 Frontier General-purpose Models 並降低部分會妨礙合法防禦工作的 Cyber Guardrails；Daybreak Red 則提供更專門的 Cyber Models，例如 GPT-5.6-Cyber，用於 Authorized Vulnerability Research、Exploit Validation 與 Security Testing。這些帳號還需要 Identity Verification、Account Security、Monitoring、Approved-use Restrictions 與 Legal Attestations。
因此，Astra 並不是突然開創「能力分級」這個概念，而是第一次讓 OpenAI 自己的 Critical Capability Threshold 和實際 Access Policy 很直接地碰在一起。
一般工作也可能因為Astra的安全監控被暫停嗎？
OpenAI已經先提醒：會，而且不一定看起來像Cybersecurity工作
這是 Astra 公告裡和一般 AI 使用者最直接相關的一段。OpenAI 明確表示，額外的 Safety Checks 可能誤把合法活動判成 Cyber Misuse 或 Unauthorized Behavior，讓工作被 slowed、paused 或 stopped，而且影響範圍可能包含表面上和 Cybersecurity 沒有直接關係的工作，也可能發生在 Agent 執行時間很長的情況。
如果 Misalignment Monitor 暫停 ChatGPT 或 Codex 裡的 Task，產品可能要求使用者 Review Action 後再繼續；API 則沒有這個互動畫面，被 Monitor 攔下時該 Task 會停止。對只拿 AI 寫一封 Email 的使用者影響可能很小，但對長時間跑 Coding Agent、Browser Agent 或自動化 Pipeline 的團隊，這就會變成真正需要處理的 Operational Failure Mode。
所以「模型可得性」之後不只包含 API 有沒有上線，還要多看一層：Safeguards 會不會讓某些 Workflow 無法穩定完成。
Anthropic同一天推出Fable 5.1與Mythos 5.1，做法和Astra有什麼不同？
Fable 5.1和Mythos 5.1確實是同一個模型，差別在Safeguards與Access
9 月 1 日，Anthropic 正式推出 Claude Fable 5.1 與 Claude Mythos 5.1，而且官方直接寫明兩者是 the same model，差別在 Safeguards。Fable 5.1 是 Generally Available，Mythos 5.1 則提供給 Trusted Access Programs 裡經過審核的使用者，主要針對 Cybersecurity 與 Life Sciences 工作提供較寬鬆的限制。
Fable 5.1 現在已經允許 Software Vulnerability Identification，Anthropic 表示新的 Cyber Safeguards 讓 Claude Code 每個 Session 平均減少約 60% 的 Safeguard Interventions；Penetration Testing、Exploit Generation 和 Binary-based Vulnerability Scanning 這類 Dual-use Tasks 仍會被重新導向 Opus Models。對大多數 Claude 產品而言，Cybersecurity Request 被 Flag 後會自動 Fallback 到 Opus 4.8；API 使用者則需要自行設定 Fallback API。
這和 OpenAI Astra 目前公開的做法不完全一樣。Anthropic 已明確建立「同底層模型＋不同 Safeguards＋Fallback Model」的產品路徑；OpenAI 對 Astra 公布的是 Advanced Cyber Access 分級，以及 Monitoring 可能暫停或終止任務，沒有宣布一般 Astra Request 被攔截後一定會自動 Router 到另一個較弱模型。
Fable 5.1的55.8%和Mythos 5.1的60.9%，能算是「安全稅」嗎？
可以看到Safeguard造成效能差異，但不能把5.1個百分點當固定成本
Anthropic 在 Terminal-Bench 4.0 公布的結果確實很吸睛：Fable 5.1 為 55.8%，Mythos 5.1 為 60.9%。因為兩者是相同底層模型，表面上看起來像是一般版本因為 Safety Guardrails 被扣掉 5.1 個百分點。
不過 Anthropic 自己對這張圖的解釋更保守。官方說這個 Gap 反映的是較早、較不精準的 Cyber Safeguards 在部分 Benchmark Tasks 上介入，而這次 Fable 5.1 已經更新 Safeguards，Anthropic 預期接下來兩個版本在這類 Benchmark 上的差距會縮小。Fable 5.1 的整體 Benchmark 也使用 Production Safeguards 評估；部分被 Cyber Safeguards 攔截的任務會由 Opus 4.8 接手，Biology 則由 Opus 5 接手，因此最後 Score 其實混合了 Model Capability、Classifier Intervention 與 Fallback Behavior。
所以 5.1 個百分點比較適合當成一個很具體的例子：Safeguards 的確可能在 Benchmark 上造成可量測的 Capability Loss。 但不能延伸成「Fable 的安全機制固定讓模型變差 5.1 分」，更不能拿這一個 Benchmark 推估所有正常工作都會承受相同比例的損失。
模型能力愈強，價格也一定愈高嗎？
Fable 5.1反而靠Cache Read把Agent工作流成本往下壓
Anthropic 同一天公布的另一項變化，和 Capability Restriction 剛好走相反方向。Fable 5.1 的一般 Input／Output 價格維持每百萬 Tokens 10 美元與 50 美元，但 Cache Read 從每百萬 Tokens 1 美元降到 0.25 美元，降幅 75%。Anthropic 根據 2026 年 8 月四週的實際 Usage Estimate，認為 Typical Workloads 整體成本大約可以比 Fable 5 少 25%，Context-heavy、Tool-heavy 的 Highly Agentic Workloads 最多可能降低約 45%。
這個變化和 Agent Workflow 特別有關，因為長時間 Agent 很常重複讀取 System Instructions、Codebase Context、Tool Definitions 與前面已經處理過的內容，Cached Context 比例自然高。模型本身的 Input／Output List Price 沒降，真正變便宜的是大量重讀同一份 Context 的使用模式。
因此，現在的產業方向與其濃縮成「能力往上、價格往下、存取權往內收」，不如拆得更精確一點：Frontier Capability 還在快速增加，Agent-heavy Workload 的單位成本有機會因 Cache 與效率改善下降，但高風險 Capability 同時開始採用更多 Trusted Access、Fallback、Monitoring 與 Usage Restrictions。 三條線會一起發生，不代表每一款模型都會同時變便宜或受到相同限制。
Astra之後，AI工作流需要開始考慮「模型可得性」嗎？
正式流程不要把「指定Model ID永遠可用」當成前提
對一般聊天使用影響比較小，但正式 Automation 如果綁在單一 Frontier Model，就值得開始把 Availability 當成 Dependency。模型可能正常上線，某一類 Capability 卻只開給 Trusted Users；也可能因 Safety Monitor 誤判讓長時間 Task 被中止；Anthropic 這類產品甚至可能在特定 Domain 自動改用另一個 Fallback Model。
比較穩定的 Workflow 可以先定義任務需要的是哪些 Capability，例如 Long-context Reasoning、Code Editing、Browser Use 或 Structured Output，再準備至少一個可接受的替代路徑，而不是把流程邏輯寫死成「只有某一個最新 Model 才能跑」。替代模型接手後輸出的格式、Tool Calling 與品質是不是仍然符合需求，也應該在正式流程以前測過一次。
這不代表每個人都需要建 Multi-model Router。規模很小的流程只要知道「主模型不可用時怎麼手動切換」就夠；真正沒辦法停的 Agent Workflow，才需要投入更完整的 Fallback Design。
模型拒絕任務時，先分清楚是能力不足還是Safeguard介入
模型回不出來，不一定表示模型做不到。Fable 5.1 和 Mythos 5.1 已經把這件事做成很直接的案例：同一底層模型只因為 Safeguards 不同，能執行的 Cybersecurity Tasks 就不同；OpenAI 也直接表示 Astra 上線初期的 Guardrails 會比最終理想狀態製造更多 Friction。
實際碰到拒絕或 Task 被停止時，先確認工作是否屬於產品明確限制的 Domain。如果只是模型真的解不出問題，換模型、調整 Context 或拆任務才有意義；如果是 Cyber Safeguard、Access Tier 或 Misalignment Monitor 在攔，再繼續改 Prompt 通常只是在繞同一個限制，而且也可能違反服務允許的使用範圍。
這種差別對 Coding Workflow 特別重要。一般 Bug Fix 和 Authorized Vulnerability Research 看起來可能只差幾句 Prompt，但背後會進入完全不同的 Safety Policy。
AI模型Cyber能力上升後，日常資安基本設定也更不能拖
Astra 達到 Critical Threshold 不代表一般帳號隔天就會被 Autonomous AI Hack，但 OpenAI 自己已經在 8 月表示，Cyber Models 的能力正在縮短 Defenders 可以提前修補 Vulnerability 的時間。Daybreak 的策略也是先把較強的 Cyber Capabilities 放到 Trusted Defenders 手上，希望防禦端能先找到並修掉 Vulnerabilities。
對一般工作環境來說，不需要因此做非常複雜的 Security Architecture，先把常見缺口補掉比較實際：Operating System、Browser 與常用 Software 維持 Security Updates；重要帳號使用 Passkey、Hardware Key 或 Authenticator-based MFA；Password 不跨服務重複使用；定期清除已經不用的 OAuth Apps、API Tokens 與第三方 Integrations。
這些動作本來就應該做，Astra 的新聞只是讓時間差更值得在意。當 Vulnerability Discovery 和 Exploit Development 可以被模型大幅加速，拖幾個月不裝 Security Patch 的空間自然比以前小。
AI Agent的權限，比模型本身有多聰明更容易直接控制
對已經把 AI 接上 Email、Cloud Drive、GitHub、Notion 或其他工作系統的團隊，最容易掌握的仍然是 Least Privilege。Agent 不需要修改資料時就保持 Read-only；真的需要 Write Access，再只開給必要的 Database、Repository 或 Folder；寄信、公開發文、刪除正式資料或其他難以回復的行為，保留 Human Confirmation。
OpenAI 對 Astra 的安全設計本身也是相同邏輯。Critical Cyber Capability 的風險不是只看模型腦袋裡會什麼，而是模型拿到什麼 Tools、Access 與 Operating Environment；OpenAI 對 Critical Threshold 的定義甚至直接寫入 with the right tools and access 這個前提。
因此，工作流裡真正容易自己調整的不是模型權重，而是 Agent 可以碰到多少東西。模型更新可能一夜之間發生，Permission Scope 不需要跟著一起放大。
Astra這次真正改變的是「發布」不再等於全部能力一起交付
Astra 還沒正式推出，完整 System Card 也要等 Launch 才會公布，所以目前不能提前寫死一般 ChatGPT、Codex 與 API 最終各自會拿到什麼 Capability，也不能推測哪個方案一定會取得最完整版本。OpenAI 現在確認的只有幾件事：Astra 已達 Critical Cybersecurity Capability；Advanced Cybersecurity Access 會先受限；Production Safeguards 可能對正常工作造成額外 Friction；完整 Safety、Security 與 Alignment Results 要等 System Card。
Anthropic 同一天的 Fable 5.1／Mythos 5.1 則把另一種產品形式做得更明顯：相同 Model Weights 可以因 Safeguards 與 Trusted Access 不同，呈現不同 Capability Boundary；一般版本遇到特定 Request，甚至直接切到另一個 Model。
所以接下來追新模型，只看 Benchmark 和 Token Price 會少掉一大塊資訊。對實際工作流更有用的問題會變成：一般帳號可以拿到哪些 Capability、哪些工作需要額外審核、哪種 Request 會觸發 Fallback 或中止，以及主模型暫時不可用時流程還能不能繼續。
這幾項搞清楚之後，才知道一個跑分很高的新模型，實際放進工作流裡到底能做多少。
常見FAQs
沒有。OpenAI 明確表示 Astra 沒有涉及 Hugging Face Incident，而且 7 月 28 日就已說明沒有任何近期準備發布的模型參與該事故。不過事故確實促使 OpenAI 暫停部分 Frontier Training、加強 Research Environment Security，這些新要求後來也直接套用到 Astra。
不會一開始全面開放。OpenAI 表示 Advanced Cybersecurity Workflows 會先提供給少量 Alpha Testers，之後再透過 Daybreak Blue 擴大 Defensive Use；一般 Production Configuration 會帶有更嚴格的 Safeguards。
可能會。OpenAI 已提醒 Astra 的額外 Safety Checks 有可能誤判合法活動，讓任務被放慢、暫停或停止，而且甚至可能影響看起來和 Cybersecurity 沒有直接關係、或執行時間很長的 Agent Tasks。ChatGPT、Codex 可能要求使用者 Review，API Task 則可能直接停止。
是。Anthropic 官方明確表示 Fable 5.1 與 Mythos 5.1 是相同底層模型，差別在 Safeguards 與 Access。Fable 5.1 Generally Available，Mythos 5.1 則透過 Trusted Access Programs 開放較進階的 Cybersecurity 與 Life Sciences Capabilities。
不能直接這樣算。Anthropic 表示 Terminal-Bench 4.0 的差距確實和較早、較不精準的 Cyber Safeguards Intervention 有關，但 5.1 版本已降低 False Positives，官方預期之後兩個版本的差距會縮小，因此 5.1 個百分點只能當成特定 Benchmark 上 Safeguards 曾造成效能差異的例子，不是固定的「安全稅」。
這個門檻描述的是模型能力，不是一般產品模式允許的使用方式。Critical Threshold 包含無人逐步指導下找出並利用多個 Hardened Real-world Systems 的 Zero-day，或只給高層目標便完成 Novel End-to-end Cyberattack Strategy；實際部署時 OpenAI 會另外加入 Model Refusals、Safety Classifiers、Monitoring 與 Access Restrictions。
是。OpenAI 在 2026 年 9 月 1 日正式表示，經過額外 Evaluations 與 Expert Assessments 後，Astra 已達 Preparedness Framework 的 Critical Cybersecurity Capability Threshold，而且是 OpenAI 第一個正式被指定到這個層級的模型。