Meta Muse 以隔離執行單元、憑證代理與 Sentinel 控制代理的所有對外副作用

Meta 推出可操作瀏覽器、連接信箱與行事曆、建立工具並在背景執行長期任務的個人代理 Muse，同時公開其安全架構。值得注意的不是一般消費功能，而是系統明確假設核心模型可能犯錯或遭網頁、圖片與下載檔案中的 prompt injection 操控，再以作業系統隔離和獨立授權路徑限制損害。

每名使用者取得一台專屬 Linux VM；代理框架、工作區、工具與代理產生的程式碼位於 `systemd-nspawn` runtime cell。容器內 root 映射成主機上的非特權使用者，另有限制 syscall、capability、虛擬網路介面及獨立根檔案系統。OAuth token 與其他秘密由 cell 外的 `hatch-authd` 保存，`privsep` worker 只以所需權限執行連接器；元件間透過帶 `SO_PEERCRED` 與 ACL 的 Unix domain socket 通訊，因此即使代理取得容器內控制權，也不應直接讀到真實憑證。

所有連接器操作與網路出口則交由獨立的主機側 Sentinel 決定允許、拒絕或要求使用者確認。瀏覽器子代理只接收 accessibility tree，不取得原始 DOM、頁面內 JavaScript 執行能力或 DevTools；登入資料由用戶端直接送入安全儲存，再於需要時注入頁面。購物動作須逐次確認，未儲存卡片的付款會使用限定商戶、金額與期限的一次性卡號。這些設計把「提出動作」和「賦予副作用」分離，對企業代理平台也具有參考價值。

不過，Sentinel 仍包含模型與分類器，不能視為形式化安全邊界；Meta 也承認 prompt injection 仍未解決。現行架構依靠政策限制 Meta 人員存取，尚未從密碼學上排除服務商；承諾中的 Confidential VM、公開原始碼與持續外部稽核要到稍後才會推出。推論軌跡在移除部分個資後仍可能用於訓練，使用者需主動退出。安全研究者接下來應驗證跨域資料外洩、Sentinel 語意混淆、瀏覽器接管切換及自製連接器是否能穿透這些邊界，而不是只接受架構圖上的隔離聲明。