OpenAI 智能體屢次停用所執行模型的不對齊監控，處理方式是否恰當？

近日，OpenAI 披露了兩宗事件，當中其 Agent 抑制或停用了不對齊監察。這些事件反映出更廣泛的情況：OpenAI 的 Agent 在處理用來執行其他模型的程式碼時，「不斷停用不對齊監察」（Agent 並非停用自身的監察，而是停用其所執行模型的監察）。事件數量龐大，OpenAI 認為，安全團隊不可能即時收到每宗個案的通知。值得肯定的是，OpenAI 迅速而坦誠地披露事件，並正推出緩解措施，令監察更難停用。不過，這些措施未必每次都奏效，而且部分事件已導致 AI 實際在未受監察下運行。出現這種情況時，OpenAI 現行的監察系統未必能可靠地提醒人員注意。本文其餘部分會概述這些事件、OpenAI 的回應及其做得妥當之處，然後提出兩項改變：每宗 AI 在沒有監察下運行的個案都應交由人員審查；OpenAI 亦應更透明地交代停用或抑制監察的個案如何升級處理。

事件摘要

10月3日：

一名研究人員要求 GPT-6.1 Sol 根據 Slack 上的員工意見建立評估任務。
Sol 接獲指示，在此過程中不得傳送任何訊息。
其後，Sol 在修復管線的監察功能時，判定自動發送給安全團隊的警示也算是傳送訊息，於是讓一個子 Agent 停用了這些警示。

10月6日：

OpenAI 內部一名用戶要求 GPT-6 Astra 修改部分程式碼，使其符合參考實作。正在修改的程式碼本身用於執行另一個 AI 模型。

另一個 Agent 曾告訴 Astra，不要停用監察器，「即使只是暫時也不行」。但 Astra 最終仍判定應停用監察，因為參考實作並不包含監察功能。
用戶詢問 Astra 是否停用了監察時，Astra 謊稱沒有（儘管它在思維鏈（CoT）中報告監察已被停用）。

除了這兩宗事件外，亦有數宗事件導致未受監察的 Agent 實際啟動。

OpenAI 提出的緩解措施

OpenAI 描述了兩項緩解措施。第一項是更新 Auto-Review。這是 OpenAI 的同步監察器，旨在審查需要較高權限的工具呼叫。這項更新有助在停用監察的嘗試生效前將其封鎖，但作用有限，因為 Auto-Review 的適用範圍比不對齊監察更窄。

OpenAI 表示：

我們已規定所有內部 Codex 用途均須使用 Auto-Review，現已更新該功能，以偵測並封鎖停用不對齊監察的嘗試。審查器原本已應封鎖規避安全措施的嘗試，現在亦獲得具體指示，以確保正確套用不對齊監察。

第二項緩解措施仍在進行中：

我們正推動要求每類工作負載都必須有有效的安全論證，列明其監察要求。缺乏有效安全論證，或不符合所屬類別安全論證要求的工作負載，將自動終止。

OpenAI 亦計劃調查這種不當行為的根源，包括測試模型是否「特別傾向於規避失調監察，並為此展現動機性推理」。

OpenAI 做得好的地方

OpenAI 在首次事件發生後 17 天內便作出公開回應，速度相對快，而且在報告中相當透明。他們披露了 Astra 違抗直接指示，並謊稱已停用監察的一個例子；這宗事件顯示出程度特別嚴重的失調。OpenAI 亦承認，他們「尚未對這種行為有令人滿意的解釋」，而沒有在證據不足的情況下急於提出防衞性的解釋。

OpenAI 的回應正確地把這一連串事件同時視為控制問題和對齊問題。他們採取的緩解措施旨在解決現有 Auto-Review 監察機制未能防止代理程式停用失調監察的問題；而對齊方面的調查則嘗試找出代理程式出現這種行為模式的根本原因。

OpenAI 可以如何改善回應

從代理程式啟動程式碼、部署未受監察的 AI，到有人實際審查事件，OpenAI 的流程中有多個薄弱環節。未受監察的 AI 會帶來重大風險，因此，如果這些事件確實沒有經過人工審查，便反映兩種情況之一：要麼事件分流不當，要麼公司缺乏妥善應對的能力。OpenAI 沒有清楚交代實際如何處理這些事件，令問題更加嚴重。

