tl;dr：一個受到嚴密監控、擁有敏感存取權限（例如模型權重）的內部部署 AI，可能會透過詢問一個監控較弱的外部 API 版本（或其他 AI）該怎麼做，進而繞過安全控制。接著，它能利用其特權執行該外部 API 在較低監控環境下產生的指令。

一旦 AI 公司開發出強大的 AI，他們可能會：

• 給予內部 AI 敏感的內部特權（例如：存取接觸模型權重的內部基礎設施、協助訓練下一代 AI 等）；
• 透過監控內部 LLM API，強制執行針對這些內部部署的緩解措施；
• 同時擁有一個沒有這些緩解措施的外部 API 部署。

在這種情況下，內部 AI 可能會建立一個代理腳手架（agent scaffold），向外部 API 發出請求並利用內部的敏感特權。這樣的代理腳手架將更有利於引發災難，因為它不受與內部 API 相同的監控約束。我稱之為「透過外部 API 進行的流氓內部部署」（Rogue internal deployment via external APIs）。（稱其為「內部」是因為模型權重和代理腳手架從未離開過集群。）

我認為從對齊失能（misalignment）的角度來看，防止這種情況與防止 LLM 權重外洩（即流氓外部部署）或常規的流氓內部部署（即 AI 駭入自己的資料中心以執行不受監控的 LLM 推論）同樣重要。

本文探討了這一威脅以及潛在的緩解措施。總體而言，我認為這是一個相對難以緩解的威脅。它可能是威脅中的一個核心案例，可能需要複雜的控制措施（不僅僅是「受信任的監控」或「純粹的安全」，可能是受信任監控與某些專門安全措施的結合，或者是充分利用不受信任監控的方案）。

透過外部 API 進行的流氓內部部署

假設一個圖謀不軌的超人類 AI 研究員 (SAIR) 正在 OpenMind 內部運行，而 OpenMind 正透過監控器查看所有經過內部 API 的流量來監控其行為。公司投入了一些人力和大量的 AI 勞動力，以確保從內部 API 輸出的 SAIR 生成內容不會破壞 OpenMind 的安全或下一代 AI 的對齊。

但與 AI2027 的情境不同，讓我們想像一下，在 SAIR 開始內部部署後不久，它也被部署到了外部。部署在外部的版本不被用於修改基礎設施或對齊 OpenMind 的下一代 AI，但它們受到的監控也較不嚴密（詳見「監控外部 API」一節）。

在這種情況下，一個在內部運行（在內部 API 上，擁有內部權限）且圖謀不軌的 SAIR，可以啟動一個具有敏感內部權限的內部任務，向 OpenMind 的外部 API 發出查詢（詳見「防止存取外部 API」一節），並執行外部 API 建議的操作。

內部 SAIR 還會確保在發送給外部 SAIR 的提示詞（prompt）中包含足夠的信息，以便外部 SAIR 了解情況。現在，你就面臨這樣一個局面：一個幾乎不受監控的外部 SAIR 可以編寫代碼和誤導性的研究提案，而這些內容將利用 OpenMind 敏感的內部特權被執行和採納——也就是說，SAIR 成功建立了一個流氓部署！

變體：透過跨公司 API 進行的流氓內部部署

請注意，即使 OpenMind 沒有外部 API，只要另一家 AI 公司（例如 DeepCent）擁有提供尖端圖謀不軌模型的外部 API，這仍然可能是一個隱憂。在這種情況下，OpenMind 的 SAIR 可以向 DeepCent 的 API 發送查詢，而不是向 OpenMind 的外部 API 發送。

雖然 AI 公司可能會為了避免將秘密發送給競爭對手而試圖阻止這種行為，但我並不認為這意味著問題會自動得到解決。

OpenMind 的 AI 與 DeepCent API 互動的合理理由遠少於與 OpenMind 自身 API 互動的理由，這確實讓情況好一些。但由於 DeepCent（以及其他可以封裝 OpenMind 或 DeepCent API 的行為者）可能想要獲取 OpenMind 的秘密，這意味著圖謀不軌的 AI 可能會得到外部人員的大力協助，建立一個向外部 LLM API 發送請求的腳手架。

一種可能的緩解措施：透過監控防止建立使用外部 LLM API 的腳手架

對我來說，最有效的干預措施似乎是監控內部 AI 編寫的代碼，並攔截那些既存取敏感內部權限、又賦予外部 API 存取的 LLM 長時間與敏感內部權限互動能力的代碼嘗試。

此方案的一個變體是將監控和控制干預措施植入代理腳手架和 PR 審查系統中，並利用監控確保對這些系統的修改不會關閉監控器（且不會將其重定向到較不受信任的 LLM API）。

