業務請 AI 整理客戶續約資料，看起來只是一句簡單指令。背後卻可能讀取 CRM、查閱合約，再建立報價草稿。如果每一步都使用同一組管理員帳號，系統雖然知道「有程式來過」，卻很難回答：這次是替哪位同事辦事？客戶資料原本是否在他的權限內？他調職後，尚未完成的任務還能繼續嗎？
近期訊號：代理也需要自己的身分
HashiCorp 在 2026 年 9 月 1 日宣布 Vault Enterprise 的代理身分管理能力正式推出；Oracle 9 月 10 日介紹的 Integration MCP Gateway，則將身分與政策控制列為 26.10 版本規劃的一部分。兩則公告反映出相近方向：企業開始把代理接入既有權限制度。以下是米亞科技的整合設計建議，並非所有平台都已具備的功能清單。
先分清楚三個角色
發起工作的人、執行工作的代理，以及真正存取 ERP 或 CRM 的系統帳號，可能是三個不同角色。不能因為代理能登入，就推定它能代替任何人操作。每次執行都應連回發起者與任務；無人值守的排程，則要有明確的服務身分、負責人與適用範圍，不宜借用某位員工的永久登入狀態。
授權要跟著任務走
一個實用起點，是把授權寫成具體範圍：替哪個部門、處理哪些客戶、可以讀取哪些欄位、能建立草稿還是能正式送出，以及何時到期。後端應取使用者權限、代理權限與這次任務範圍的交集。把「只處理這個客戶」寫在提示詞中有助於理解，但真正的限制仍須由查詢與寫入介面執行。
用續約準備看懂差別
假設設備服務商請代理準備甲客戶的續約資料，這是示意情境，不是米亞科技已交付的案例。代理可讀取該客戶合約與授權範圍內的設備紀錄，依既有計價程式取得金額，再整理續約草稿。它不因此取得乙客戶資料，也不能自行變更折扣或寄出承諾。主管核准時，應看到實際草稿、對象與金額；若核准後內容改變，就需重新檢查，而不是沿用一個籠統的「同意」。
能給權限，也要能收回
人員離職、案件取消或核准逾期時，正在排隊的代理工作也需要停止。短效憑證可縮短暴露時間，卻不等於立即撤權：系統仍應在重要操作前重新檢查授權，並處理已排程工作、快取與下游連線。若資料已送出或正式寫入，撤權不會自動還原結果，必須另有取消、補正或人工處理流程。
讓紀錄說得出前因後果
日誌至少要串起任務編號、發起者、代理身分、使用工具、授權範圍、核准版本與執行結果。憑證與密碼不應進入模型對話或一般日誌。這些紀錄的價值不只是事後查責，也能讓客服或主管知道工作停在哪一步、由誰接手，避免只看到一段「執行失敗」。
第一個驗收，不妨測試它何時不能做
先挑一條查詢加草稿流程，測試跨客戶查詢、權限撤銷、核准後改價與排程途中停用帳號。檢查是否真的阻擋操作、是否留下原因，以及人工能否承接。除了草稿準備時間，也記錄錯誤授權攔截與撤權生效時間，才能看出便利背後是否仍保有控制。
米亞科技的觀點：把委託關係接完整
企業導入代理時，網站、APP、知識庫與 ERP 的連接數只是起點。更值得先做好的，是讓每個動作都能回答「誰委託、做到哪裡、何時失效」。從一條可驗證的授權鏈開始，企業才能逐步擴大 AI 的工作範圍，同時保留原有管理制度的判斷與責任。