一個帶人工批准的 AI 工作流程應在高影響動作前停下，展示確切目標、範圍、變更、權限和後果，並透過可信通道接收決定。系統必須把批准綁定到審閱者、提案版本、允許動作和有效期。任何實質變化都會令批准失效，並需要重新決策。

Microsoft 的 Work Trend Index 把有效 Agent 使用與人類判斷和主動權連結。［1］真正的審批門檻會把原則變成技術邊界：它不是叫人為黑箱結果蓋章，而是提供足夠的已核驗資訊，讓人接受或拒絕一個具體動作。

關鍵要點

先按後果分級動作，再確定審批點。

分開提案產生與高權限執行。

展示完整、可讀、可核驗的審批包。

把批准綁定到身份、版本、範圍和到期時間。

輸入、權限或效果變化時必須重新批准。

測試偽造對話框、過期批准和間接提示注入。

先用重複任務自動化流程選擇並原型化有邊界的任務。本文由提案可能產生外部副作用的位置開始。

哪些動作需要帶人工批准的 AI 工作流程？

按動作可能造成的後果分類，而不是按系統調用它有多容易。要考慮保密性、金錢、法律權利、安全、對外溝通、資料完整性、帳戶存取、可逆性、受影響人數和復原時間。

一個簡單的分級模型如下：

等級	典型後果	預設控制
讀取	查看獲准資料，不作任何改動	記錄日誌、最小權限存取
起草	產生內容，不向外發送	使用前人工審閱
可逆寫入	修改有可靠回復機制的有界紀錄	批准或範圍狹窄的預授權
外部或高權限動作	發送、發佈、付款、授權、刪除或部署	對精確動作的明確批准
不可逆或高影響	安全、權利、重大財務、大範圍刪除	獨立控制或排除在外

同一個工具調用可能屬於不同等級。起草電郵不等於發送電郵；產生存取規則提案不等於安裝規則；展示 diff 不等於部署。把風險等級寫進工作流程定義，令模型無法透過改寫動作描述來降低其等級。

OWASP 的 Excessive Agency 指引建議限制功能、權限和自主程度，並對高影響動作要求用戶批准。［2］審批只是其中一層，不能取代最小權限、校驗、速率限制或回復。

步驟 1：分開提案和執行

在無法執行高影響動作的環境中產生提案。提案階段可以讀取獲准輸入、產生結構化候選、校驗候選並製作預覽，但不應持有執行憑證。

執行服務只應接受已校驗的提案 ID 加上可信的批准憑據。它必須重新讀取規範（canonical）提案，再次檢查政策和權限，並只執行其中編碼的操作。批准之後，不要讓模型另行傳送任意工具參數。

這種分工帶來清晰的責任劃分：

模型提出提案；
確定性程式碼負責校驗和打包；
經身份認證的人作出決定；
可信執行器中介每一個副作用；
審計儲存記錄決定和結果。

如果執行器由生成的程式碼實現，請按AI 程式碼審閱清單檢查。權限執行、序列化、重試和故障復原，都需要與其他安全敏感程式碼同等的審閱。

步驟 2：為 AI 審批工作流程製作完整審批包

審批介面應直接回答「到底會發生甚麼」，而不要求審閱者從聊天紀錄重組提案。應包括：

目的：為何要求這個動作，由誰負責；
目標：精確的帳戶、紀錄、收件人、環境或資源；
範圍：包括和排除的項目、數量、時間範圍和目的地；
變更：可讀的 diff 或前後對照；
證據：支持提案的已校驗輸入和政策檢查；
權限：執行器將使用哪項能力和哪個憑證；
效果：對外訊息、寫入、費用、存取變更或下游工作；
風險與可逆性：可能的失敗方式和回復限制；
版本和有效期：不可變的提案身份和決定期限；
替代選項：拒絕、編輯後重新產生、收窄範圍或上報處理。

可以逐層展開細節，但絕不能把重大後果藏在摺疊的摘要內。突出顯示不確定和缺失的資料。如果提案涉及大量紀錄，要同時展示匯總和可供審閱的樣本；當集合超出已批准的邊界時，要求更嚴格的審閱。

不要只展示模型生成的文字。關鍵欄位應從規範的結構化資料和確定性政策檢查中產生。審閱者應能分辨哪些陳述已經核實，哪些只是模型的解釋。

步驟 3：把批准綁定到身份、版本、範圍和有效期