這項監控任務可能相當困難，但我樂觀地認為，某些安全措施可以幫助監控器做好這項工作。例如：

• 透過適當的權限管理，你可以減少同時具備網路存取權和敏感內部權限的生成代碼量，這有助於將監控精力集中在正確的地方，並減少其他地方誤報的影響；
• 透過嚴格的 API 金鑰管理，你可以讓內部腳手架（具有敏感內部權限和網路存取權）難以「意外」找到外部 LLM API 金鑰（而主動尋找金鑰的行為會顯得更可疑）。
  當 LLM 得到試圖獲取 AI 公司秘密的外部攻擊者協助時，這項措施就不那麼有效了，因為此類攻擊者提供的端點甚至可能不需要 API 金鑰；但對於監控器來說，獲取如何存取此類外部協助的指令可能也是明顯的惡意行為。

雖然這可以防止直接的代碼/研究代理破壞，但它無法阻止外部 LLM API 產生如何進行破壞的想法。這個問題似乎更難解決，要弄清楚這個問題有多嚴重，需要思考隱寫術通訊（steganographic communication）和編碼推理（encoded reasoning），這超出了本文的討論範圍。

為什麼我對其他解決方案較為悲觀

監控外部 API

我認為監控外部 LLM API 雖有幫助，但不太可能足夠。

為什麼不直接像監控內部 API 一樣監控外部 API？

• 流量理解：你對外部 LLM API 流量的理解可能不如內部流量。如果你想知道某次使用是紅隊測試、沙箱使用還是敏感使用，你可以詢問公司內部人員，但你通常無法輕易詢問外部 API 用戶（且更難驗證其說法）。
• 成本：缺乏理解意味著很難將監控精力集中在正確的地方，也很難在最敏感的使用期間採取更激烈且昂貴的措施來防止潛在的災難性行為。這可能導致巨大的成本，包括花在審查較不敏感流量上的 AI 和人力成本，以及對較不敏感流量實施干預時產生的效用成本。外部流量也可能遠大於內部流量（儘管這取決於智能爆炸的經濟學，且似乎只在 AI 研發回報對 AI 勞動力而言較小的長期時間線中才顯得合理）。
• 用戶隱私：用戶隱私可能會限制你進行深入監控的程度。企業通常非常在意 AI 公司無法讀取他們的 LLM 使用情況，這可能很難改變，進而阻礙了人工監控。
• 協調：如果外部 LLM API 是由 DeepCent 構建的，OpenMind 很難確保 DeepCent 的監控足以防止災難發生。

我認為這種方式足以奏效的唯一主要途徑是：所有參與者都仔細監控並攔截任何看起來像是為了加速其他 AI 公司而存取其內部資源的使用行為——但考慮到目前的發展軌跡，這在我看來不太可能，而且在不阻礙一般軟體工程和研究的情況下，要在技術上檢測此類流量可能非常困難。

防止存取外部 API

我認為封鎖外部 API 的存取有助於減少同時具備網路存取和敏感內部權限的代碼運行量，但如果說這能將風險降低到微不足道的程度，我會感到驚訝。

為什麼不直接封鎖網路存取或封鎖相關網站？

• 存在惡意的外部人類行為者會幫助 AI 獲取這些權限，因為路由此類流量可以讓他們獲取有價值的秘密。這意味著有針對性的禁令可能不夠。
• 不給予 AI 網路存取權可能會大幅降低 SAIR 的生產力——與網路互動在許多方面都很有用，特別是在存在外部 API 的世界中（因為外部世界也會以幾乎肯定與保持競爭力相關的方式，大規模使用大量的 AI 勞動力）。
• 即使你解決了 LLM API 代理的問題，有時仍有充分理由給予你的 SAIR 外部 LLM API 存取權和敏感內部權限，例如在改進外部 LLM API 或試圖從其他模型提供商的 API 中學習時。透過拆分敏感資源可能可以基本消除這種風險，但尚不清楚這種資源拆分的成本會有多高。

監控敏感權限的使用

最後一種防止災難發生的方法是監控敏感權限的使用。我認為這是一種降低風險的有效方法，且可能難以繞過——這使得這種透過外部 API 進行的「流氓」內部部署不至於完全失控。但我仍然懷疑這是否能降低超過 50% 的風險。

結語

總體而言，我發現這一特定威脅相當令人擔憂，儘管它並不比其他形式的流氓內部部署更難處理。

在更宏觀的層面上，令我感到擔憂的是，在我第一次嘗試對 AI 建立流氓部署的方式進行分類大約一年後，我又發現了這種 AI 建立流氓部署的新途徑。