AI Agent Kill Switch 怎麼設計？緊急停止與恢復驗收
AI Agent 緊急停止的正確做法，不是只把模型程序關掉，而是讓系統能同時拒絕新任務、阻止高風險工具呼叫、撤銷可用憑證、隔離未完成工作，並留下可復原的狀態與稽核紀錄。如果只能 kill process，背景佇列、下游 API 或已簽發的權杖仍可能繼續動作；如果停完無法判斷哪些操作已成功，恢復時又可能重複扣款、寄信或改資料。可上線的停止機制必須回答三件事：誰能停、停下後哪些能力真的失效、由誰根據什麼證據恢復。
先畫出停止邊界，而不是先做一顆紅按鈕
Microsoft 對自主 Agent 的安全建議，把「可靠、系統層級、可立即暫停或停止」列為人類監督的一部分；NIST 的生成式 AI 風險管理文件也要求建立必要時可停用系統的協定。兩者都沒有規定一套適合所有產品的固定秒數，因為客服草稿、付款代理與基礎設施代理的影響範圍完全不同。團隊應先列出 Agent 能觸及的每個資源：模型執行器、工作佇列、工具閘道、OAuth 權杖、服務帳號、資料庫交易、通知通道與長期記憶，再定義停止邊界。
一個實用判斷是：若執行器停掉後，任何外部系統仍能接受先前由 Agent 排出的寫入，就代表停止邊界還沒封閉。若只是低風險讀取失敗，未必需要全站關閉；可先凍結特定工具、租戶或工作類型，減少不必要的服務中斷。
五層 Kill Switch 矩陣：每層都有不同失效模式
以下矩陣是本文依官方控制原則整理的實作分層。它不是單一框架的內建功能，而是一份用來找缺口的設計檢查表。
| 層級 | 停止動作 | 必留證據 | 只做這層會漏掉什麼 |
|---|---|---|---|
| 入口 | 關閉新 session、新任務與排程觸發 | 停用時間、操作者、規則版本 | 已在佇列與執行中的任務 |
| 編排 | 取消或暫停 run，凍結 handoff 與重試 | run ID、最後狀態、待處理 tool call | 已送往下游的請求 |
| 工具 | 在工具閘道 deny 高風險動作 | tool、參數摘要、拒絕理由 | 繞過閘道的直連憑證 |
| 身分 | 撤銷權杖、服務帳號或細分權限 | credential ID、撤銷回應、作用範圍 | 已完成但尚未對帳的副作用 |
| 資料與復原 | 隔離未完成交易、保存 checkpoint 與事件快照 | 事件序列、交易狀態、受影響資源 | 沒有人工判斷就自動重播的風險 |
OWASP 將過度功能、過度權限與過度自主列為 Excessive Agency 的根因，並建議縮小工具功能與權限、讓下游系統完整執行授權檢查、對高衝擊動作設人工核准。這表示 Kill Switch 不能只放在 LLM prompt 或編排器裡；真正的拒絕必須發生在模型無法改寫的政策層與下游授權層。
把高風險核准放在副作用之前
緊急停止是事故控制，不能代替平時的人工核准。刪除資料、付款、公開發布、寄出大量訊息、變更權限與執行任意程式碼等不可逆或高衝擊操作，應在工具真正執行前中斷，而不是完成後才通知。OpenAI Agents SDK 的 Human-in-the-loop 流程示範了這個模式：工具宣告需核准，run 產生 interruption，應用程式保存 RunState，人工 approve 或 reject 後才從原本的頂層 run 恢復。
核准畫面不要只顯示 Agent 生成的自然語言摘要。至少由可信任應用層直接呈現工具名稱、目標資源、結構化參數、預期副作用、請求者身分與有效期限。核准應綁定單一 call ID 與參數雜湊；若參數在等待期間改變，就重新送審。跨 MCP server 的工具也要把 server 身分納入核准鍵，避免同名工具共用錯誤授權。
事故發生時，停止順序要能封住新的副作用
- 宣告事件並鎖定範圍：記錄觸發訊號、租戶、Agent 版本、工具與時間，不讓「先全部重啟」抹掉線索。
- 拒絕新工作：入口改為 fail closed；排程器停止派送，重試政策暫停，避免故障期間持續放大。
- 阻斷高風險工具：由獨立政策閘道 deny 寫入、刪除、付款、發布或權限變更。不要期待模型自行遵守停止提示。
- 撤銷身分能力：停用短期權杖、服務帳號或特定 scope，並向下游服務確認拒絕已生效。
- 封存狀態：保存 run、message、tool call、回應碼與交易識別碼；敏感內容依資料政策遮罩與控管存取。
- 對帳外部副作用：逐項確認「未開始、進行中、已成功、已失敗、未知」，未知不能直接重播。
停止命令本身也會失敗，因此控制通道不應依賴同一個 Agent、同一套模型推理或同一個易受影響的工作佇列。至少要能由獨立管理身分呼叫，而且拒絕規則應在逾時或控制面失聯時採取團隊預先定義的安全預設。
恢復不是把開關切回 ON
恢復前先建立新的執行範圍，而不是沿用事故前所有權限。建議依序完成：修正或隔離根因、輪替受影響憑證、重新計算允許的工具清單、由非原操作者覆核、先以唯讀或 shadow mode 執行，再逐步開放可逆寫入。任何待重播工作都要有 idempotency key，並查詢下游交易狀態；無法證明尚未成功的付款、寄送或刪除請求，必須交給人工處理。
對可序列化的 Agent run，checkpoint 只代表能繼續，不代表應該繼續。OpenAI 文件提醒長時間等待核准時要保存 Agent 定義或 SDK 版本標記；同樣地，恢復前也應比對工具 schema、政策版本與憑證範圍。版本不相容時建立新 run，並把舊 run 保留為事件證據。
用故障演練驗收：看證據，不看按鈕有沒有變灰
上線前可建立一個不接真實客戶資料的測試租戶，注入「連續工具呼叫、未授權寫入、下游逾時、核准人不回應、停止控制面失聯」等情境。以下欄位可直接變成演練紀錄；門檻數字由團隊依風險與系統能力制定，不把任意秒數冒充產業標準。
- 觸發：哪個可觀測訊號啟動手動或自動停止，是否能定位到租戶、run 與工具。
- 阻斷：停止後送入新的高風險 tool call，應收到可辨識的拒絕；下游稽核也不能出現成功寫入。
- 撤銷：使用事故前權杖直接呼叫下游 API，確認授權層拒絕，而非只由前端隱藏按鈕。
- 保存：能否還原停止前最後一個已確認成功的副作用，以及所有狀態未知的請求。
- 通知：值班、資安、產品與受影響資料負責人是否收到同一事件識別碼與處置狀態。
- 恢復：經雙人覆核後，只開放測試範圍；冪等重播不產生第二次副作用，異常時能再次停止。
若任何一項只能靠讀取聊天紀錄猜測，就不算通過。驗收證據應來自政策閘道、身分系統、下游 API 與事件儲存，而不是模型對自己行為的說明。需要延伸測試輸入與誤攔率時，可接著閱讀LLM Guardrails 紅隊與上線驗收清單；想縮小工具供應鏈風險，則參考MCP Server 安全漏洞防護。所有 AI 工程主題也整理在AI 工程實戰主題樞紐。
三個最常讓 Kill Switch 失效的設計
只停模型、不停工具：已派送任務與有效權杖仍可完成副作用。把核准交給同一個 Agent：遭提示注入或規則錯誤時，Agent 可能同時產生動作與「核准理由」。沒有恢復對帳：服務重啟後盲目重試，將一次事故變成重複交易。解法不是增加更長的 system prompt，而是把拒絕、身分、記錄與恢復責任放到獨立且可測試的系統元件。
這套矩陣能驗證的是技術控制是否存在、是否阻斷、是否留下證據；它不能單獨證明法規合規，也不能保證沒有未知攻擊。涉及個資、金融、醫療或關鍵基礎設施時，仍需由組織的法務、資安與業務責任人依實際資料流與風險完成審查。
參考資料
- Microsoft Learn：Reduce autonomous agentic AI risk（人類監督、系統層級停止、最小權限與稽核）
- OWASP GenAI Security Project：LLM06 Excessive Agency（最小工具功能、下游授權、高風險人工核准與監控）
- OpenAI Agents SDK：Human-in-the-loop（工具核准、暫停、狀態保存、拒絕與恢復流程）
- NIST AI 600-1：Generative AI Profile（系統停用協定、事件應變與人類監督責任）