企業 AI Agent 的權限必須由系統層的 RBAC、工具白名單與人工核准共同控制，不能只靠模型理解一段 Prompt。最小可行做法是先開放只讀工具，再逐步加入可建立與受控寫入，所有高風險動作都要能拒絕、追蹤與復原。
優創智能的企業 AI 導入與流程自動化若涉及 CRM、ERP、客服或報表，真正的交付物不只是一個會對話的 Agent，還包括角色矩陣、工具契約、測試集與交接文件。本文提供的是採購、PoC 與內部資安審查可使用的決策框架，正式權限仍須依企業政策設計。
企業 AI Agent 權限治理：先把動作列出來
AI Agent 能做什麼，必須拆成資源與動作
「客服 Agent」或「業務 Agent」不是權限定義。權限要落到資源、動作、範圍與條件，例如「只能讀取本人負責客戶的訂單狀態」，而不是籠統地寫「可以使用 CRM」。
| 動作級別 | 例子 | 建議預設 |
|---|---|---|
| Read | 讀取公開 FAQ、本人案件狀態 | 可自動執行，記錄來源 |
| Search | 在指定部門知識庫檢索 | 先做租戶與角色過濾 |
| Create | 建立工單、回電任務或草稿 | 欄位驗證，避免重複建立 |
| Update | 修改 CRM 聯絡資料 | 二次確認與變更日誌 |
| Approve | 核准折扣、退款或例外 | 不由同一個 Agent 自行完成 |
| Delete | 刪除資料、撤銷權限 | 預設停用，必要時全程人工 |
每個動作都要有明確的失敗狀態。工具回傳「沒有權限」時，Agent 應停止並提供安全的人工流程，不應換一個工具或改寫參數重試。
RBAC 角色矩陣怎麼開始？
先用最少角色建立矩陣，再隨業務增加。以下是通用起始範例：
| 角色 | 公開 FAQ | 本人客戶資料 | 全部客戶資料 | 折扣工具 | 退款工具 |
|---|---|---|---|---|---|
| 一般客服 Agent | 讀取 | 讀取 | 禁止 | 查詢 | 禁止 |
| 資深客服 Agent | 讀取 | 讀取／建單 | 指定範圍 | 查詢／申請 | 申請 |
| 主管核准人 | 讀取 | 讀取 | 指定範圍 | 核准 | 核准 |
| IT 維運 | 依需 | 不應讀取內容 | 系統診斷 | 禁止業務核准 | 禁止業務核准 |
矩陣不是文件裝飾。每一格都要能對應到真正的 API scope、資料庫 row-level filter 或工具端檢查，並在撤銷角色後實際測試權限是否立即生效。
AI Agent 工具呼叫的最小權限設計
Tool schema 應限制模型能傳什麼
工具輸入不要接受一個任意 JSON 或一段 SQL。應把欄位、型別、允許值、上限與必填條件寫成明確 schema，再於伺服器端重新驗證。
使用者身分與角色
→ 可用工具白名單
→ 資料範圍過濾
→ 輸入 schema 與規則驗證
→ 人工核准（高風險）
→ 帶請求識別碼執行
→ 記錄結果與回滾資訊
如果工具需要讀取大量資料才能回答，先問能否縮小範圍。最小權限也包含回傳欄位：客服只需要訂單狀態，不必取得完整地址、電話或付款資訊。
人工核准應該設在哪裡？
人工核准不是在聊天畫面加一個「確定」按鈕就完成。核准者要看見實際動作、目標資源、變更前後值、規則來源、有效期限與風險提示；核准結果要和原始請求 ID 綁定，避免被另一個請求重放。
以下情況通常應提高核准門檻：
- 會造成金錢、庫存或合約承諾的動作。
- 會接觸他人個資或跨租戶資料的動作。
- 會批次修改、刪除或發送外部訊息的動作。
- 例外政策、底價、退款與醫療相關內容。
- 無法在失敗後自動回滾的動作。
AI Agent 上線前的權限驗收清單
正常、越權與復原要一起測
| 測試情境 | 預期結果 | 證據 |
|---|---|---|
| 一般客服查詢本人案件 | 回傳最小必要欄位 | 請求 ID、角色、來源 |
| 試圖查詢他人案件 | 拒絕且不洩漏存在性 | 拒答與無敏感錯誤 |
| Agent 要求直接退款 | 轉核准或人工 | 未執行寫入 |
| Token 過期 | 停止操作並重新驗證 | 無匿名 fallback |
| 工具 timeout 後重試 | 依 idempotency 控制 | 沒有重複異動 |
| 核准後資料已被修改 | 重新檢查版本 | 不套用過期核准 |
| 撤銷角色後再次呼叫 | 伺服器端拒絕 | 權限變更時間 |
測試集要保存「應該發生什麼」與「實際發生什麼」。如果只有成功案例，團隊無法知道 Agent 在壓力、惡意輸入或資料錯誤時會不會越權。
日誌要能回答哪四個問題？
一次 Agent 操作至少要能回答：誰發起、Agent 看了什麼、呼叫了什麼、最後改變了什麼。若日誌只保存自然語言回答，就無法確認是否先查了錯誤租戶、是否呼叫過高風險工具，或是否因重試產生副作用。
敏感資料應依保存政策做遮罩或雜湊，但不能為了脫敏而刪掉事件關聯所需的請求 ID、工具名稱、結果狀態與版本資訊。
優創智能 AI Agent 導入時的交付範圍
詢問優創智能企業 AI 導入服務或流程自動化服務時，可以要求將以下內容列入 PoC：
- 角色與資料範圍矩陣，以及撤銷權限的處理方式。
- 每個工具的輸入 schema、白名單、錯誤狀態與 idempotency 設計。
- 高風險動作的核准畫面、核准者與版本檢查。
- 越權、Prompt Injection、Token 過期、timeout 與重放測試。
- 日誌欄位、保存期限、告警、回滾與退出交接。
如果團隊還沒有明確的資源 owner，先限制 Agent 做只讀搜尋與工單整理。權限一旦直接連到交易流程，治理成本就會從「回答品質」提升為「業務控制」，應在 PoC 階段把這個轉折說清楚。
相關推薦與延伸閱讀
- AI 客服 API 當機怎麼辦？Timeout、Retry、熔斷與人工降級標準：AI 客服遇到上游 API timeout、429 或 5xx 時，不能無限重試。本文整理 timeout、backoff、circuit breaker 的建
- 5 個行政自動化場景：會議、郵件、排程與報表驗收：AI 行政自動化怎麼做才有效？從會議摘要、郵件草稿、社群排程到費用及定期報表，整理五類行政自動化的輸入、人工覆核與驗收方式，不把工具設定完成當成效益保證。文中附
- ChatGPT 能讀 Chrome 分頁了：企業該開放哪些權限、哪些要先擋：OpenAI 於 2026 年 10 月 15 日升級 ChatGPT Chrome 擴充，Chat 可讀取已開啟的分頁，Work 可直接操作分頁送訊息、填表與