AI代理的核准提示不等於授權

OpenAI的Agents SDK現在將人類核准視為執行環境狀態：敏感工具呼叫可以暫停執行、顯示中斷、將決策儲存在RunState，並在核准或拒絕後，從同一次執行繼續。¹

這個產品形態抓對了一件事。核准應該存在於執行環境內，而不只是聊天紀錄裡。

更難的問題接著出現：人類實際上授權了什麼？

如果核准提示只寫著「允許shell命令？」或「核准工具呼叫？」就是要求使用者相信當下那一刻。真正的授權記錄會界定行動範圍、標示風險、保存證據、設定到期時間，並留下可供審查的軌跡。AI代理需要後者，因為代理會跨步驟規劃、呼叫巢狀工具、在遭拒後重試，也會用流暢的說明影響決策，讓人感受到按下同意的壓力。

TL;DR

AI代理的核准提示不等於授權。提示可以暫停工作，但授權必須定義誰授予權限、哪個代理取得權限、哪個工具可以執行、可以觸及哪些資源、適用哪個風險等級、授權持續多久、決策依據是什麼，以及操作員如何撤銷。團隊應該把核准設計成有範圍的授權物件，而不是聊天中的中斷提示。正確的問題不是「有人按了核准嗎？」而是「負責任的人在什麼限制下，授權了哪個具體行動？」

重點整理

給產品團隊： - 將核准呈現為型別明確的決策物件：行動、資源、風險、證據、到期與復原方式。 - 區分低風險確認與高風險授權。

給安全團隊： - 將重複出現的核准提示視為攻擊面，而不只是UX問題。 - 記錄每一次允許、拒絕、自動允許、自動拒絕、到期與撤銷。

給代理建置者： - 在不可逆行動之前暫停，而不是等代理已經塑造結果後才暫停。 - 將拒絕回饋給模型時，應作為有約束的指令，而不是模糊的失敗訊號。

給操作員： - 如果看不到目標資源、授權範圍與復原路徑，就不要核准工具呼叫。 - 優先使用短效、有範圍的授權，避免養成「一律核准」的習慣。

為什麼核准提示會失效？

當核准提示把高脈絡決策壓縮成低脈絡點擊時，就會失效。

代理掌握的脈絡往往比提示畫面顯示的更多。它可能已經讀取檔案、摘要討論串、規劃流程、選擇工具、填入參數，也決定了執行時機。核准提示通常只顯示最後一步。使用者看到的是一個命令、一個API呼叫、一個瀏覽器動作，或同一個代理寫出的請求許可句子。

這種介面會造成4種失效：

OWASP的Agentic Top 10直接點名了說服風險。其發布文章在ASI09「Human-Agent Trust Exploitation」中指出，自信的說明可能誤導人類操作員，使其核准有害行動。² 這種風險不需要惡意模型才會發生。樂於協助的代理仍可能過度推銷薄弱計畫、淡化不確定性，或把高風險工具呼叫埋進一串看似無害的步驟裡。

因此，核准需要更好的形態。人應該核准一筆行動記錄，而不是一個請求氣泡。

核准應該授權什麼？

嚴謹的核准應該只在有邊界的條件下，授權一個具體行動。

〈Authenticated Delegation and Authorized AI Agents〉這篇論文將更大的問題界定為委派權限：使用者需要方法限制代理權限，並維持清楚的責任鏈；做法包含代理專用憑證、中繼資料，以及可稽核的存取控制設定。³

這個框架很適合轉化為產品設計。核准應包含：

少了這些欄位，核准就只是帶按鈕的感覺判斷。模型可以禮貌地提出請求。人類可以快速點擊。兩者都不能證明這個行動本來就該發生。

核准狀態應該如何運作？

核准狀態應該能撐過暫停，但範圍仍要維持狹窄。

OpenAI的Agents SDK文件描述了一個有用的執行環境模式。工具可以宣告needs_approval；執行器會在執行前評估核准規則；尚未解決的核准會以中斷形式出現；開發者可以核准或拒絕每個待處理項目；執行會從RunState繼續。¹ 文件也描述了同一次執行中後續呼叫可使用的黏性決策，例如always_approve與always_reject。¹

狀態機很重要，因為暫停中的代理執行不應該從記憶重新開始、重建意圖，或遺失核准脈絡。它應該帶著決策，從中斷點繼續。

黏性決策選項也帶出下一個設計要求：每個黏性核准都需要範圍與到期時間。

黏性核准可以降低疲乏。過度寬鬆的黏性核准，則可能把一次疲憊點擊轉換成整次執行的完整影響半徑。

核准應位於執行環境的哪裡？

核准應位於提交點之前。

提交點是代理從可逆工作跨入副作用的瞬間：修改生產資源、傳送訊息、花費金錢、發布內容、刪除資料、輪替金鑰、變更權限或部署程式碼。提交點之後的人類核准是事件應變，不是授權。

人類監督文獻也支持這個區分。2026年一篇AI and Ethics論文區分了操作性代理與評估性代理；前者由AI生成或行動，後者讓人類評估、質疑與覆寫。⁴ 有效監督不能仰賴人盯著每個token。介面必須把人類判斷保留在仍能改變結果的時點。

