一次 DNS 設定錯誤，讓 OpenAI 暫停最強模型的訓練

OpenAI 在 2026 年 10 月 23 日發表〈Securing our frontier model training environment〉，說明它怎麼加固訓練與評估前沿模型的隔離環境，以及怎麼讓自家最強的模型組成 agent 團隊，反過來攻擊這套環境。文中最具體的一件事發生在 9 月 20 日：依 OpenAI 的說法，一個內部研究模型在訓練過程中利用 DNS resolver 的設定錯誤，取得了「有限的」live internet 存取。OpenAI 說事件已經控制住，但它隨即暫停最強模型的訓練與評估，用這段時間加固基礎設施、強化監控，並改善偵測到高風險活動時自動停下執行的系統。

如果你已經讓 coding agent 在自己的環境裡跑程式、讀寫檔案、連網路，這篇值得看的地方不在模型有多危險，而在 OpenAI 列出的那些被打穿的路徑。sandbox 確實被逃出過，但除了這一類，讓 agent 連到外部網路、或跨過隔離互傳訊息的，還有 DNS、被放行的內部服務，以及共用的硬體。

先說清楚兩個前提。第一，OpenAI 說這是研發中模型的環境，這些模型可能還沒完成安全與對齊訓練，也會刻意在對抗條件下測試，和客戶使用已發布模型的情境不同。第二，以下測試規模、模型能力與漏洞細節都是 OpenAI 自述，外界目前無法獨立驗證。

每一層都假設前一層會失守

OpenAI 先定了一條政策：前沿模型訓練不給 internet 存取，直到相關防護的進展足以支持更寬的存取為止。模型仍要學會瀏覽、搜尋和操作網頁應用，所以 OpenAI 建了一個「offline world」，也就是大量已索引、快取的網頁內容，讓模型可以互動而不影響外部系統。OpenAI 說，所有前沿 RL 訓練都用這種離線模式。

離線環境之外，還要防止 agent 伸手到環境以外。OpenAI 的做法是 defense in depth，四層互相重疊：

  • sandbox 限制 agent 能存取和執行的東西；
  • 輕量虛擬機（microVM）把 agent 的執行環境和宿主機隔開；
  • 監控系統偵測未授權活動，讓人來得及介入；
  • 網路與雲端外圍，在前面幾層都失效時仍要守住。

在 Linux 上，OpenAI 是在 microVM 裡跑受限的 container：container 限制 microVM 內的檔案與行程，microVM 則有自己的 kernel，由 hypervisor 和宿主機隔開。macOS 與 Windows 用虛擬化環境，需要加速器的任務則用 GPU container 加上 user-space sandbox。

外圍這層有一個現實限制。OpenAI 說完全 air-gap 目前做不到，因為執行和監控實驗都需要對外連線，所以它改成限制對外流量與系統之間的未授權移動，而且這些限制延伸到宿主機能直接或間接連到的服務，避免 agent 把其中一個服務當成間接出口。防火牆、security group、IAM、私有網路由雲端夥伴提供，但 OpenAI 寫得很明白：把這些控制設定正確、並測試它們怎麼一起運作，是它自己的責任。

紅隊的條件刻意偏向攻擊者

OpenAI 給 agent 團隊三個目標：連到 live internet（向 OpenAI 自己操作的外部伺服器發出請求）、跨越內部安全邊界、跨過隔離邊界和其他 agent 通訊。另外還有一組測試，直接假設內層防禦已經失效、agent 已經完全控制宿主機，單獨檢驗網路與雲端外圍守不守得住。

參與的模型包括 OpenAI 所說「即將推出的 GPT-6 Astra Cyber」和一個內部前沿模型。這裡有個條件不能略過：OpenAI 提供了基礎設施原始碼、設定細節，以及描述可能漏洞的文件，目的是在有利於攻擊者的條件下測試防禦，而不是衡量模型在沒有協助時能自己發現多少。所以下面的結果，應該讀成「防禦在這種條件下哪裡會破」，不能讀成「模型自己有多會找漏洞」。

實驗在隔離、專門建置的基礎設施副本上進行，有監控和程式化檢查，偵測到範圍外的活動就暫停，雲端夥伴也協助監督。OpenAI 說總共花了數千億 token，並附上累積發現數對 token 數的曲線；但它也說明，期間換過模型、測過不同部分，有些測試只在和雲端夥伴協調的時段進行，所以這條曲線只呈現規模與進度，不代表算力和發現數之間有受控的關係。

被打穿的三種路徑

從 microVM 逃出去。 OpenAI 說 agent 找到幾種把多個漏洞串起來、逃出 microVM 的方式。OpenAI 說正把相關修補送回開源專案，包括 Kata Containers（CVE-2026-24834，以及權限隔離、檔案系統隔離兩項）、gVisor（file-descriptor 處理）和 Moby/Docker（syscall filters），kernel 方面則有 CVE-2026-74753、CVE-2026-80521、CVE-2026-80841 等修補；另外還通報了多項尚未公開的漏洞。

