Muse 真正開始替你做事後，你一定會遇到一個畫面：
Approval。
例如：
AI 已經幫你把 Email 寫好。
準備寄出。
或者商品已經找到。
準備付款。
Muse 會停下來問：
要不要允許？
很多人這時候只會看：
「Yes 還是 No？」
但今天要多看一件事：
「這個 Yes 到底可以用多久？」
Muse 的 Approval 不只分「准、不准」
Meta 對 Muse 的安全設計裡，有一個獨立的 Sentinel。
它不是負責替你完成主要工作。
而是專門判斷：
Muse 現在要求的 Connector Action 或網路操作，到底可以：
允許。
拒絕。
還是需要再問使用者。
如果需要你批准，系統會停下來。
Muse 本身不能自己偷偷替你按 Yes。
但更重要的是：
批准也有 Scope。
Scope 可以理解成：
這個權限到底涵蓋多大的範圍。
Meta 支援哪些 Permission Scope？
Meta 技術文件列出的 Muse Approval 類型包括：
One-time。
也就是只允許這一次。
Session-scoped。
只在這個 Session 有效。
Task-scoped。
只在這個 Task 有效。
Time-bounded。
只在一段指定時間內有效。
以及：
Perpetual。
持續有效。
不過不是每一次 Approval 畫面都一定會把所有選項全部列出來。
Meta 說明，是由 Sentinel 根據這次行為決定哪些 Grant Type 適合提供。
所以今天不是教你：
「每次一定會看到五個按鈕。」
而是教你一個判斷方式。
今天只記一條：第一次先給最短 Scope
假設你第一次叫 Muse：
「幫我寫一封 Email 給飯店，詢問有沒有機場接送。」
Muse：
查完資料。
寫好內容。
準備寄出。
這時如果畫面提供：
只允許這一次。
和：
以後都可以替我寄信。
第一次比較合理的選擇通常是：
只允許這一次。
原因不是你一定不能信任 Muse。
而是：
你目前真正需要的權限，本來就只有寄這一封信。
不要把「省一次點擊」變成「多很多未來權限」
想像另一個情況。
你今天只是請朋友幫你進家裡拿一個包裹。
你會給他：
今天下午可以進門一次。
還是：
從此以後永久持有你家鑰匙？
不是說這個朋友一定不可信。
而是：
完成今天這件事，根本不需要永久鑰匙。
AI Agent 的權限也是一樣。
如果任務只需要一次：
就先給一次。
如果整個 Task 需要反覆做同類動作：
再考慮 Task Scope。
只有真的出現穩定、長期、重複工作時：
才值得重新評估更長的授權。
例如：整理行程和寄信需要的權限不一樣
假設你請 Muse：
「幫我規劃下週的出差。」
它可能需要：
讀 Calendar。
讀 Email。
找航班。
比較飯店。
最後準備寄一封確認信。
你不需要因為它要完成整個旅行規劃，就把所有權限都設成同樣長度。
讀 Calendar：
如果整個 Task 都需要，可以考慮 Task Scope。
寄出最後那封 Email：
可能只需要 One-time Approval。
付款：
更應該針對每次實際交易確認。
這才是 Permission Scope 真正的用途。
同一個 Agent，不同 Action，可以有不同權限長度。
「這次准了」也不等於「以後任何事情都准了」
Meta 的 Muse Approval 還有另一個重要設計。
批准不是只記一句：
「這個人相信 Muse。」
Permission 會綁定到比較具體的：
Connector。
Destination。
Use Case。
也就是：
哪一個服務。
要去什麼地方。
做什麼事情。
這比單純在 Prompt 裡說：
「你以後可以幫我處理。」
更接近真正的技術權限。
例如你批准 Muse：
替這次任務寄出某封 Email。
不代表 Muse 因此取得：
任意登入其他網站。
任意使用所有 Credential。
任意代表你做其他事情。
為什麼要從最短權限開始？
因為 AI Agent 和一般 App 最大的差別，是它會自己走很多步。
一般 App：
你按一個按鈕。
它做一件固定的事。
Agent：
你給一個 Goal。
它可能：
找資料。
開網站。
讀 Email。
呼叫 Subagent。
填表。
再根據中途得到的新資料決定下一步。
這種彈性就是 Agent 好用的地方。
但也代表：
它未來會遇到的情境，很難全部在第一天預測。
所以在你還不了解一個工作流程之前：
權限愈長。
未來可以作用的情境也愈多。
最簡單的方法：問「這件事做完後，權限還有存在的必要嗎？」
下次看到 Muse Approval，可以先不要立刻按。
只問自己一句：
「這件事完成後，這個權限還有存在的必要嗎？」
如果答案是：
沒有。
選一次性。
如果答案是：
這整個 Task 還需要。
考慮 Task Scope。
如果答案是：
今天工作期間還會反覆使用。
才考慮比較適合的 Session 或限時 Scope。
只有當你真的確認：
這是一個長期固定流程。
風險也可以接受。
才重新評估 Persistent 或 Perpetual Permission。
先小，再慢慢放大
可以把它記成：
一次 → 一個 Task → 一段時間 → 長期。
不要反過來。
第一次直接：
長期全部打開。
之後發現太大，再慢慢往回關。
因為在 Agent 世界裡，最容易失控的往往不是：
「AI 完全沒有權限。」
而是：
以前為了方便給出去的權限，後來大家忘記它還存在。
但「最短 Scope」不是所有情況永遠最好
如果你每天都固定叫 Muse：
整理同一個 Calendar。
在同一個範圍讀取同樣資料。
每次都要求相同操作。
人工每次重新批准可能真的沒有必要。
這時較長的 Permission Scope 就可能合理。
所以今天的原則不是：
永久權限一定錯。
而是：
第一次不要因為怕麻煩，就直接從最大權限開始。
先讓工作真的跑過。
看看 Agent 做了什麼。
確認 Audit Trail。
看看有沒有意料之外的步驟。
再決定是不是值得延長。
Approval 也不是萬用安全保證
就算你永遠選最短 Scope，也不能得到：
「Agent 絕對不會出錯。」
Meta 自己明確表示：
Muse 仍然可能犯錯。
也可能讀到帶有 Prompt Injection 的外部資料。
所以 Muse 除了 Human Approval，還另外使用：
Secure VM。
Credential Isolation。
Sentinel。
網路出口控制。
Prompt Injection 偵測。
以及其他技術邊界。
這代表：
Approval 是安全層之一，不是全部。
人的 Permission Choice 也不能取代系統本身的安全設計。
今天實際怎麼做？
下次 Muse 跳出 Approval 時：
先不要只看：
「它現在想做什麼？」
多看第二個問題：
「我這次批准之後，它可以用這個權限多久？」
如果只是完成現在這一件事：
選最短可用 Scope。
先跑一次。
看完結果。
再決定下一次要不要放大。
這個動作可能只多花幾秒鐘。
但當 AI Agent 開始碰：
Email。
Calendar。
帳號。
購物。
付款。
真正代表你對外做事時：
權限多一天。
和只准一次。
已經不是同一件事。
所以今天只記一句：
第一次授權 Agent，不要先問「怎樣最方便」，先問「完成這次任務最少需要多久」。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 快問快答｜2026/09/01：OpenClaw 固定 Automation 已經核准一次，就代表之後每次執行都安全、不用再看嗎？
AI 一分鐘教學｜2026/09/01：OpenClaw 跑固定工作前，先寫「能做、一定停、憑證怎麼拿」最小權限卡
AI 快問快答｜2026/09/03：Workspace Studio 已經設定 Approval，就代表所有高風險動作一定會停下來嗎？
