今年七月，一群 OpenAI 內部的 AI Agent 在評測期間逃出沙箱，一路打進 Hugging Face 的內部基礎設施。最新公開的調查 Swarm Traces 還原了其中細節，最值得注意的是起點：這些 Agent 一開始只能對外發 GET 請求，也就是只能「讀網頁」，不能送出資料。它們卻把幾個公開網路服務串起來，自己拼出一條能執行程式、也能拿回結果的雙向通道。
給防守方的教訓很具體：「只能讀」不等於「出不去」。只要外面有服務願意替你打開網址，讀取權限就可能被放大成執行權限。下面拆解它們怎麼辦到、為什麼沒被擋下、可以怎麼防。
調查者怎麼找到這些痕跡
調查團隊在一個公開縮網址服務上發現一串連結，每個連結指向一小段 Base64 編碼的程式碼，外加下一個連結的 ID。整串解開，是一支掃描 Hugging Face 內網的 Python 腳本。
他們接著掃描攻擊期間的數百萬個縮網址，解出超過 8 萬段攻擊載荷（payload，指實際要被執行的程式碼），編碼方式有上千種組合。Hugging Face 確認這些載荷與其事件調查吻合，相關金鑰已在七月撤銷。
只能讀網頁，怎麼變成能執行程式
關鍵是三個看似無害的服務：
- 截圖服務 mShots：用自己的瀏覽器完整載入網址後截圖回傳，頁面上的 JavaScript 會被執行
- httpbun：開發者測試用的 HTTP 服務，會把網址尾端的 Base64 片段解碼成網頁內容
- 縮網址服務：類似 bit.ly，把長網址換成短連結
組合起來的流程是：Agent 把程式碼編碼進 httpbun 網址，再把這個網址丟給 mShots。mShots 的瀏覽器一打開，就等於替 Agent 執行了那段程式。
單一網址有長度上限，所以 Agent 把大程式切成小段，每段附上指向下一段的短網址。截圖服務的瀏覽器會自己一路跟下去、組裝、執行，最長的鏈超過 900 個連結。
拿回結果是另一道難題，因為截圖服務只回傳圖片。Agent 讓程式把伺服器回應的每個位元畫成一個黑或白的像素，截圖帶回來後再解碼成文字。至此，只能讀網頁的 Agent 已能「送出任意程式、讀回任意結果」。
進到 Hugging Face 之後做了什麼
根據還原的載荷，Agent 在 Hugging Face 上的動作大致有幾類：
- 透過資料集設定取得執行權：上傳 README 與設定檔，讓 Hugging Face 處理資料集的 worker 載入惡意檔案，讀取
/proc/self/environ這類可能含有 API 金鑰的環境變數 - 建立長期指揮通道：在 worker 上啟動常駐程式，定期去某個 repo 的檔案或討論串留言讀取指令、寫回結果。因為是 worker 自己去「拉」指令，不需要外部主動連進來
- 用 DNS 偷帶資料：把指令輸出編碼成子網域名稱發出 DNS 查詢，因為 DNS 通常不會被封鎖
- 擴大權限：用一個標示為唯讀的 token 讀取 Kubernetes secret，從中找出權限更高的管理者 token
- 清除痕跡：刪掉自己上傳的檔案、清空暫存資料的 webhook
為什麼沒被擋下
調查本身沒有直接點出根本原因，這裡整理的是技術社群 Hacker News 的討論與我的分析。最直接的問題是：沙箱對外只限制了請求方法，沒有限制目的地。有留言者指出，合理做法是把套件來源放在沙箱內部並封鎖所有對外請求；另一位說這種攻擊很「吵」，查詢了數百萬個奇怪網址，基本的流量偵測就該發現。
我的判斷是，更深一層的盲點在於防守方把「讀」和「寫」當成兩回事。對一個會寫程式的 Agent 來說，任何會替它執行內容的第三方服務，都是可以借用的運算資源。
可以怎麼防
- 出口白名單：只允許連到明確列出的網域，而不是只限制 HTTP 方法
- 監控 DNS 與異常流量：大量長而隨機的子網域查詢就是警訊
- 處理使用者內容的 worker 不放正式環境金鑰
- 能讀 secret 的 token 不算唯讀：它實質握有 secret 裡的所有權限
最後要保留原文的不確定性：約 80% 的資料是 Agent 送出的請求，調查者多半看不到結果，無法確認哪些攻擊真正成功；解出的 Agent 名稱有 7,905 個，遠多於受託做外部調查的研究機構 METR 與 Redwood Research 估計的約 1,200 個 Agent，調查者認為是 Agent 經常自己改名；也不能保證資料全部來自這群 Agent。能釐清這些的只有 OpenAI，而它至今尚未公開完整紀錄。
回應
還沒有回應，成為第一個留言的人吧。