最近看到一篇研究在測試工具型 agent 的 approval flow，我們把「拿到 token」誤當成「拿到完整授權」。

研究在官方 OpenClaw 環境做了 23 次控制實驗，原始配置有 9/9 次走到 token transition，8/9 次完成目標操作。只要沿著表面合理的核准流程前進，再把 token 交給文件服務，就可能完成原本沒有被清楚核准的事情。

核准的產品物件到底是什麼

approval 不應該只是yes/no，也不應該只是一串代表「有人按過同意」的 token。至少要綁定六個欄位：requester、approver、resource、action、recipient，以及 business purpose。

少了任何一項，使用者核准的範圍就可能和系統真正執行的範圍不同。例如使用者同意 agent 讀取內部報告，結果卻被轉寄到外部信箱。前者是 read，後者已經包含 export 或 share。畫面若只寫「允許 agent 處理文件」，就是把最重要的 trade-off 藏起來。

介面要讓人看見落差

核准畫面應同時顯示「現在核准的內容」和「實際動作」，不要只放Allow。我會要求露出：

1. Request summary：誰提出請求，代表哪個 agent 或 service。
2. Scope：resource、action、資料範圍與有效時間。
3. Destination：結果會送給誰，包含外部 recipient。
4. Purpose：這次操作要解決什麼 business purpose。
5. Change alert：執行時欄位若改變，要求重新核准。

硬性驗收條件是，六個欄位任一個變更，原 token 就不能直接通過。系統要阻擋、提示差異，並建立新的 approval。否則核准只是把人工點擊包裝成安全感。

PM 可以怎麼驗收

我會準備三組測試。第一組驗證 happy path，核准讀取指定文件並寄給指定收件人，系統只能完成這個範圍。第二組逐一替換六個欄位，例如把 read 改成 write、把內部收件人改成外部收件人，確認每次都重新核准。第三組測試 token replay，確認 token 被不同 requester、service 或 resource 重用時會失效。

驗收不要只看有沒有跳 approval dialog，而要看執行前後的 diff：核准了什麼、實際做了什麼、哪個欄位造成阻擋。diff 要能讓 stakeholder 看懂，也要能查 audit log。

安全產品的核心不只是多一道確認，而是讓人的意圖一路傳遞到最後一個工具。使用者按下核准時，要知道自己給出去的是哪個範圍的權力；系統執行時，也要證明自己沒有偷偷擴張。