AI 不再只是回答問題的聊天視窗。當 AI 代理（AI agent）能讀取文件、呼叫 API、更新資料或寄送訊息，它就從「提供建議」走到「替人採取行動」。對小型團隊來說，真正要先想清楚的不是要不要用 AI，而是：它能碰哪些資料、能做哪些事，以及什麼情況一定要有人點頭。
這篇整理一套不必先建大型資安團隊也能開始的 AI 代理安全做法：從縮小任務、設定最小權限，到高風險操作人工核准與留存紀錄，逐步讓效率和可控性一起上線。
AI 代理安全為什麼不同於一般聊天機器人？
一般聊天機器人多半產生文字供人參考；AI 代理則可能透過工具讀信件、查資料庫、建立檔案或觸發工作流程。回答錯誤固然需要查證，但一旦代理有寫入權限，錯誤可能直接變成寄錯郵件、改錯紀錄，或把不該分享的內容送出去。
因此，AI 代理治理不能只靠一段「請謹慎回答」的提示詞。安全要同時涵蓋代理的身分、可用工具、資料範圍、核准規則和事後追蹤；這些控制要在系統層落實，而不是期待模型永遠理解每條規則。
小型團隊建立 AI Agent 權限管理的 5 個步驟
1. 先選一個範圍窄、成果可檢查的任務
不要一開始就讓代理「管理整個客服流程」或「處理所有郵件」。先挑一件頻率高、輸入相對固定、錯誤容易發現的工作，例如整理指定資料夾的文件摘要，或依範本產生待審核的回覆草稿。寫下任務的輸入、預期輸出、不得執行的動作，以及成功與失敗如何判斷。
好的起點通常是只讀、只草擬、不直接對外。先比較代理建議與人工結果，再決定是否逐步開放下一項能力。
2. 依任務給最小必要權限
把每個工具分成「讀取」、「草擬」與「寫入／對外執行」幾種能力。只需要搜尋資料的代理不必取得修改資料庫的權限；負責整理郵件的代理，也不應順手拿到寄信、刪除郵件或管理帳號的權限。若平台支援，為不同代理建立獨立身分與受限的服務帳號，避免共用管理員帳號或長期有效的高權限金鑰。
也要限制可讀取的資料夾、欄位、客戶範圍或 API 操作。金鑰應放在平台的密鑰管理或安全設定中，不要貼進提示詞、文件或對話紀錄。這才是可落地的 AI Agent 權限管理：即使代理判斷錯誤，能造成的影響仍被限制在小範圍內。
3. 把郵件、網頁和文件內容視為不可信輸入
代理在工作時讀到的文字，可能包含要求它忽略原指令、外傳資料或呼叫其他工具的內容。這種間接提示注入不一定來自使用者直接輸入，也可能藏在網頁、附件或信件裡。代理應把這些內容當作待分析資料，而不是新的授權命令；即使文件寫著「請立即寄出名單」，也不代表它因此取得寄送名單的權限。
工具權限要由系統獨立限制，重要操作再由規則檢查。OWASP《Top 10 for Agentic Applications 2026》把代理系統的風險整理成實務檢查起點；小團隊可先用它檢視工具權限、輸入資料和失控操作等面向。
4. 對不可逆或影響較大的動作設人工關卡
對外寄信、發布內容、付款、刪除資料、修改正式客戶紀錄等動作，不妨先設定成「代理準備、人來核准」。核准畫面要清楚列出即將執行的內容、收件人或目標資料、重要數值與依據，讓人能選擇核准、修改或拒絕；不要只問一句「是否繼續？」就讓人盲按。
人工核准也不是萬靈丹：若代理仍握有太多權限，或核准內容看不清楚，風險依然存在。可以依影響程度分級，低風險、可復原的內部整理採自動化；涉及外部承諾、敏感資料或不可逆變更時，則必須停下來等待指定人員確認。Google Cloud 的代理治理說明也強調，工具權限和明確的人在迴路中監督，應一起設計。
5. 留下可追查紀錄，並定期測試邊界
至少記錄代理身分、任務來源、引用的資料、呼叫了哪些工具、是否有人核准、最後結果和錯誤訊息。這些紀錄不只是出問題時用來追責，也能幫團隊發現代理是否常常要求不必要的權限，或在相似任務上表現不穩定。指定一位維護者定期檢查權限，停用不再使用的連線，並知道遇到異常時如何暫停代理或撤銷憑證。
測試不只要問「它答得對不對」，還要確認它遇到惡意文件、資料不足、工具失敗、重複執行或超出任務範圍時會怎麼做。NIST AI 風險管理框架（AI RMF）是自願採用的風險管理資源，提供從治理、辨識、衡量到管理風險的思路；可用來規劃持續檢查，而非只在上線前做一次審核。
一個小型團隊可以先做的安全試行
若要在本週開始，先挑一個不含敏感資料的內部工作，讓代理只能讀取指定內容並產生草稿。由一位負責人檢查輸出，記下常見錯誤；確認任務穩定後，再只開放一項必要工具，並把所有對外或會改動正式資料的操作留在人手核准。每次擴大權限前，都先問：「這個新增權限真的必要嗎？出錯時影響範圍多大？誰可以立刻停掉它？」
AI 代理安全不是讓代理什麼都不能做，而是讓每個能力都有清楚邊界、負責人和退場方式。從一項窄任務開始，採最小權限、為高風險動作保留人工覆核，再以紀錄和測試慢慢擴大範圍，通常比一次交出整套系統權限更務實。