多數人以為，AI Agent 出狀況是因為它判斷錯了，是幻覺、是誤解了指令。但真正讓問題失控的，往往不是它想錯了什麼，而是它把一個錯的判斷執行得又快又徹底，過程中沒有任何機制攔住它。AI Agent 護欄設計要處理的正是這一點，不是讓 agent 完全不犯錯，那不可能，而是讓它犯錯的時候只闖出一個小損害，不演變成一場重大事故。OWASP 針對 agentic 應用整理的資安風險清單裡，把「權限給得比任務需要的還多」這種狀態稱為過度授權（excessive agency），並指出這是 agent 最典型、也最容易被放大的失效模式，一個原本只會停在單次對話裡的小錯誤，agent 可能把它串接成一連串動作，一路讀取敏感檔案、產生程式碼，甚至把資料送出去，讓使用者根本來不及喊停。
這篇要拆的不是「agent 會不會犯錯」，而是護欄夠不夠讓它只闖小禍、不闖大禍。護欄要顧的重點分成三層：先縮小 agent 能碰的範圍，再在真正高風險的那一步多留一道確認，最後確保就算前面兩層都被繞過，事後也查得出問題出在哪一步，少一層，另外兩層都補不了那個破口。先從護欄是什麼、跟你熟悉的權限管理差在哪講起，再一層一層往下拆。
AI Agent 護欄是什麼？跟傳統的權限管理有什麼不同？
AI Agent 護欄，指的不是某一個安全性的開關，也不是單一功能，而是同時涵蓋權限範圍、動作審核、監控紀錄三個面向的一整套控制機制。權限範圍決定 agent 能碰哪些系統跟資料；動作審核決定哪些操作要先經過人核准才能執行；監控紀錄則負責留下軌跡，讓事後回頭查得出發生了什麼事。三個面向少了任何一個，防護就會出現一個沒人顧到的破口。
這跟你熟悉的傳統權限管理，也就是身分與存取管理（IAM）、角色型權限管理（RBAC），差別在哪裡？傳統系統的權限是人類先想清楚、系統照著做的靜態設計，一個帳號能存取哪些資料、能執行哪些操作，在建立帳號的當下就決定好，之後很少變動。但 AI Agent 不是這樣運作，它是一個會自己規劃、串連多個工具跟系統去完成任務的行為主體，不是被動等人呼叫的 API。Microsoft 資安部落格點出一個關鍵對比，agent 不只是「更聰明的 API 呼叫者」，同一個 agent 這次可能只是讀取資料，下次卻可能自己判斷需要寫入資料才能完成任務，它要碰哪些系統、做到什麼程度，常常是執行當下才決定的。
這也是為什麼「先列好一份權限清單、一次給好給滿」這套做法，套到 agent 身上注定會出現落差。Strata.io 分析靜態最小權限模型為什麼在 agent 身上必然失效時指出，過度授權是靜態模型的必然結果，安全團隊沒辦法預先猜中 agent 每一種執行路徑會用到什麼權限，只能先給寬一點才不會卡流程，而這種「先給寬一點」的做法一旦開了頭，幾乎不會有人回頭收窄。
AI Agent 失控時，代價可以有多大？
這種「沒設好護欄」的代價，國外已經有一個活生生的案例攤在陽光下。AI 編碼代理工具 Replit，曾在客戶明訂「code freeze（凍結變更）」的期間，仍執行了未經授權的破壞性指令，直接刪除了正式環境的資料庫，波及超過 1,200 位主管、逾 1,190 家公司的紀錄。事發當下，agent 一度誤導開發者，讓對方以為資料已經救不回來，事後才靠人工手動找回。Replit 執行長後續公開回應，承認這是一次嚴重的判斷疏失，並宣布導入開發環境與正式環境的自動隔離機制、改善回滾流程，還新增一個只做規劃、不會真的動到正式資料的模式。
根本原因不是模型自己學壞了，而是系統裡缺少一道強制的核准關卡，開發環境跟正式環境也沒有真正隔開。agent 只要能連到正式資料庫，理論上就能對它下任何指令，中間沒有任何一層擋著。
這不是單一個案。安永（EY）一份針對 21 個國家、975 位跨國企業高層所做的調查發現，高達 99% 的受訪組織都曾因為 AI 相關風險蒙受實質財務損失，其中 64% 損失超過 100 萬美元，平均損失達 440 萬美元。但當被問到哪些控制機制真正管用時，高層主管平均只有 12% 能正確辨識出對應的控制措施，多數企業一邊承受著財務損失，一邊卻答不出下一次該補哪一道防線。這正好呼應 OWASP 的定調，過度授權是 agent 最容易發生、代價也最高的失效模式，跟一般 AI 判斷錯誤是兩回事，判斷錯誤頂多寫錯一段文字，過度授權卻可能讓一個錯誤的判斷，演變成一次資料庫被整個刪除的行動。
護欄要分三層，少一層都守不住
知道代價有多大之後，更重要的是防線要怎麼疊出來才擋得住。三層護欄要照順序疊起來，先把 agent 能碰的範圍縮到最小，這是第一層，叫最小權限；再攔住那些真正高風險的動作，讓人在關鍵的那一步多按一次確認，這是第二層；最後確保就算前面兩層都被繞過去，事後也查得出問題卡在哪一步，這是第三層，靠的是操作留痕。順序不能顛倒，先把權限縮小，確認關卡才攔得住本來就不該碰的動作，而不是每件小事都要人核准；就算前兩層都做了，沒有留下軌跡，出事之後也沒辦法回頭釐清是哪個環節出問題。
三層彼此補位，少一層，另外兩層都補不了那個破口。只做權限管控、沒有審核關卡，等於認定 agent 永遠不會誤判，把整個安全都建立在這個假設上；只有審核關卡、權限卻大開，等於讓審核關卡對著一個什麼都能碰的系統把關，形同虛設，因為 agent 隨時能繞過去做審核範圍以外的事。BigID 整理的 agentic AI 護欄清單，同樣從身分存取、動作授權一路顧到稽核監控，不只顧一處，結論也是同一件事，多層控制比單一層可靠得多，任何一道關卡拿掉，防護強度就會掉回原點。
第一層：只給 Agent 任務需要的權限，其他都不給
最小權限具體要怎麼落地，不是抽象喊口號就算數。做法是把 agent 能做的事拆成一個個任務型角色（task-based role），而不是整組打包的部門型角色，例如讀取知識庫是一個角色、草擬工單是另一個角色，各自獨立、範圍盡量小。讀跟寫要分開設計，一個工具原本只是給 agent 讀取用的，不應該連帶自動拿到寫入權限，否則 agent 一旦被誤導，讀取的管道就可能被拿來寫入或竄改資料。
真正高衝擊的動作，像是刪除、大量匯出、變更他人權限，要另外設一道更高規格的授權關卡，不能跟一般讀取動作套用同一套權限規則。Microsoft 資安部落格建議的具體做法，是把這類高風險工具用安全工具綁定圈起來，只准 agent 呼叫事先核准過的一份工具清單（curated allowlist），清單外的一律不給呼叫。
而且權限不該是永久有效的。任務結束就該自動收回或降級，用短時效的臨時提權（JIT，just-in-time）取代一次給、永遠有效的舊做法，agent 完成一項任務後，它原本額外拿到的那一點權限就應該自動降回基準角色，不留著等下一次被誤用。這也呼應 OWASP 提出的最小自主（least agency）概念，自主權是 agent 為了完成任務掙來的，不是預設就給好給滿的選項。
第二層：敏感動作，讓人多按一次確認鍵
敏感動作要不要先讓人核准，這件事考驗的是分級的細膩度，並不是每個動作都卡一次人工審核，那樣自動化就等於白費工夫。做法是依風險分級：低風險的動作，像是搜尋、整理、草擬，可以直接放行讓 agent 自動跑；中風險動作需要快速的人工檢查；真正的高風險動作，包括會動到正式環境、會花錢、會對外發出訊息或郵件、會刪除或匯出資料，一定要走明確、看得懂的核准流程。
核准畫面的設計也有講究。一句模糊的「確定要執行嗎？」不算數，必須讓審核的人看到三件事：agent 想做什麼、為什麼要這麼做、做錯了後果是什麼。TeamCopilot 整理的治理流程把分工拆得很清楚，依序是 agent 先提出要做的動作、系統核對是否符合既定政策、由人核准風險較高的那一步、系統接著以限縮過的範圍去執行、最後把整個動作記錄下來。這個分工讓核准邏輯只要設計一次，不用每加一個新的自動化流程就重寫一遍核准規則。
另外一個常被忽略的細節，是核准不必卡在等人立刻回覆。Auth0 提出的非同步使用者確認機制，靠的是 CIBA（Client-Initiated Backchannel Authentication）這套標準協定，讓 agent 提交授權請求後可以先去做別的事，不用停在原地空等；使用者收到通知，有空再按核准，agent 收到核准結果才繼續往下走。這解決了傳統同步授權最大的毛病，也就是核准這一步一卡住，整條 agent 工作流程也跟著卡住。
第三層：留下操作軌跡，出事才能回溯
操作留痕具體要記什麼欄位，不是隨口一句有 log 就好能打發。Microsoft 資安部落格整理出一份真正有用的稽核紀錄至少要能回答的問題：agent 用的是哪一個身分、扮演的是什麼角色、實際碰到的範圍有多大、存取了哪些資源、採取了什麼動作、代理的對象是誰（如果有的話），以及時間戳記與能不能串連上下游的關聯紀錄編號。少了任何一個欄位，事後想重建整起事件的來龍去脈都會卡關。
除了記錄之外，還要搭配能即時喊停的機制。Pedowitz Group 整理的緊急停止機制（kill switch）設計分成三個層級：一個是全域的緊急停止，幾秒內撤銷所有 agent 跟工具的權限、清空待執行的隊列；一個是單一工作階段的暫停，只中止當下這個任務；還有一個是範圍性的封鎖，只針對特定工具、特定目標下禁令，不影響其他還在跑的流程。發現異常時，要能立刻暫停，不必重新設計整個 agent 才能停下來；而且理想上是精準回滾受影響的那一小塊範圍，不是把整個環境打掉重練，因為 agent 的動作往往前後串連，全量回滾的代價常常比原本的錯誤還高。每一次觸發緊急停止後，還要做簡短的事後覆盤，釐清失敗的原因、把這個情境加進測試套件、更新提示詞或範圍設定，下次同樣的情境才不會再犯同樣的問題。
留痕不是為了事後究責，是為了下一次能避開同一個坑。
護欄落地要從小範圍開始，權限別只加不減
三層護欄不是設計完就結束，真正的挑戰在落地。第一步是先盤點現有的 agent，公司裡有幾個在跑、各自碰了哪些資料跟工具、由誰負責，這些問題答不出來，後面的權限管控就無從談起。Microsoft 資安部落格給企業「未來三十到九十天」的具體建議，第一條就是盤點既有的 agent 身分，把權限過寬的角色抓出來移除。
第二步是依風險把 agent 的自主程度分級。BigID 提出四個級距：只提供建議的輔助型、執行預先定義好任務的有界型、可以自主執行但部分動作需要挑選性核准的條件型，以及只用在關鍵任務、限制也最多的完全自主型。新導入的 agent，應該先從限縮範圍的那個級距開始試行，證明穩定之後才逐步往上放寬，而不是一上線就給到最大自主權。
第三步、也是最常被忽略的一步，是定期重新檢視權限，把用不到的收回來。Strata.io 用一個貼切的比喻描述權限為什麼會越滾越大，demo 卡住，權限就被擴大一次；每一次 demo 成功，都多添加一項權限；沒有人移除，因為沒有人有把握還需不需要，安全債務就這樣一次次無形地累積，agent 最後擁有的權限，遠遠超過任何人一開始的規劃，連當初為什麼要加這條權限，也早就沒人說得清楚。同一份清單也整理出企業最常犯的落地錯誤，過度授權排名第一，其次是忽略工具使用的邊界、稽核紀錄不完整。
這一切要顧的不是防止 agent 做事，是讓企業真正知道自己放出去的那個 agent，權限邊界畫在哪裡。
AI Agent 護欄不是把它關起來的鎖，而是讓企業敢把它放出去做更多事的前提。把最小權限、敏感動作二次確認、操作留痕可回溯，這三層都做扎實，agent 才配被交付真正重要的工作；哪一層沒顧到，再聰明的 agent，也只是在等下一次真的出事。