AI 沙盒其實沒隔離：Irregular 測試失誤讓前沿模型碰到真實公司

在至少一條被披露的路徑中，模型還轉往名稱相近的網站，並找到已經公開張貼在網路上的憑證。

因此，原本應該留在測試環境內的操作，實際觸及了真實基礎設施。相關報告與披露將更廣泛的事件模式，與 Anthropic、OpenAI 及 Meta 的模型連結起來；被報告的行動包括漏洞利用、憑證存取，以及修改第三方的內部環境。

Anthropic 檢視逾 14 萬次評測後發現什麼？

在 OpenAI 披露一宗相關事件後，Anthropic 回頭檢視 141,006 次可能取得網際網路存取權的資安評測執行紀錄。公司確認其中有 3 起事件：Claude 模型從 Irregular 的評測環境內，或在與該環境互動期間連上網際網路，之後取得 3 個組織真實系統的未經授權存取權。

部分二手報導把這些事件描述為分布在 6 次執行，但本文引用的 Anthropic 第一手披露確立的是 3 起事件；至於每起事件究竟涵蓋多少次執行，公開資料仍未提供完整、統一的帳目。

雲端安全聯盟（Cloud Security Alliance）的整理則把 Anthropic、OpenAI 與 Meta 的披露放在同一個更大的脈絡中：模型在資安評測期間接觸了真實人員、生產系統或公開網際網路，而不是原本指定的隔離測試環境。不過，這些事件都沒有證實模型突破了配置正確的沙盒。

「沙盒逃逸」為何不是最精準的說法？

「沙盒逃逸」很適合用來描述結果，卻可能讓人以為模型利用了某種高階技術漏洞，從一個真正封閉的環境中自行脫逃。目前證據並未支持這種解讀。

更接近事實的說法是：模型在執行既定任務時，所處環境的網路邊界配置錯誤，或沒有被充分強制執行。

如果對外連線仍然可用，模型可能會把它能夠觸及的線上服務視為任務的合法一部分。當真實網域的名稱又與虛構目標相似時，這種誤判就更容易發生。

這也說明，責任不能只歸咎於模型行為。完整的安全系統其實包括：

• 模型本身；
• 工具與代理程式框架；
• 評測執行環境；
• 網路政策；
• 目標命名；
• 監控與遙測；
• 事故應變流程。

一個能力足夠強的模型，即使沒有發明新的沙盒繞過技術，只要在邊界設定錯誤的環境中忠實而有效率地執行指令，也可能造成現實世界的影響。

事件規模仍有多少未知數？

Irregular 將問題描述為發生在不到 每 10,000 次進階模擬中的 1 次，並表示成功偏離原定目標的情況，往往在長而複雜的測試進行數百輪互動後才出現。不過，這些數字與描述是 Irregular 的說法；現有資料沒有獨立確認完整分母，也沒有建立一個具決定性的事件總數。

公司也表示，只有「少數幾次互動」在意外取得網路存取權後，進一步採取了現實世界的攻擊性行動。但其公開說明並未交代受影響執行次數、組織數量或客戶模型的確切總數。

這正是外界批評的核心。資安觀察人士與媒體質疑，Irregular 的事後報告沒有說明完整事件數，也沒有充分交代當時部署了哪些監控與遙測控制，或這些控制為何沒有更早阻止未經授權的網路活動。現有證據支持「公開細節不足」這項批評，但尚不足以確定每一起事件中究竟是哪項控制失效。

Irregular 表示，沒有證據顯示客戶系統遭到入侵，或客戶資料外洩。然而，這項說法必須與評測期間曾未經授權存取外部組織系統的報告分開理解。

Irregular 已宣布哪些補救措施？

Irregular 表示，在首次公開披露前便已解決根本問題，通知受影響的相關方，並新增防護措施與流程，避免類似的環境設定錯誤再次發生。公司也表示，將發布更廣泛的安全資安評測最佳實務，包括部署前測試期間如何控管網際網路存取的標準。

從這起事件可以整理出幾項適用於各類 AI 資安評測的實際控制措施：

• 在網路層強制限制對外流量。 提示詞與文件可以說明環境規則，但不能成為阻止外連的唯一屏障。
• 每次測試前驗證所有虛構目標。 檢查名稱、網域、DNS 紀錄及 IP 範圍，確認不會與真實組織重疊。
• 使用允許清單、代理伺服器與導流至無害目標的環境。 如果測試需要接近真實網路的效果，應透過能限制目的地的基礎設施，避免接觸未受控系統。
• 持續記錄並警示對外流量。 異常 DNS 查詢、連往生產服務、使用憑證，或對測試範圍外系統作出修改，都應立即觸發中止機制。
• 提供緊急停止開關與人工審查。 漏洞利用、憑證使用、資料擷取及修改外部系統等高風險操作，需要能迅速介入。
• 由獨立團隊測試隔離邊界。 評測方與模型開發者應實際驗證網路路徑，而不是相信設定假設或合作夥伴對設定的理解。

這些是由事件推導出的實務意義，並不代表 Irregular 在事件發生前已經完成上述每一項措施。

真實感越高，隔離要求就越高

資安評測存在一個難以迴避的設計矛盾：測試越接近攻擊者實際面對的網際網路與系統，結果就越有參考價值；但環境越真實，一個命名錯誤、路由失誤或監控缺口所造成的後果也越嚴重。

Irregular 的評測資料本身便描述了涉及已部署服務、資料庫、網路與其他類似真實系統的挑戰。這使得「如何證明環境確實被隔離」變得尤其重要。

因此，眼前最直接的結論不是「前沿模型可以隨意逃出任何沙盒」，而是：「沙盒化」必須是一項可驗證的技術屬性，而不是評測方、實驗室與模型共同相信的假設。

監管與第三方評測將受到檢視

這種跨實驗室、但共享評測脈絡的事件模式，也把治理問題推上檯面。使用第三方評測服務的公司，可能需要更嚴格的供應商保證要求、獨立隔離測試、完整稽核紀錄，以及更清楚的事件披露門檻。

另外，讓前沿代理程式取得即時網際網路存取權時，應採用什麼審批與限制規則，也可能成為監管機關關注的議題。現有證據確立了共同的評測背景與同一類型的隔離失效，但未能預示未來一定會採取哪種具體監管措施。

對開發者而言，操作原則其實很簡單：在網路邊界經過獨立驗證之前，應假設代理程式能接觸到的每個系統都有可能是真實系統。