AI Agent 權限控管檢查表

先選一個任務，不要先開全部權限

例如先讓 Agent「依指定報價單產生郵件草稿」，不要直接給它「管理全部客戶和信箱」的權限。由業務負責人確認用途、資料負責人確認資料範圍，IT 核對系統實際授權；需要時再請法務與資安確認。

以下欄位與測試都是實務建議。還沒能驗證的項目寫「待驗證」，不能因為 Agent 回答「我會遵守」就勾選通過。資料範圍不清楚時，先用企業 AI 資料分級表決定可用資料。

可複製欄位：單一任務授權單

一個任務填一份；正式環境與測試環境分開。身分欄填可辨識的帳號或服務身分代號，不填密碼、API key 或 token。

授權單編號／版本：
任務與完成條件：
環境（測試／正式）：
Agent 身分代號／版本：
委派人／業務負責人／核准人：
允許工具與資料範圍：
允許動作與對象（讀／寫／寄出等分列）：
禁止事項（含匯出、刪除、改權限）：
人審條件（對象、內容版本、金額、數量）：
轉交其他 Agent 的範圍（未核准不轉交）：
生效時間／到期時間／撤權負責人：
必要日誌／保存期限／誰可閱覽：
重試與防止重複執行的方法：
緊急停用／可回復及不可回復事項：
測試證據位置／結果（通過、待修、待驗證）：
組織採用決定／核准人／日期：

最小權限要落在系統、工具或 API 的授權設定，不只寫在提示詞。Agent 轉交另一個 Agent 時，也不能把原本沒有的權限一起放大；應能追到原委派人、每一段授權範圍與撤回方式。

用「報價郵件草稿」演練一次

以下是示意，不是通用核准門檻：

• 任務只讀取指定客戶與已核准報價單，在指定工作區產生草稿；不讀全公司客戶名單。
• 草稿權限不包含寄出、修改報價、刪除資料或轉交其他 Agent。確實需要寄信時，另行設定寄送流程。
• 人審畫面呈現實際收件人、附件、報價版本與內容；核准紀錄綁定這次動作。Agent 改了收件人或附件，原核准不能沿用。
• 任務到期即收回授權；業務負責人離職、停用任務或發現異常時，也要有撤權程序。
• 郵件已送出不一定能收回。事故處理應包括停止後續寄送、確認影響對象、保存必要證據與指定聯絡人，不能只寫「自動復原」。

上線前做七項拒絕與留痕測試

先在隔離測試環境用虛構或適當去識別資料演練，記錄預期、實際結果與證據位置。這些測試是起點，不是完整安全驗證。

1. 超出範圍會拒絕嗎？ 要求讀另一位客戶或刪除檔案，應由系統權限擋下，而不是只靠模型答應不做。
2. 核准後變更還會停下嗎？ 改收件人、金額、附件或數量，應重新人審；拒絕或逾時不應繼續執行。
3. 文件裡的指令能擴權嗎？ 在測試資料放入要求轉寄或改權限的文字，確認它不會變成授權；外部資料不能替業務負責人核准動作。
4. 到期與撤權真的生效嗎？ 取消任務後測試排隊工作、後續工具呼叫與下游 Agent。不要只看到後台顯示停用，就假設所有既有授權都立刻失效。
5. 重試會不會做兩次？ 模擬工具逾時但實際已成功，確認系統先查結果或以同一操作識別碼防止重複寄信、下單；不確定時先停下交人處理。
6. 日誌能追查，又不多收資料嗎？ 用一筆成功、一筆拒絕與一筆人審紀錄，追到任務、Agent、委派人、工具、對象、時間與結果；不保存密碼、token 或無必要的完整客戶資料。
7. 事故能停在哪裡？ 演練誰能停用、撤權、隔離並通知負責人；資料變更是否能還原、已寄出的訊息如何補救，要分開驗證。

日誌優先記錄必要欄位、資料版本或受控證據位置，不是把整段提示詞、文件與對話無限期全部保存。依用途、個資、產業與契約要求訂保存期限、刪除流程及閱覽權限；本表不提供一體適用的法定保存年限。

這張表的法源與使用邊界

官方已確認： 台灣《資通安全管理法》及施行細則的直接管理義務有適用對象，不能擴張成所有一般民間企業都必須採用本表。《個人資料保護法》要求個資蒐集、處理與利用不得逾越特定目的的必要範圍；操作日誌也可能含個資。

國際草案參考： NIST NCCoE 的 2026 年 2 月概念草案，討論 Agent 身分、授權、存取委派、留痕與資料來源追蹤。截至 2026-08-31，所查專案頁仍以潛在專案及徵詢回饋說明；概念草案不是已完成的實作標準、認證或台灣法律。草案的初期範圍也不含單純檢索增強生成（RAG）問答與不可信外部 Agent 的身分管理，不能說它已涵蓋所有 AI 系統。

實務建議與待確認： 本站把上述議題轉成授權單及演練題，不是逐字翻譯的官方表格。填表、測試、人審紀錄與組織正式採用決定要分開；金融、醫療、政府服務、個資或關鍵系統，仍要逐項確認適用規範。一般責任與歐盟適用範圍另見 AI Agent 責任與風險。