每少一次確認，Agent 就多一點自由：安全、完成率與使用成本

[[我也希望安全第一]]｜第 9／30 天

最方便的設定，剛好拿掉最後一次檢查

ChatGPT 的 Apple Messages 外掛可以搜尋歷史訊息、整理收件匣、草擬回覆，也可以直接替使用者發送或刪除簡訊。OpenAI 在產品說明裡特別提醒，不要輕易開啟 persistent approval，因為那會拿掉訊息以你名義送出前的最後一次檢查。

這個例子比「把 Agent 完全關在沙盒」更接近日常取捨。每封訊息都確認，使用者很快覺得煩；整個 session 永久放行，Agent 才真正像一個能代辦事情的助理。產品價值和風險用的是同一個開關。

同樣的壓力也出現在企業 Agent。ChatGPT Work 要連接 email、Slack、Notion 和 Figma，替白領工作者完成多步任務。報導引用的資料顯示，OpenAI 內部有 98% 員工使用 Codex，但機構訂閱者約 17%、個人訂閱者不到 1%；記者四天的休閒測試還消耗約 8,000 萬 token、成本約 65 美元。數字來自廠商資料與單一記者實測，不能代表所有使用者，卻把產品團隊面對的問題說得很清楚：Agent 若一直卡住、一直問、又很昂貴，很難被採用。

於是安全限制不只接受紅隊挑戰，也會接受產品經理、成本報表和使用者流失的挑戰。

三種過量，會一起放大破壞半徑

OWASP 把 Excessive Agency 的常見根因整理成 excessive functionality、permissions 和 autonomy。我會把它們翻成三個部署問題：

這三項常被混成一句「權限太大」，修法其實不同。移除 delete 工具是在縮功能；讓資料庫帳號只有 SELECT 是縮權限；要求付款前停下來則是在縮自主程度。

只做其中一項會留下很奇怪的組合。例如工具名稱叫 read_customer，底層卻使用能刪整張表的 service account；介面看起來唯讀，真正權限沒有跟著縮。反過來，一個權限很小的工具若能被 agent 每秒呼叫上千次，也可能造成成本或可用性事故。

安全限制會從四個地方收費

這些妥協不一定出自輕忽。有時一個只能建立草稿、不能寄出的銷售 Agent，確實省不了多少時間；有時人工 queue 在週末沒人處理，反而讓正式流程停擺。問題出在團隊只量 task completion，沒有把多開的能力和事故半徑放進同一張產品報表。

先替每個 workflow 編一份能力預算

對小團隊來說，最容易開始的做法是替每個 workflow 建一張能力表：

這不是永久分類。同一個 send_email，寄到公司內部測試信箱可能是 L2，寄給一萬名客戶就是 L3 或 L4。風險要看資料、目的地、數量、可逆性和登入者，而不是只看 tool name。

每個 Agent 只載入完成該 workflow 所需的 profile。再把商業上想觀察的數字寫進同一份 rollout 設定：

workflow: messages-follow-up
capabilities:
  read_recent_thread: auto
  draft_reply: auto
  send_message: per_action_approval
  delete_message: deny
budgets:
  max_tool_calls: 12
  max_runtime_seconds: 90
rollout:
  cohort_percent: 5
  compare_with: draft_only
abort_if:
  unintended_send_rate: "> 0"
  approval_mismatch_rate: "> 0"
  p95_latency_seconds: "> 45"
review_metrics:
  - task_completion_rate
  - approval_accept_rate
  - user_correction_rate
  - support_contact_rate

send_message 是否值得開，不靠會議上誰比較樂觀決定。先讓 5% 的測試群組使用，和只能產生草稿的版本比較：省下多少時間、有多少人改寫、確認視窗是否被直接略過，以及客服多了哪些問題。任何非預期送出都直接停止 rollout。

放寬以前，先知道自己換到了什麼

這張表的重點是讓安全成本和產品收益一起被看見。如果確認視窗拿掉後，任務只快了兩秒，卻第一次出現誤送，答案很容易；若完成率大幅上升，團隊才有理由投資更精準的批准介面，而不是在「全開」和「全關」之間擺盪。

網路如何確定封住，已批准的效果怎麼綁定、出錯後能不能復原，會在後面的文章繼續說明。這一篇先確認：團隊為什麼想把鎖打開，以及打開後準備用什麼數字負責。

下一篇要把第二部收起來。既然外部控制永遠會留下開口，是否應該把力氣放回模型，讓它根本不想越界？答案不會是二選一；比較有用的是判斷哪種失敗該由哪一層負責，並要求相對應的證據。

本篇的鎖

• 鎖是什麼：按 workflow 編列的能力預算、操作與成本上限，以及可隨時停止的分階段 rollout。
• 想攔什麼：團隊只為提高完成率、降低延遲或減少抱怨，便一次放開整個 session 的工具與自主權。
• 破口在哪：產品收益容易立刻看見，低機率傷害卻常延後出現；只量平均完成率，也會掩蓋少數高影響錯誤。
• 怎麼補：每次放寬只改一項能力，同時量 task success、使用者修正與意外副作用；先定 abort condition，再開始 rollout。

參考與來源

• 訊息外掛：原始報導
• Agent 採用與成本：原始報導
• 工程參考：OWASP LLM06: Excessive Agency