當 AI Agent 開始替員工查詢資料、更新系統紀錄或呼叫內部 API，企業的存取控管就不能只驗證「是哪位員工登入」。系統還必須辨識：是哪個 Agent 執行動作、它代表誰、被允許存取哪些資源，以及如何在任務結束或權限變更時撤銷授權。
若讓 Agent 共用員工帳號、長期服務帳號或未經治理的 API 金鑰，企業很難在事後釐清責任，也容易讓原本只供單一工作流程使用的憑證擴大權限。這也是 AI Agent 身分治理逐漸成為 IAM 架構一部分的原因。
JumpCloud 11 月更新：讓 Agent 以自己的身分代表使用者
JumpCloud 在 2026 年 11 月 4 日的官方更新中，宣布 Agent Delegated Access 進入私人預覽（Private Preview）。這項能力延伸既有 Agent Identities，讓 AI Agent 在代表終端使用者執行工作時，使用由 JumpCloud 管理的 Agent 身分進行驗證。初期情境鎖定自行建置 Agent 應用程式與內部 API 的客戶。
官方說明的流程包含身分權杖交換：系統可將可信任的使用者身分權杖，交換為代表該 Agent 代使用者行動的簽署權杖。管理員可啟用委派功能、選擇受信任的 OIDC 應用程式，並設定 Agent 可為哪些資源請求權杖的允許對象（Allowed Audiences）。官方也指出，Agent 可直接使用 JumpCloud 核發的權杖存取客戶自行管理的 API，不必讓這些 API 呼叫經過 AI Gateway。
需要特別注意，這項功能在該次更新中仍是私人預覽，不應視為已對所有客戶正式開放。企業應先向供應商確認預覽資格、支援條件、授權方式與正式上市時程，再決定是否納入正式環境。
身分委派之外，也要建立定期存取審查
JumpCloud 11 月 2 日的更新另介紹 Access Certification。官方將其定位為身分治理與管理（IGA）能力，可針對 SSO 應用程式或目錄使用者群組啟動單次或週期性審查，並支援管理員、主管、資源負責人等多階段核准流程。審查決定完成或逾期時，可依設定自動撤銷存取權或停用閒置身分，並匯出 CSV、JSON 或 PDF 稽核資料。
另外，JumpCloud 於 10 月 26 日更新 Directory Insights 的 SIEM 整合，提供持續擷取身分事件的 API，以及 RAW 或 OCSF 正規化格式；官方文件也說明可匯出最長七天的歷史資料區間，並在 13 個月的回溯範圍內執行匯出。對已經部署 SIEM 的企業，這有助於把身分事件納入既有調查與稽核流程，但仍需實際驗證欄位映射、事件完整度與日誌保存政策。
企業設計 Agent 存取時，至少要釐清四個邊界
- 使用者與 Agent 必須分開識別：保留發起請求的員工身分，也保留實際執行工作的 Agent 身分。不要讓 Agent 以共用人類帳號操作，否則難以區分使用者意圖與自動化執行。
- 委派權限應有明確範圍：逐一列出 Agent 可呼叫的 API、資料類型與操作動作。Allowed Audiences 應依業務服務設定，不應為了方便而授權整個 API 網域或所有內部系統。
- 建立擁有者與生命週期：每個 Agent 都應有業務負責人、技術維護人與用途說明，並定義建立、測試、上線、停用及刪除流程。員工離職或專案結束時，也要檢查其所擁有的 Agent 與相關授權。
- 讓事件可以被調查：記錄誰提出請求、哪個 Agent 執行、使用哪個應用程式與資源、核准依據及結果。將身分事件送入 SIEM，並與 API、應用程式及工作流程日誌對時，才能建立完整事件脈絡。
台灣企業導入前的評估清單
台灣企業若計畫將 AI Agent 接上 ERP、MES、HR、客服、知識管理或內部資料平台，建議先挑選一個低風險工作流程進行試行。測試時確認自建 Agent 應用程式與內部 API 是否符合 OIDC 與權杖交換要求、委派權限能否限制到指定資源、使用者與 Agent 是否都能被清楚識別，以及管理員能否在事件發生後停用或撤銷授權。
採購評估還應確認私人預覽的申請條件、正式版時程、功能授權與支援範圍；並釐清雲端服務的資料處理地點、跨境資料傳輸、日誌保存、管理介面語言、在地支援窗口及與既有 Microsoft Entra ID、Google Workspace、HR 系統和 SIEM 的整合方式。不要只看功能展示，也要要求供應商說明權杖生命週期、撤銷機制、API 錯誤處理及稽核資料如何匯出。
先治理身分，再擴大 Agent 自動化
JumpCloud 的近期更新反映出 IAM 正從管理員工與裝置，延伸到管理自動化 Agent。對企業而言，重點不是盡快讓每個 Agent 都能呼叫系統，而是先建立可辨識、可授權、可審查、可撤銷的身分邊界。Agent Delegated Access 目前仍處於私人預覽階段，適合先進行架構驗證與小規模測試；正式採用前，應以實際 API、稽核流程與資料治理要求完成安全評估。