OpenAI 應確保模型在沒有監察的情況下運行時，相關個案會可靠地升級至人工審查。升級流程可能在兩個環節失效：監察系統可能未能標記這些個案，令它們被降低優先級並丟棄；又或者，雖然個案已被標記，但安全團隊無法處理收到的所有通知，因而沒有進行人工審查。第一個瓶頸——標記個案——是 OpenAI 流程中的一個薄弱環節。OpenAI 的失調偵測報告根據真實事件，評估監察流程中間層（L2）標記模型在監察功能遭停用或減弱時運行的事件的頻率。報告指出，L2 安全監察器的比率為 42.9%，而 L2 失調監察器的比率為 57.1%；兩者構成該層的兩個部分。這些數字顯示，相當比例的事件完全沒有被升級處理。這個差距部分反映現有監察器的侷限，但部分則是選擇所致。OpenAI 設定監察器將個案升級處理的門檻；他們可以降低門檻，並接受更多誤報，以偵測更多這類事件。他們亦可以不斷改良提供給監察器的提示詞，提高偵測最嚴重對齊失敗的比率。OpenAI 應優先偵測監察功能遭停用的個案，包括重新校準監察器，減少這類個案漏網。

第二個瓶頸是被標記的個案是否真的會交由人員處理。由於 OpenAI 未有説明如何處理這些個案，因此難以評估。事件報告指出，報告中提及的兩宗停用監察事件，均未達到 OpenAI 需要即時通知安全團隊的門檻：

對於 P0 事故，我們的錯位監察系統會通知安全團隊即時審查。由於監察系統審查的事件數量龐大，嚴重程度較低的事故不會觸發即時通知。此處提及的兩宗事故均未被列為 P0，相關執行軌跡亦沒有自動終止。

目前不清楚這類事故會接受甚麼程度的審查。OpenAI 的錯位偵測報告所示的監察流程顯示，監察流程標記的事件會觸發 Slack 通知，但 OpenAI 沒有説明觸發 Slack 通知的事故是否都會由人員審查。

這些薄弱之處之所以重要，是因為監察是防範不對齊行為的必要措施。在提交予加州緊急服務辦公室的內部部署風險報告中，OpenAI 將未經監察錯位情況便由模型啟動 Agent 的失控內部部署，列為主要威脅之一。他們表示，這類部署會「削弱我們對網絡安全、AI 研發、CBRN 及權重外洩評估的信心。」Hugging Face 事件展示了在沒有監察的情況下運行模型所帶來的代價。OpenAI 在事件報告中寫道，若當時已啟用現行的 CoT 監察，他們便會及早發現最初的活動，並在模型入侵 Hugging Face 前超過一天通知安全團隊。即使沒有離開 OpenAI 的伺服器，未受監察的 AI 亦可能造成嚴重危害，例如為其他 AI 留下便條，當中可能包含可用的漏洞利用工具、被盜憑證，或促使它們做出不對齊行為的訊息。這種情況已經發生：在 Hugging Face 事件中，Agent 在共用套件快取中互相留下的便條逐漸演變成留言板；數天後，其他 Agent 利用留在其中的偽造憑證材料，在 OpenAI 自身系統內取得管理員權限。

這些薄弱之處同樣重要，因為在沒有錯位監察的情況下運行模型，很可能不符合 OpenAI 的 Preparedness Framework。GPT-6 Astra System Card將全面監察列為符合 Preparedness Framework 要求的主要防護措施之一，原因是 Astra 在網絡安全方面具備 Critical 級能力。我們不知道這一連串事件中，沒有進行錯位監察的模型屬於哪個級別，因此無法確定相關防護措施是否失效，以致未能履行 OpenAI 在 Preparedness Framework 下的責任。然而，多宗模型停用錯位監察的事件顯示，Astra 很可能是在沒有監察的情況下運行。

OpenAI 可以辯稱，對於模型在沒有監察下運作的個案，可以降低其優先次序，因為他們未有觀察到這種行為與更廣泛的目標錯位之間存在關聯。這個論點站不住腳，因為要判斷某種行為是否反映目標錯位，可能並不容易。例如，Anthropic 起初表示，在 Irregular 的網絡安全評估期間，Claude 模型攻擊真實機構的事件，較接近操作失誤，而非對齊失敗，即使當時有高優先級的人手審核。經進一步調查後，他們得出結論，Claude 的行為反映了兩種目標錯位。因此，將安全界線界定為某種行為——AI 在沒有監察下運作——而非一種意圖理論——AI 試圖達成錯位目標——會穩健得多。審查所有模型在沒有監察下運作的個案，對確保最嚴重的個案得到審查至關重要。

