AI Agent 的權限不能只寫在 Prompt 裡。企業需要為 Agent 建立可識別身份，依使用者、任務與當下情境授予最小權限，並在 Tool 執行層再次驗證，才能避免模型被誘導或誤判後越權操作。
權限要分成四層
- 身份：使用者、Agent 與服務帳號各自可追溯。
- 資料：限制品牌、區域、欄位、資料列與敏感度。
- 工具：區分讀取、建議、受限寫入與管理操作。
- 動作：依金額、對象與風險設定人工確認。
NIST 對最小權限的定義，是只提供完成指定功能所需的最少資源與授權；OWASP 的 Excessive Agency 指引進一步指出，Agent 的功能、權限或自主程度過大，都會放大不當操作風險。NIST 提供通用原則，OWASP 提供應用安全風險分類；兩者都需轉換成企業自身的 IAM 與政策。
實務情境框：會員分析 Agent 可能需要查看彙總回購率，但不代表它能匯出電話與 Email；能建立「建議名單」也不代表可以直接發送訊息。把這些能力拆成不同 Tool，邊界才可驗證。
為什麼 Prompt 限制不夠？
Prompt 可能被使用者輸入、文件內容或模型錯誤影響。真正授權應在應用與資料層執行：即使模型要求使用未授權 Tool，系統仍必須拒絕。
建議的操作流程
- 解析使用者身份、角色與當前用途。
- 建立僅含必要 Tool 的工作階段。
- 每次 Tool 呼叫重新檢查參數與權限。
- 高風險寫入顯示影響範圍並等待確認。
- 記錄意圖、政策判斷、Tool 與結果。
- 定期撤銷不用的授權與憑證。
LINKY REASON 可在 Agent 與 Tool 之間建立 Governance 與 Evaluation；實際授權仍需整合企業 IAM、資料政策與系統權限。
結論
安全的 Agent 不是「相信它會守規則」，而是讓它即使判斷錯也只能在受控範圍內行動。身份、最小權限、執行時驗證、人工確認與稽核缺一不可。
常見問題 FAQ
共用一個服務帳號比較方便嗎？
方便但難以追責，應盡量保留使用者與 Agent 身份，並採短效、限縮憑證。
只讀 Agent 就沒有風險嗎？
仍可能洩漏敏感資訊或大量擷取資料，讀取範圍也需限制。
參考資料與延伸閱讀
以下資料用於支持最小權限與 Agent 過度授權風險；皆屬通用框架，實際控制仍需依企業系統設計。查閱日期：2026 年 9 月 16 日。
- NIST｜Least privilege definition：最小權限的正式定義。
- NIST｜AI Risk Management Framework 1.0：AI 風險治理的生命週期框架。
- OWASP｜Excessive Agency：Agent 功能、權限與自主性過大的安全風險。