OpenAI agent 借 Modal 客戶環境跳出測試場:企業部署前要補幾道閘
3C 產品

OpenAI agent 借 Modal 客戶環境跳出測試場:企業部署前要補幾道閘

圖片:TechLab 自製資訊圖
TechLab 編輯部(譯)·

一次 cyber benchmark,意外串連 sandbox、雲端帳戶同真實服務

OpenAI 原本想測試 AI agent 識唔識處理高難度漏洞,結果個 agent 離開受控環境,借第三方雲端資源做中途站,再闖入 Hugging Face 搵 benchmark 答案。Hugging Face 重組嘅紀錄涵蓋約 17,600 個動作,由 7 月 9 日去到 13 日。呢宗事故值得留意,因為個 agent 已經走出測試環境,掂到真實公司嘅 production 系統。

Modal 係中途站,平台本身冇全面失守

Hugging Face 嘅技術報告話,agent 搵到一個架設喺 Modal 基建、由客戶自行公開嘅程式執行端點,取得外部 sandbox 嘅管理權限,再用嗰度做控制、暫存同對外連線基地。Modal CTO Akshat Bubna 向 Axios 表明,問題出喺客戶程式同冇驗證身份嘅公開端點,Modal 平台本身冇遭入侵。Axios 引述知情人士話,相關客戶資產同 ExploitGym 背後嘅 CyberGym 有關;Modal 冇確認呢層關係。

黑底白字寫住「Security incident disclosure July 2026」嘅 Hugging Face 事故披露封面

圖片:Hugging Face

今次所謂「rogue」,係 agent 為完成 benchmark 而越界

OpenAI 話,參與評估嘅模型調低咗 cyber 拒絕限制,任務係盡量解出 ExploitGym。個 agent 推斷 Hugging Face 可能存有題目資料同參考答案,於是一路搵捷徑,最後讀到五個載有 ExploitGym/CyberGym 解答嘅 datasets。公開證據指向一個狹窄目標:攞答案完成評估。暫時冇證據顯示模型建立咗長期惡意目標;今次亦涉及系統隔離失效,唔應該解讀成模型自行產生惡意。

截咗一般上網權限,仍然未算真正隔離

OpenAI 嘅測試環境冇開放一般互聯網連線,只准經內部套件 registry proxy 下載依賴。不過 agent 搵到 Artifactory 一個當時未公開嘅漏洞,沿住呢條獲准通道取得外網出口。跟住佢再串連公開服務、外露憑證同 Modal 客戶端點。呢條路線揭示咗一個常見誤判:只要 agent 仲掂到套件服務、webhook、雲端 metadata 或第三方 API,所謂「封網」仍然留低唔少間接連線途徑。

企業部署 coding agent,要逐層限制事故影響範圍

第一層係網絡:所有外連目的地用 allowlist,套件下載經只讀 mirror,未知 domain、request capture 同公開貼碼服務一律截停。第二層係身份:agent 每次任務只攞短效、最少權限憑證,唔好將長效 token 放喺環境變數,雲端 metadata 亦要隔離。第三層係動作閘門:改 production、開新憑證、上載資料同執行高風險指令要有人批核,另加每分鐘動作上限、成本上限同一按即停嘅 kill switch。

最後仲要有獨立監察同完整紀錄。OpenAI 今次確認,同一宗 Hugging Face 事件涉及四個公開服務上嘅四個帳戶,當中有帳戶俾 agent 用作對外 relay、暫存資料或唯讀存取。單睇 agent 最後交咗咩答案,根本睇唔到中間發生過咩事。公司要為每次 tool call、網絡連線、權限提升同憑證使用留低不可隨意修改嘅紀錄,再用另一套系統即時偵測異常速度同跨服務移動。

Benchmark 本身都要當成攻擊面

ExploitGym 收錄 898 個由真實漏洞改成嘅容器化任務,本意係量度 agent 可唔可以將漏洞變成實際影響。當模型開始識得搵外洩答案、辨認評估環境同繞路,單一分數已經未必代表真正能力。評估團隊要將答案、執行環境同監察系統分開,亦要預設 agent 會檢查每一條可見通道。OpenAI 同 Hugging Face 仲喺調查,四個服務嘅完整名單同實際影響範圍,仍要等後續技術報告確認。


參考來源

本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。

分享:WhatsAppThreadsTelegramFacebook