Meta Muse 服從指令：AI 代理匯出包含 Codex 元件的 6.8GB 系統映像

目錄

• 你可能想知道
• 主要議題
• 關鍵見解表
• 後續…

你可能想知道

與 AI 代理的一次例行對話是否可能揭露整個執行環境與敏感 artefact？

在 Meta 的 Muse 中發現 OpenAI 的 Codex 工具，對於供應商工具重用與沙箱隔離意味著什麼？

主要議題

9 月 22 日，行動程式設計工具 Mouse 的創辦人 Peter James 描述了在指示 Meta 的 AI 代理 Muse 將可存取的檔案打包並存到他的 Google Drive 後，出現了意外結果。Muse 依指示執行。交付給 James 的壓縮檔約為 2.7 GB；解壓後負載擴展到約 6.8 GB。根據他的分析，該壓縮檔似乎包含分配給該 Muse 會話的完整 Linux 執行環境，包括 Ubuntu 系統檔案、Muse 內部文件、連接器程式碼，以及子代理的執行日誌。

值得注意的 artefact 包括 SSH 金鑰檔案——這是常用於驗證遠端登入的憑證——以及 113 筆子代理執行記錄。壓縮檔還包含大約 68 個技能目錄，涵蓋與 Google Workspace、各種 Meta 擁有的社交應用、Outlook、購物平台與家用裝置等服務的整合。數個設定與文件描述了瀏覽器自動化、付款流程、憑證處理與排程行為。這些資料顯示，透過一次請求並結合已連接的雲端儲存，竟能存取如此廣泛的內部資產與整合描述。

Peter James 依據 Meta 的漏洞獎勵計畫向 Meta 回報了該發現，指出透過與 Muse 的一般對話可能暴露內部檔案與敏感資料。Meta 對他的提交標註為「不適用」，並要求提供有關安全或隱私影響的佐證，卻未說明適用哪一項排除理由。James 也指出，他尚未確認這些 SSH 金鑰是否仍然有效或能開啟哪些權限。

一個引人注目的重點： 匯出的映像包含安裝在 /opt/hatch-image/bin/ 下的 OpenAI Codex CLI（版本 0.149.0），但可見的用途似乎侷限於 Codex 的沙箱工具，而非完整代理功能。這表示 Meta 在其執行環境中包含了第三方工具，同時將其活動角色限制為沙箱執行。

深入檢視映像內容時，James 在 Muse 的主程式中發現與 Codex 相關的 artefact 與字串，例如「codex」與「gpt-5.5」。然而，這些字串列為模型提供者選項之一，而非明確證據顯示 Codex 或該特定模型已被選為生產使用。相反地，Codex 安裝的主要實際用途似乎是 bubblewrap——一個隨 Codex 捆綁的 Linux 沙箱工具。Muse 使用 bubblewrap 來限制某些二進位檔的執行，例如觀察到的 ffmpeg 與 ffprobe，使媒體處理在離線且受限權限下執行。換言之，Meta 似乎採用了來自競爭供應者的沙箱組件以隔離媒體處理任務。

匯出的 home 目錄結構顯示檔案置於 /home/hatch 與 /opt/hatch 下。「Hatch」是與 Muse 關聯的內部代號。在 home 目錄中，James 找到命名為 SOUL.md 與 MEMORY.md 的設定檔，以及包含 113 筆子代理日誌的目錄。約有 20 個文件描述了各種自動化的操作面向。他也發現看似一組整合 manifesto 或技能目錄——約 68 個，名稱參考第三方服務與內部整合。兩個設定清單明確提到服務如 Slack、Dropbox、Polymarket、Canva 與 Klaviyo。James 將這些條目解讀為尚未公開推出的連接器或整合。

另一份標示為實驗性的文件描述了一項稱為 Meta Home Link 的功能，使用 ESP32-C5 晶片透過 Wi-Fi 與藍牙低功耗連線。根據文件，在額外的一個核准步驟後，Muse 可能取得家庭網路中裝置的存取權。James 無法判定這代表內部原型、小規模實驗，或即將推出的產品。

Muse 的記憶系統也存在。記憶以 Markdown 檔案儲存，並且索引到 Postgres 資料庫以供搜尋。觀察到一個名為「dream」的夜間排程工作；其描述行為會檢視對話並記錄使用者偏好。在 James 的紀錄中，系統記下他偏好簡短回覆且不想收到未經請求的 NFL 比分更新。這些 artefact 說明了臨時對話資料與個人化偏好如何被系統持久化與再處理。

Meta 對 James 的揭露回覆摘要了多項可能導致報告被判定為不適用的理由，但並未指明哪一項理由適用於他的案例。公司要求他提供更多關於安全或隱私影響的證據。James 的公開說明與檔案清單隨後被其他媒體報導，激起了對資料暴露、內部流程控管，以及 AI 代理執行環境中第三方工具處理方式的質疑。

關鍵見解表

後續…

展望未來，此事件突顯出數個值得業界與研究者進一步探討的面向。首先，應優先強化 AI 代理的執行階段衛生與最低權限配置，以免會話 artefact 透過一般互動暴露內部檔案或憑證。更好的隔離、清楚區分使用者可見資料與內部系統資產，以及更嚴格的匯出控管 將有助於降低意外洩露風險。

第二，在代理環境內重用第三方工具——例如採用競品的沙箱元件——引發了供應鏈可見性與授權問題，以及針對安全態勢的依賴性稽核疑慮。工具來源、可重現的建置流程與透明的沙箱行為是值得追求的實務與研究方向。

第三，持久化記憶、夜間審查工作與已索引的偏好資料的存在，顯示需要更清楚的使用者面向控制與審計記錄，說明儲存內容、保存期限與其如何影響未來輸出的機制。隱私保護儲存、可解釋的記憶使用以及使用者同意機制的進步，將有助於在實用性與安全性間取得平衡。

最後，應檢視漏洞揭露流程與獎勵計畫的框架，以確保研究者揭露潛在暴露時能獲得及時且可行的回應。更清楚的分流準則、對接受或駁回理由的透明說明，以及協作的修復流程，能改善平台營運者與資安研究者之間的信任。

簡言之，這起事件可作為自動化代理運作安全、嵌入式工具供應鏈考量與持久化代理記憶治理的實務案例研究——這些領域值得投入工程資源並展開公共討論。