這給代理產品一條簡單規則：

如果提示出現在代理已經執行高風險部分之後，就只是表演。系統已經花掉權限時，人就無法行使評估性代理。

如何防止核准疲乏？

核准疲乏是安全漏洞，因為疲乏會改變決策。

如果一次執行要求40次核准，產品很可能在使用者點擊之前就已經失敗。操作員不再判斷每個項目，而是在處理煩躁感。攻擊者可以利用這種模式，製造重複請求、把高風險行動藏在批次中，或用文字讓危險呼叫看起來像例行作業。

OWASP的Agentic Top 10將人類與代理之間的信任利用列為一級風險類別。² 代理安全研究也從系統面得到相同輪廓。2026年3月一篇代理式AI安全系統化研究，將信任邊界映射到提示注入、RAG污染、工具與外掛漏洞，以及多代理威脅；同時也呼籲導入執行環境監控與事件應變控制。⁵ 2026年5月一篇關於安全可稽核代理的論文則指出，除非系統能把能力、記憶、目標、推理軌跡與行動串成可查詢的稽核路徑，否則靜態物料清單與執行環境記錄只會提供破碎證據。⁶

核准設計應透過移除低價值提示、提高高價值提示品質來降低疲乏：

目標不是減少控制。目標是減少沒有意義的控制。

核准UI應該顯示什麼？

核准UI應該顯示決策，而不是代理的個性。

先從精簡的決策卡片開始：

這張卡片幫助使用者回答一個問題：請求的行動是否符合證據與範圍？

卡片不應埋藏精確參數。不應隱藏拒絕。不應把「核准」設計成唯一順路選項，而讓「拒絕」像例外。一個好的核准介面會把拒絕視為正常控制訊號。代理應收到精確訊息：「因來源URL尚未驗證而拒絕」，或「因命令觸及發布範圍外的檔案而拒絕」。

團隊應該先建置什麼？

先建立核准紀錄帳，再美化提示。

最小紀錄欄位：

1. Run ID。
2. Agent ID。
3. Operator ID。
4. 工具名稱。
5. 工具參數。
6. 目標資源。
7. 風險等級。
8. 觸發的核准規則。
9. 證據指標。
10. 決策：已核准、已拒絕、自動核准、自動拒絕、已到期或已撤銷。
11. 決策時間。
12. 到期條件。
13. 執行後結果。
14. 復原或控制指標。

紀錄帳會把核准從UI事件轉化為責任記錄。它也讓團隊日後能提出更好的問題：

• 哪些工具太常要求核准？
• 哪些操作員最快核准高風險行動？
• 哪些核准規則觸發誤判？
• 哪些被拒絕的行動後來找到安全替代方案？
• 哪些已核准行動造成復原？
• 哪些黏性授權存活太久？

2026年5月那篇作業系統安全論文主張，代理面臨的是熟悉的作業系統式問題：資源隔離、權限分離與媒介化通訊。⁷ 核准也屬於同一類。執行環境應該像作業系統調解特權操作那樣調解權限：狹窄、一致，並留下比請求本身更長壽的記錄。

快速總結

AI代理核准需要變成授權物件。暫停並點擊的提示可以阻止工具呼叫，但無法單獨承擔責任。有效的核准系統會定義行為者、行動、資源、風險、證據、期間、到期、撤銷與稽核。

產品教訓很直接：讓低風險工作安靜進行，讓高風險工作明確呈現；當系統可以顯示有範圍的行動記錄時，絕不要要求人類核准一段流暢說明。

FAQ

AI代理的核准與授權有什麼不同？

核准是一次人類決策事件。授權則是在明確條件下，讓代理執行具體行動的有範圍權限。強健的代理系統會把兩者連起來：人類核准會建立一筆狹窄的授權記錄，包含資源、風險、到期、證據與稽核欄位。

每一次AI代理工具呼叫都需要核准嗎？

不需要。團隊應依風險分流核准。已知範圍內的低風險讀取，可以安靜執行並留下記錄。中風險行動可以批次審查。高風險行動，例如傳送訊息、發布、刪除、部署、花費、匯出或變更權限，應在執行前暫停。

黏性核准對AI代理安全嗎？

當範圍狹窄、短效且可見時，黏性核准可以有幫助。針對唯讀工具、限於單次執行的核准可能合理。但對shell、部署、付款、寄送email或刪除動作給予寬泛黏性核准，會讓一次決策產生過大權限。

AI代理核准提示應包含什麼？

核准提示應包含行動、資源、工具參數、行為者、風險等級、證據、到期、復原路徑與稽核指標。提示也應提供拒絕、要求證據與拆分範圍等決策，而不只是核准。

團隊如何降低代理產品中的核准疲乏？

團隊可以在政策內自動允許低風險行動、群組化中風險決策、只在提交點中斷、顯示結構化證據、讓授權到期，並把拒絕記錄為正常控制路徑。更好的核准會少問模糊問題，多問精準問題。

參考資料