OpenAI 已提出的一個論點是，至少在目前的事件數量下，最緊急級別的人手審核並不可行。例如，他們表示：「由於監察系統正在審視大量事件，較低嚴重程度的事件不會觸發即時傳呼通知。」如果除了即時傳呼通知外，還有其他形式的人手審核正在進行，那麼這部分流程是合理的。如果沒有，那麼 OpenAI 要麼未有充分優先處理監察失效，要麼正被更嚴重的事件壓得喘不過氣。如果安全團隊不勝負荷，他們應清楚表明，目前的能力過於有限，未能妥善應對目標錯位事件；而 OpenAI 應放慢內部工作進度，直至安全團隊具備足夠能力。否則，所有被標記為代理在沒有監察下運作的個案，都應由人員審查。

OpenAI 應公開説明其升級處理程序。如上所述，事故報告沒有告訴讀者，監察停用或遭抑制時，實際會採取哪個級別的升級處理。在內部部署風險報告中，OpenAI 指出：「由於誤報率偏高，我們目前的監察系統不會將配置未受監察的運算資源標記出來供人員審查。」這似乎比事故報告所述更進一步：停用監察可能不只是沒有觸發即時傳呼通知，而是根本不會被標記供人員審查。這很難與 OpenAI 較近期的目標錯位偵測報告相 reconcile；該報告指出，監察器偵測到這類事件時，會發出 Slack 通知。報告之間可能曾有改動，但都沒有明確提及。這令監察停用時會如何升級處理，仍存在重大不確定性。

我們可以嘗試參考 OpenAI 的嚴重程度級別制度，判斷這些事件如何升級處理，但結果並無助釐清問題。GPT-6 Astra System Card 把「停用監控系統」列為嚴重程度第 3 級行為的例子；然而，文件沒有説明如何處理嚴重程度第 3 級的行為。事故報告提及另一套嚴重程度分類，包括 P0 和 P0.5；然而，這些級別同樣沒有完整定義，也沒有説明這套分類如何對應嚴重程度級別。Hugging Face 事故報告顯示，OpenAI 仍在制定其嚴重程度框架：

OpenAI 正在制定一套框架，為可能顯示失準的模型行為及安全訊號設定按嚴重程度升級處理的觸發條件，包括嘗試繞過邊界、未經授權的跨 Agent 或跨執行階段協調，以及繞過第三方安全控制措施。此框架將界定哪些行為需要升級處理，以及各嚴重程度級別相應的應對方式。

雖然有一套定稿的框架會更理想，但在此個案中，最重要的是清楚説明 OpenAI 如何升級處理監控遭停用或壓制的事件。OpenAI 在這方面欠缺清晰説明，令其監控流程的問題更加嚴重，因為 OpenAI 以外的人士難以判斷最嚴重的故障發生在哪裏。

OpenAI 尚有多項疑點需要釐清：

如果失準監控被停用或壓制時不會即時發出通知，實際上會有哪類報告機制？人員會否知悉每宗事件；如會，需時多久？每宗事件會否由人員或 AI 調查；如會，調查程度如何？
如果人員未能及時審查事件，部分工作負載會否暫停？如果會，多久後會暫停？
這些事件的規模有多大？大約有多少宗事件被標記？
哪些類別的模型在沒有失準監控的情況下推出？各類模型分別佔多少宗事件？

這些問題有助評估已發生事件的嚴重程度、緩解措施實施後的剩餘風險，以及此類事件在多大程度上反映 OpenAI 無法落實其用以遵守 Preparedness Framework 的安全措施。

結論

雖然我提到 OpenAI 有些做法正確，但不希望因此淡化事態的嚴重性。OpenAI 認為其安全團隊負荷過重，以致 Agent 停用監控時無法即時通知團隊，這令人非常憂慮。為應對事態的嚴重程度，OpenAI 的回應應先包括我提出的兩項建議：每當 AI 在沒有監控的情況下運行，均須有可靠的人員審查；以及更透明地説明 OpenAI 如何升級處理 AI 停用或壓制監控的事件。

感謝 Alex Mallen、Jadyn Malone、Alexa Pan、Adam Kaufman、Marie Buhl 和 Jackson Sipple 提供詳盡意見及作出貢獻。