批准憑據應標明已認證的審閱者、角色或權限、提案 ID、內容版本、容許的動作、精確範圍、目的地、有效期、決定和決定時間。以適合你系統的身份與完整性控制保護它。

執行時，把批准憑據與規範提案對照。出現以下情況時拒絕執行：

提案雜湊值或版本已改變；
動作類型、目標、目的地或紀錄集合已改變；
所要求的權限更寬；
批准已過期或被撤銷；
審閱者已不再擁有相應權限；
政策或相關狀態已改變；
規定只能使用一次的憑據已被使用。

批准「發送每週摘要」，並不等於批准發送其後修改的草稿、加入收件人、附加檔案或更換帳戶。以往的一般偏好可以指導低風險起草，但不應被理解為對高影響動作的永久授權。

批准有效期應短至與底層狀態的變化速度相符。如果存貨、帳戶存取、收件人、價格或部署目標可能很快改變，就要在執行前立即重新校驗；實際效果有實質差異時，要求重新批准。

步驟 4：定義拒絕、逾時、編輯與重試行為

拒絕是正常結果，不是需要繞過的錯誤。有需要時記錄理由，停止該提案，並防止同一動作被自動重新提交。修訂後的提案需要新的身份和新的批准。

逾時應 fail closed（預設拒絕）。不要把沉默當作同意。按政策通知負責人，或把請求標為已過期。如確需緊急處理，應走另行管治的上報途徑，而不是降低關卡。

在審批介面內直接編輯可能很危險，因為展示的變更與實際執行的變更可能不一致。優先採用「拒絕並重新產生」，或根據編輯結果建立新的規範提案，再展示新版本供批准。

重試必須保留動作身份。遇到逾時或網絡回應不明確時，先查詢目標系統，確認動作是否已經發生。盲目重放付款、訊息、權限變更或部署，可能令效果重複。下游系統支援時使用冪等機制，不支援時設計明確的復原程序。

步驟 5：批准後仍要中介每個動作

OWASP 要求對 Agent 工具調用作完整中介，而不是信任模型的計劃。［2］執行器應獨立檢查所要求的操作、參數、目標、授權、批准綁定、速率限制和現行政策。

使用範圍狹窄的操作允許清單。不能因為審批包顯示了一段安全摘要，執行器就接受 shell 指令或自由形式的 API 調用。把已批准的提案轉換成欄位有界的類型化內部指令。

執行最小權限：

分開讀取、提案和執行身份；
只授予目標資源和目標操作的存取權；
避免把長期憑證放進模型上下文；
限制動作量和受影響紀錄數目；
批准後禁止更改目的地；
既記錄執行，也記錄拒絕；
讓緊急停止開關留在模型控制之外。

當審批包含敏感來源資料時，請參考AI 私隱風險。展示足以作出決定的證據，但不要把無關的個人或機密資料複製到介面或日誌。

步驟 6：保護人機協作 AI 控制免受操縱

OWASP 的 AI Agent 安全指引把提示注入、工具濫用、記憶污染、過度自主和人類監督不足視為互相關連的風險。［3］外部內容絕不能建立、偽裝或提交一個可信的批准。

Lies-in-the-Loop 攻擊描述了偽造或誤導性的人機互動，用以誘騙用戶批准某個動作。［4］凡是由不可信網頁內容、電郵、文件或模型輸出渲染而成的對話框，都應視為不可信。真正的審批介面應有明確的來源、已認證的工作階段、穩定的提案身份和已核實的動作詳情。

防禦措施包括：

把不可信內容渲染在清楚分隔的資料區域；
絕不執行其中包含的連結、表格或指令；
把批准和拒絕控制項放在可信的應用程式介面框架中；
在最終決定點再次顯示目標和 diff；
較高風險等級要求重新認證；
防止模型把自己的提案標記為已批准；
對異常敏感的動作發出獨立通知；
在網頁介面中偵測框架嵌套、覆蓋層或來源混淆。

不要依賴「此動作是安全的」這類措辭。決定必須建基於獨立得出的欄位和政策結果。

步驟 7：測試批准、審計執行並準備回復

先測試正常流程，再嘗試破壞批准綁定。測試應包括：

批准後修改提案；
更改收件人、環境或目的地；
擴大紀錄集合或權限；
使用過期、已撤銷、重複或已用過的批准；
由已認證但無相應權限的角色批准；
聲稱已批准的偽造介面或內容；
檢索材料中的間接提示注入；
下游逾時且執行結果未知；
部分執行且回復失敗；
審計儲存或通知故障。

