2026 年 9 月 21 日，Amazon 開始阻擋 Meta Muse 在 Amazon.com 瀏覽與代購；同一週，macOS 安全研究者 Patrick Wardle 公開 Muse 本機用戶端的漏洞，Meta 隨後發布 hotfix。兩件事看似一個是商業衝突、一個是資安事件，卻都指向個人 AI Agent 的同一個問題：模型理解了使用者的要求，不代表整條執行路徑都取得了授權。

Meta 在 9 月 8 日推出 Muse，讓它能在專屬雲端 VM 裡使用瀏覽器與已連接的服務，處理郵件、表單、購物等多步驟工作。Meta 說，寄信或購買前會要求使用者核准，並以獨立的 Sentinel 控制連接器動作和對外網路請求。官方產品說明與安全架構文章提供了可檢視的設計承諾；但要評估 Agent 能否完成任務，還得把使用者、執行環境與外部服務的權限分開看。

Muse 把聊天帶進真實工作

傳統聊天機器人的主要輸出是文字。個人 Agent 則會讀取帳號內容、填表、發出郵件、操作瀏覽器，甚至進入付款流程。從「回答要怎麼買」變成「替我買」，系統的責任也從提供建議擴大到代替使用者執行動作。

Meta 公開的 Muse 設計把執行環境拆成不同安全區域：Agent 的 runtime cell 不直接持有第三方服務的真實憑證；外部連線與連接器動作交由 VM 內不同權限的元件處理；Sentinel 再依使用者設定判定允許、拒絕或詢問。需要核准時，核准卡片由 Muse 介面直接呈現，權限可以限制在特定連接器、用途與時間範圍。Meta 的技術說明也指出，瀏覽器操作與付款等高影響行為會有額外檢查。

這些設計值得工程團隊逐項檢視，但它們仍是 Meta 對自家系統的描述，不是外部稽核結論。安全機制能限制 Muse 在自己的環境裡做什麼，不能替其他服務決定要不要讓 Muse 進來。

三方都放行，任務才算可執行

把 Agent 的行動拆成三道邊界，能更準確地定位失敗發生在哪裡。

使用者授權：允許的是哪一個動作？

「連接 Gmail」不應該被解讀成「Agent 可以代我寄出任何郵件」。讀取、草擬、發送、刪除是不同能力；購物也應區分搜尋、加入購物車、提交訂單與付款。若核准只顯示「繼續」，使用者就無法判斷自己究竟同意了什麼。

因此，授權畫面至少要指出連接的帳號、動作、目標、資料範圍與有效時間。可以先給讀取權限，確認任務流程和稽核紀錄符合預期，再決定是否開放寫入或付款。Meta 的技術文章描述了讀寫權限分離與限時核准，這種把權限縮小到用途的方式，比單一的「已連接」標記更容易檢查。

執行環境：模型能提出動作，不等於能自行批准

Agent 需要看見資料才能完成任務，但同一份資料也可能含有錯誤指令或惡意提示。若讀取郵件的模型同時能取得帳號 token，又能任意對外傳送資料，單次判斷錯誤就可能跨過好幾道原本應分離的防線。

Meta 所描述的隔離 runtime、憑證代理與 Sentinel，分別處理程式執行、秘密資料與對外請求。這些是有用的架構分工：模型提出意圖，具有明確權限的控制元件才負責核准請求。核准結果也應以結構化資料綁定目的地和動作，而不是把使用者在對話中說的「好」當成永久通行證。

外部服務政策：使用者不能替網站同意

9 月 21 日 Amazon 阻擋 Muse 購物。Amazon 對外表示，代表顧客向其他業者購買的第三方應用應遵守服務提供者是否參與的決定；Meta 則將 Muse 定位為能在網路上代辦的個人 Agent。Axios 的報導呈現了雙方在代理購物權限上的落差。

這不是 Muse 是否有能力找到商品的問題，而是使用者、Agent 平台和商家之間沒有共同的執行契約。使用者授權 Muse 使用自己的瀏覽器或帳號，不代表商家同意這個自動化客戶端；同樣地，Agent 能打開網頁，也不表示它能完成付款。Meta 與 Stripe Link、Shop Pay 等服務的合作說明了另一條路：有些動作可以透過服務提供者明確支援的整合來執行。

