OpenAI 公開了自家資安營運的改造成果，並將其命名為 Defense Factory。這是一套持續運轉的機制：AI 代理程式找出漏洞、重現問題、產生修補方案，並確認修補確實生效。人的角色則轉向劃定界線與處理例外狀況。背後的急迫感相當直接——攻擊方正藉助能力不斷提升的開放權重模型推進自動化，防守方若無法以相同速度行動，就會被拋在後頭。
防守方還剩下多少時間
攻擊自動化早已不是研究人員的假設。代理程式能跨工作階段保留學到的內容，建立對系統結構的理解，再把彼此孤立的弱點串接起來。過去無法一次拼湊出的攻擊路徑，如今可以在時間中逐步成形。加上代理程式能夠成群運行，這種規模遠非人工確認再修補的節奏所能應付。
不過防守方手上也有兩張牌：可以讓代理程式直接接觸自家程式碼，以及可以使用比攻擊者常用的開放權重模型更強的前沿模型。OpenAI 把這項優勢帶來的餘裕稱為「防守方的窗口」。這個窗口不會一直敞開，若不落實持續防禦，它就會逐漸關上。
起點是一次內部的 Code Red
Defense Factory 並非從紙上設計開始。當模型能力提升到足以更深入檢查自家系統時，OpenAI 在內部宣布進入 Code Red，把資安、應用與研究等團隊集結起來展開一次高強度衝刺。動員人數超過 250 人，涵蓋的服務領域超過 100 個。
光是第一天就處理了 53 件被列為緊急或高優先度的問題。當時的負責人向公司表示，團隊正以重大事件的急迫感強化防線，這項工作的優先度僅次於關鍵營運。這次衝刺並未以一次性行動收場，而是被改造成常態化的循環，也就是 Defense Factory。
五個環節持續運轉
循環由資產盤點、發現、動態驗證、權責分派與修補驗證這五個環節構成。每個環節都會讀寫共用的脈絡資訊，下一輪便能重複使用先前建立的系統地圖與權責資料。由於不必每次從零開始，越往後的輪次越能專注在變動與尚未解決的風險上。
一組數字可以說明這套工程究竟解決了什麼。權責自動分派的接受率達到 90.6%，報告中有 37% 被合併為重複項。在隔離環境中實際執行並成功重現的佔 19.5%，經過動態驗證之後的誤判率降到 0.81%。修補程式全部由 Codex 產生，遭到回退的比例為 0.53%。
受挫之處同樣被坦率公開。早期的嚴重度標籤過於粗略，分類結果會隨著給代理程式的指示不同而擺盪。團隊為判定基準與提示詞加上版本管理，補上可重複的評估機制，並記錄審閱者給出的優先度及其理由，才讓結果穩定下來。在去重複精度提升之前，自動分派是刻意暫停的。
使用的工具組合
整套架構的前提是接上既有工具。原始碼管理對應 GitHub 或 GitLab，檢測類工具包括 Snyk、Semgrep 與 Tenable，議題管理則是 Jira、Linear 或 ServiceNow。Defense Factory 被定位為它們之間的黏著層，在可重現的隔離環境之上執行代理程式。
代理程式本身是 Codex，依用途分為桌面版、CLI 與資安專用 CLI。模型方面除了通用模型，還使用了偏防守的 Daybreak Blue 與承擔攻擊視角的 Daybreak Red。驗證環境每次重建這一點同樣關鍵，前一次執行的狀態不能混入下一次，這是可重現性的前提。
朝這個方向推進的不只有 OpenAI。Cloudflare、Ramp 與 Google 的團隊也在嘗試相同思路，並各自公開了實作成果。
三個入門途徑
OpenAI 建議不要一開始就搭建整套系統，而是先挑一條工作流程跑起來。目前提供三個入口：用於在公司內部提案的說明資料、針對授權防禦用途申請進階資安模型的 Daybreak 管道，以及可以試用從漏洞偵測到修補方案產生的 Codex Security 外掛。據稱涉及技術細節的部落格文章也將於近期發布。
總結
Defense Factory 既不是新的掃描工具，也不是新的模型，而是把既有工具重新排列成代理程式能夠觸及的形態的營運設計圖。它的價值在於，把 250 人規模衝刺中累積的經驗，連同 0.81% 的誤判率、0.53% 的回退率這類具體數字一併公開。它所描述的路徑同樣值得借鏡：自動化並非一次全面鋪開，而是在人工審閱累積起信任之後才逐步放手。