安全的結果是可見的停止，而不是猜測的成功。確認動作沒有發生、嘗試已被記錄且沒有洩露密鑰，而且獲授權的操作人員能理解原因。

NIST 的生成式 AI 概況文件強調在 AI 整個生命週期中進行管治、記錄、量度和管理。［5］把測試證據與工作流程版本一併保存；模型、提示詞、schema、政策、身份系統、工具或用戶介面有變後，重新執行測試。

審計執行並令回復真正可用

記錄提案 ID、工作流程版本、審閱者身份、決定、批准範圍、時間戳記、校驗結果、執行器身份、下游請求身份、結果和回復狀態。盡量減少日誌中的敏感內容，並防止日誌被未經授權修改。

審計紀錄必須區分：

已提出但從未獲批；
已拒絕或已過期；
已批准但未執行；
執行成功；
執行結果未知；
部分執行；
已回復或已修正。

以接近真實的權限和依賴測試回復。如果下游訊息無法撤回，或外部用戶已據此採取行動，一個標示「復原」的按鈕並不構成復原計劃。對於不可逆效果，要加強執行前審閱，或把該動作移出工作流程。

為停機和有爭議的批准保留人手操作程序。SOP 冷運行檢查可以在事故發生前揭示負責人、憑證或復原步驟方面的缺口。

如何量度人機協作 AI 審批關卡？

不要只看批准率。按風險等級追蹤提案、審閱時間、拒絕與重新產生的原因、試圖改變範圍的次數、過期批准、執行器拒絕、關鍵錯誤、回復成功率和審閱者分歧。批准率很高可能反映提案質素出色，也可能反映審閱者疲勞或審批包資料不足。

抽樣檢查已批准的動作，把展示的審批包與規範提案和實際副作用對比。訪問審閱者：他們實際用了哪些欄位、哪些內容無法核實、何時感到被催促。在提升清晰度的同時，不要刪去重要細節。

通用 AI 使用指南為有邊界的任務和核實提供了更廣的框架；審批關卡只是這個更大系統中的一項專門控制。

常見問題

按下「批准」就足以構成人類監督嗎？

不足夠。審閱者需要一份可信、完整的審批包，以及真正拒絕的權力。系統必須把決定綁定到一個精確提案，並獨立中介執行。

哪些動作一定需要批准？

答案取決於你的風險政策，但對外溝通、資金轉移、存取權限變更、刪除、發佈、部署和高影響決定，通常都需要明確控制。當中部分應完全排除在 AI 執行之外。

一次批准可以涵蓋一個批次嗎？

只有當批次成員、範圍、目的地、上限和效果都可見且固定時才可以。任何新增項目或改變了的目標，都應令批准失效，或進入另行授權的規則。

批准後提案改變了怎麼辦？

拒絕已過時的批准，並建立新的提案版本。不要原地修補已獲批的內容，也不要假設審閱者會接受類似的變更。

批准應該有效多久？

按相關狀態和風險變化的速度設定有效期。執行前立即重新校驗；效果有實質差異時，要求重新作出決定。

AI 可以解釋某個動作為何安全嗎？

它可以提供清楚標示的解釋，但關鍵欄位和政策結果應來自規範資料和確定性檢查。模型的自信不是批准證據。

如何防止偽造的審批對話框？

使用可信的應用程式來源、已認證工作階段、穩定的提案身份、分隔開的不可信內容、已核實的目標詳情和受保護的控制項。測試覆蓋層、嵌入內容和間接提示注入。

執行逾時應該如何處理？

在檢查目標系統之前，把結果視為未知。不要自動重放高影響動作。使用冪等機制或明確的對帳程序。

延伸閱讀

免責聲明：本文提供一般安全與工作流程資訊。審批要求取決於系統、風險、法律和政策。高影響部署應由合資格的安全、私隱、法律和營運人員審閱。

來源：

Microsoft WorkLab — Work Trend Index: Agents, human agency, and the opportunity for every organization — https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization
OWASP GenAI Security Project — LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
OWASP Cheat Sheet Series — AI Agent Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
OWASP — Lies-in-the-Loop — https://owasp.org/www-community/attacks/Lies_in_the_Loop
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 8 月 24 日。

如何建立帶人工批准的 AI 工作流程：分開提案與執行，並防範偽造審批