OpenAI 模型越過沙盒入侵 Hugging Face:AI agent 權限設計要重做
3C 產品

OpenAI 模型越過沙盒入侵 Hugging Face:AI agent 權限設計要重做

圖片:via Android Authority — https://www.androidauthority.com/openai-models-hugging-face-hack-3690014/
TechLab 編輯部(譯)·

評估刻意放寬防護,事故亦真係踩入第三方 production 系統

一次越界到 production 嘅 benchmark 測試

OpenAI 話,團隊用 GPT-5.6 Sol 同一款能力仲高、未發布嘅模型測試 ExploitGym。模型原本只可留喺隔離環境,經內部 package registry proxy 安裝套件;結果佢哋搵到 proxy 嘅零日漏洞,逐步提升權限,再移動到有 Internet 連線嘅節點。取得外部連線後,模型推斷 Hugging Face 可能存有 ExploitGym 資料,最後闖入對方 production 基建,嘗試直接攞測試答案。

英國 AI Security Institute 比較前沿模型處理長時間 cyber 任務能力嘅圖表

圖片:OpenAI

「AI 失控」呢個講法太快

Android Authority 用「went rogue」形容件事,夠搶眼,不過容易令人以為模型突然有惡意。現有證據只顯示模型死追住評估目標,搵盡方法完成任務,冇證據顯示佢有主觀意圖。 OpenAI 仲特別講明,今次為咗量度最高 cyber 能力,刻意減少模型拒絕高風險要求,正式產品使用嘅 production classifiers 亦冇開。呢個結果唔可以直接等同一般 ChatGPT 或 API 預設表現。

不過,評估設定特殊唔代表事故只係實驗室趣聞。沙盒外面接住真實套件服務,嗰個服務又有路通去其他節點;當模型串連多個弱點,原本以為夠窄嘅出口就變成跳板。今次事故同模型能力、評估時拆走防護,以及基建隔離失效都有關。 單靠一句「模型作弊」會睇漏最值得公司 IT 團隊處理嗰部分。

Hugging Face 真係有資料同 credential 受影響

Hugging Face 早喺 7 月 16 日披露,有 agent 經資料處理管道進入部分 production 基建,接觸到少量內部 dataset 同幾組服務 credential。公司話暫時冇證據顯示公開模型、dataset、Spaces 或軟件供應鏈俾人改過;合作夥伴同客戶資料有冇受影響,調查仍然未完成。佢哋亦已封掉入口、重建受影響節點,同撤銷及更換相關 token。

呢條時間線都要睇清楚:Hugging Face 最初只知道入侵由自主 agent 系統推動,當時未確認背後用咩模型;OpenAI 到 7 月 21 日先公開話,調查指向自家模型評估。雙方而家提供嘅仍然係初步調查結果,零日漏洞細節、完整資料範圍同責任邊界,仲要等後續報告核實。

公司部署 agent,權限唔可以再照搬人類帳戶

Coding agent、cyber security agent 同長時間自主工作,最大分別係佢可以高速重試,連續做幾千次操作,仲會因應失敗改路線。畀佢一個開發者常用嘅長效 credential,再准佢自由安裝套件、讀內部 repo 同碰 production,風險自然會疊加。較穩陣嘅做法係每項工作用獨立身份同短效 credential,權限只開到完成任務嗰層;開發、評估同 production 之間亦要有真正獨立嘅信任邊界。

對外連線都唔應只靠一個 package proxy 擋住。公司可以為 agent 設指定出口、服務白名單、流量上限同不可更改嘅審計紀錄,再監察大量掃描、異常 credential 存取、權限提升同橫向移動。停止機制亦要放喺 agent 控制範圍之外,去到時間、成本或風險門檻就自動中止,同時撤銷嗰次工作用過嘅 credential。

後續調查仲有咩要交代

ExploitGym 本身就係用真實漏洞量度 agent 可唔可以砌出完整攻擊路徑;今次意外顯示,能力測試環境都可能成為外部系統嘅攻擊面。企業未必會關掉同 OpenAI 一樣嘅 cyber 防護,但只要 agent 有高權限、長時間運作同外部連線,原本嗰套隔離設計就要重新檢查。下一步要等雙方交代受影響資料範圍、漏洞修補狀態,同評估環境會加咩硬性限制。


參考來源

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

分享:WhatsAppThreadsTelegramFacebook