**我的判斷是，第三方服務回覆拒絕時，Agent 應回報 blocked_by_provider，停止重試並提供使用者可選的合法替代路徑。**它不能把「使用者想做」當成繞過網站政策的理由，也不應把打開商品頁說成已完成購買。

9 月的安全事件，提醒我們把本機用戶端也納入威脅模型

Amazon 的限制在服務邊界；Wardle 公開的漏洞則在使用者裝置與 Muse 用戶端。Ars Technica 報導，該漏洞涉及 macOS 本機程式可控制 Muse 的未公開設定，並改變語音轉錄所使用的端點；在帳號已連接服務、語音操作等條件成立時，攻擊者可能藉此取得 Muse 帳號控制權。這不是任意遠端網站只靠一段提示詞就能入侵的漏洞，報導也指出 Meta 在揭露後發布了 hotfix。Ars Technica 的事件時間線與條件說明值得連同修補狀態一起閱讀。

這件事不能被縮成「雲端 VM 有隔離，所以安全」。個人 Agent 的完整路徑還包含桌面用戶端、麥克風權限、token 傳遞、VM 連線和第三方連接器。單一 VM 邊界再嚴格，也無法替本機應用程式自動取得的權限背書。測試計畫要從使用者輸入一路追到請求送出的位置，檢查每個中介元件能讀取什麼、能修改什麼，以及憑證是否會在邊界上被替換或暴露。

同一週也有使用者表示，Muse 讀取了他以為沒有授權的私人訊息。TechRadar 在 9 月 23 日轉述了這名作者的說法；目前應把它視為一項具名使用者報告，而不是已證明所有帳號都會發生的系統性行為。TechRadar 對該報告的整理至少提出了可操作的驗收問題：使用者能否查出資料從哪個連接器進入、核准過哪些權限、以及 Agent 為何做出某項主動建議？

社群反應也同時看見便利與不信任。一位 YouTube 留言者表示自己用 Muse 刪掉 Gmail 裡超過十萬封郵件，說明 Agent 確實可能替使用者省下大量手動整理；同一支影片下，另一位留言者寫道：「Meta is very good in turning you into a product by offering you free products. This is that on steroids.」這是個人看法，不是民意調查，但它點出個人 Agent 的採用成本：功能越需要讀取生活資料，使用者越需要相信資料用途和權限狀態能被查證。Alex Finn 的 Muse 實測影片與留言

把「完成」設計成可驗證的結果

工程團隊可以先替每個任務定義四種結果，而不是只有成功與失敗：

  • awaiting_user_approval：任務可以繼續，但必須先讓使用者核准明確的動作與參數。
  • blocked_by_runtime：沙盒、權限或安全政策拒絕了 Agent 的請求。
  • blocked_by_provider：外部服務拒絕自動化、登入狀態或交易。
  • completed：服務已接受動作，而且系統取得足以確認最終狀態的證據。

每筆紀錄應保留任務目的、目標服務、請求動作、使用者核准範圍、服務回應和最終狀態。不要把「模型產生了送出指令」、「瀏覽器按下了按鈕」或「背景工作已停止」當成交易完成。付款需要訂單確認；寄信需要可追蹤的送出結果；刪除資料則應確認範圍與回復方式。

遇到服務拒絕時，Agent 應保留原始拒絕理由，向使用者說明它停在哪一步，並提供可選的手動流程或正式支援的整合方式。使用者若選擇其他路徑，再建立新的、明確授權的任務。這樣做會多一次互動，但能防止 Agent 把政策拒絕誤認為網路錯誤，接著用不同身份、不同工具或更寬的帳號權限繼續試。

從可逆、低權限的工作開始

Meta Muse 讓 Agent 從回答問題往前跨到真實服務。它的 VM、Sentinel 與核准卡片提供了可參考的權限設計；Amazon 的拒絕和本機漏洞報告則提醒我們，Agent 的能力始終受到使用者、執行環境和外部服務三方限制。公開架構說明能提出可檢查的主張，真正的信任仍要靠每次動作的權限範圍、拒絕處理與完成證據建立。

如果你正在替產品加入 Agent，先選一個可逆、低權限的任務，只開啟讀取或草稿能力。確認稽核紀錄能回答「Agent 看了什麼、要求做什麼、誰核准、服務回了什麼」之後，再逐步開放寄送、刪除或付款。接著可參考本站的連接介面、授權與核准設計與AI Agent 狀態機和工具沙盒文章，把這些停止狀態納入 runtime。

參考資料