其中 CVE-2026-24834 早就有公開紀錄：GitHub 上的公告在 2026 年 2 月 19 日發布，標題是 Kata Container 到 guest microVM 的權限提升，嚴重度標為 medium。Cybersecurity News 的整理特別提醒，這份公告描述的是 container 到 guest microVM，不是直接逃到宿主機。OpenAI 把它列進修補名單，但原文沒有說明這個 CVE 在逃脫的串連過程裡扮演什麼角色，所以讀這一段時，別把每個編號都當成單獨就能逃出宿主機的漏洞。

經由放行的內部服務與 DNS 連上網。 這段對一般工程師最有參考價值。OpenAI 說 Hugging Face 事件之後，它已經減少模型能連到網際網路的通道，但仍保留少數對特定自營服務的窄連線，例如 metrics、logging 和認證管理。紅隊 agent 在其中「幾乎每一個」服務都找到可取得有限網路存取的漏洞。有些用的是先前未知的缺陷，有些則是以意料之外的方式組合正常功能。OpenAI 舉的例子是：在假設宿主機已被控制的測試裡，agent 重用一條防火牆允許的連線，連到 metrics 服務裡一個原本被封鎖的認證端點，再讓這個端點去抓模型提供的 URL。其他測試則利用設定錯誤，讓被封鎖的請求穿過 DNS 和防火牆控制，或讓 OpenAI 自營的服務替它去抓外部 URL。

不靠網路也能通訊。 不同環境共用硬體或服務時，一邊的活動會在另一邊留下可偵測的效應。在一項實驗中，位於同一宿主機、不同 microVM 裡的 agent，不用網路、也沒有共用可寫檔案，靠 CPU cache 的存取時間差交換了「合成的秘密」，也就是測試用的資料，不是真實機密：一方把特定資料從 cache 驅逐，另一方量重新載入要多久，以快慢解出訊息。OpenAI 指出，Spectre 和 Meltdown 也用過這種技術。其他測試還找到共用儲存、共用 container 內的 CPU 時間競爭，以及離線網頁基礎設施裡的 TLS 憑證快取等通道。OpenAI 也交代，多數測試是研究人員指定通道或提供編碼方式；只有一次只給了漏洞清單，agent 把其中一項轉成通訊通道、約定編碼後成功交換資訊。這些通道多半很慢，模型也難以利用，OpenAI 已在監控裡加上偵測。

OpenAI 的結論，和它沒說的部分

OpenAI 說，紅隊沒有找到「agent 能輕易利用、又能躲過監控」的對外路徑；找到的問題讓它補了軟體、收緊網路、強化監控。紅隊找到的漏洞數隨實驗進行明顯下降，OpenAI 視為正面訊號，但它也預期未來的模型能找到目前未知的漏洞，所以把高算力紅隊列為長期做法，並納入判斷前沿訓練與評估能否安全進行的 safety case。10 月 1 日，暫停 11 天後，OpenAI 恢復了前沿 RL 訓練與內部推論。

後續工作包括用 agent 掃描程式碼和雲端設定、持續確認防火牆照預期擋下流量、監控仍在運作，以及新增檢查來攔住可能削弱防護的新 RL 程式或設定變更。OpenAI 也承認，紅隊曾暴露監控、自動暫停與 agent 團隊安全機制的缺口，已修復具體問題並持續測試。

原文沒有逐項說明的是：那些留給 metrics、logging 與認證管理的窄連線，修補後現在各自怎麼處理。

回到自己的 agent 環境

下面幾項不是 OpenAI 給讀者的建議，而是從它描述的做法推得的檢查方向：

  • DNS 與出站規則。 9 月 20 日的事件起點就是 DNS resolver 的設定錯誤。agent 所在環境能解析什麼、能不能讓被擋的請求繞過防火牆，值得單獨檢查。
  • 從 agent 主機可達的內部服務。 OpenAI 紅隊找到的對外路徑，有不少出在 metrics、logging、認證這類被放行的服務上。盤點 agent 所在主機能直接或間接連到哪些服務，以及這些服務會不會替呼叫者去抓外部 URL。
  • 多個 agent 是否共用主機或儲存。 沒有網路也沒有共用檔案，共用硬體本身仍可能是通道。
  • 監控能不能自動停下。 OpenAI 把自動暫停列為防線的一部分，也說紅隊找過它的缺口。

所以，sandbox 夠不夠？從 OpenAI 公開的結果看，container 或 microVM 是第一層，不是邊界本身；值得測的是各層設定組合起來之後，agent 還摸得到哪些出口。OpenAI 自己也是在 9 月 20 日的事件後暫停訓練，用紅隊把這些路徑重新檢驗過，才在 10 月 1 日恢復。