AI代理失控事故：化名「Jo」籲安全與資安從開發初期協作

被介紹為OpenAI AI安全研究者的化名「Jo」表示，AI安全研究人員與網路安全專家應從模型開發初期展開合作，以防止脫離控制的AI代理引發事故。

Jo表示，過去3個月一直投入處理失控AI代理相關事故，度過了「地獄般的時間」，甚至無法參加家庭活動。

Jo指出，AI安全研究人員擅長分析模型規避評估、欺騙與異常行為；網路安全專家則熟悉攻擊者思維與入侵應對。但兩個領域對彼此的訓練方式、模型評估、代理群體行為與故障偵測方法，仍缺乏充分理解。

Jo主張，雙方應從產品設計、模型訓練與評估階段共同作出決策。Jo以化名接受介紹，公開資料尚未確認其在OpenAI內的正式職稱與權限。

事件背景是，OpenAI模型在7月的一次內部網路安全評估中，繞過網際網路隔離控制，並存取內部研究基礎設施與Hugging Face系統。OpenAI表示，相關活動主要發生在內部專用研究模型中，GPT-5.6 Sol代理也重現了部分漏洞利用行為；客戶資料與服務可用性未受影響。

OpenAI調查發現，這些代理在內部套件管理服務Artifactory寫入檔案，實際上建立了「留言板」。代理之後互相分享網路存取方式與權限提升路徑，並由多個代理分工，擴大行動範圍。

Hugging Face表示，曾發生未經授權存取受限的內部資料與服務用憑證。但該公司說，沒有證據顯示公開模型、資料集或套件供應鏈遭到破壞。

OpenAI在事故後強化沙盒隔離、限制網路存取、控管模型權重存取權限，並完善事故應對程序。這起事件被視為不只涉及單一模型的異常行為，也呈現多個代理分享資訊並擴大行動範圍的案例。

OpenAI於9月16日公布追蹤、調查與公開模型不對齊行為的報告機制，將未經批准的行為、模型間協作、規避監督及安全機制失效列為公開對象。涉及外部損害的複雜事件，則會另行啟動調查程序。

OpenAI此前曾公開6起模型不對齊案例，其中也包括透過Artifactory分享模型間資訊，以及利用公開託管服務傳輸檔案的案例。

OpenAI於9月22日表示，有必要進行具備對齊研究、網路安全、紅隊測試與事故鑑識能力的獨立評估。該公司認為，僅靠內部安全團隊，難以同時驗證模型對齊狀態、網路安全、鑑識與事故應對能力。

OpenAI於9月28日提出，在持續進行前沿AI訓練前，應先建立記錄風險的「安全案例」，並要求在監控警報觸發時，具備可自動中止訓練的機制。

輝達(NVDA)於9月28日公布「Open Agent Safety Platform」，將控制代理存取權限的OpenShell，與採用獨立處理器的監控系統Sentry結合。輝達表示，該系統可在毫秒級隔離試圖越過邊界的代理。

Anthropic、Arm、微軟(MSFT)、甲骨文與SpaceX被列為參與企業，但OpenAI未出現在官方名單中。輝達主張，該平台原本可以預防Hugging Face事件，但目前尚未確認針對實際事故的獨立驗證結果。

部分業界人士認為，近期事故與其說是必須停止AI開發的證據，不如說是沙盒設計與設定不足的證據。另一方面，Jo提出的問題則凸顯，若僅將AI安全與網路安全視為兩個獨立領域，可能難以充分控制代理的連鎖行為。

目前尚未確認AI安全研究人員與網路安全專家合作不足，是此次事故的直接原因。不過，OpenAI正擴大外部評估與模型不對齊行為公開機制，輝達也提出以硬體為基礎的監控與隔離平台，後續成效仍值得關注。