AI Agent 導入不是只接模型：企業先補的 4 個資料與權限治理邊界
企業開始把 AI agent 接到搜尋、客服、工單與內部系統，真正需要先處理的通常不是模型大小，而是 agent 能看什麼、能替誰做什麼，以及出錯後能不能追得回來。
AWS Bedrock AgentCore Web Search 與 Google ADK（Agent Development Kit）的近期更新，讓即時資料、跨語言 multi-agent，以及 on-device 與 cloud 的分工更容易落地；但連線越方便，資料外送與權限失控的風險也越容易被忽略。
在讓 AI agent 正式進入生產環境前，建議企業團隊先補齊以下 4 個資料與權限治理邊界：
1. 先定義可查資料，不要讓搜尋變成無邊界外送
導入前把資料分成公開、內部、機密與受法規保護四層，為每層設定可用工具、來源與保存期限。
買方要問：搜尋請求與回應是否留存？能否看到資料來源？敏感欄位能否遮罩？這些能力比單純比較模型準確率，更能直接影響日後的稽核成本與法規合規性。
2. 權限要綁工作，不要直接綁人
agent 不應拿到長期有效、橫跨所有系統的管理員憑證。按任務建立最小權限（Least Privilege），例如只能讀指定知識庫、建立草稿工單，或提出付款申請但不能核准。
每次呼叫工具都要有身分、目的、範圍與時效。multi-agent 協作也應使用獨立身分，避免一次 prompt 誘導沿著信任鏈擴大影響。如需了解多平台環境下的身分控管與權限到期，可以參考我們這篇關於 AI 多平台稽核與權限治理 的實務建議。
3. 把 on-device 與 cloud 分工寫進規則
可在裝置端完成的分類、遮罩或初步判斷，應先在本地處理；需要大模型或跨來源彙整時，再送出已降敏內容。
企業要把哪些資料不得外送、哪些工具只能在內網呼叫寫成可檢查政策，而不是依賴開發者記憶，這也讓部署與維運責任更容易估算。針對已佈局邊緣運算或託管服務的架構，建議延伸閱讀 AI Agent 邊緣資安治理 的 4 個核心關卡。
4. 每個決策都要能回放與收回
agent 的答案、引用來源、工具呼叫、使用者身分與最終動作，都應留下可稽核紀錄；高風險操作要有人確認（Human-in-the-Loop）。
還要驗證撤銷機制：停用 token 後能否立即阻斷？錯誤規則能否回滾？日誌能否串到既有 SOC？否則出了問題只能人工翻紀錄通靈。
買方怎麼判斷方案是否適合
用一個真實流程驗證：讓 agent 查資料、呼叫工具、交給另一個 agent，再執行需核准的動作，觀察它能否記錄來源與權限、阻擋越權，並在撤銷後立即失效。想建立具體的測試機制，可搭配 提示詞管理與 AI 治理 4 步驟 一起進行團隊盤點。
若已有 Penta Security WAF，可先保護對外 API 與 Web 入口，再搭配 Cloudbric WAF、OSecure 或弱點掃描補上外部暴露、郵件與弱點治理。重點不是一次買齊，而是先收斂最危險的資料流與工具權限。