企業安全：解耦 Microsoft Entra Agent ID 的技術架構

解構 Entra Agent ID

剖析微軟針對自主型與輔助型 AI 系統打造的階層式身分識別模型

身分識別架構的結構性轉變

有別於過去為了可預測的指令碼（Scripts）而建置的傳統機器身分，現代 AI 代理人（Agent）的角色更加動態，具備呼叫 API、利用工具集以及冒充人類使用者的能力。Entra Agent ID 框架並非將代理人視為綁定在應用程式註冊上的單一靜態憑證，而是將「憑證維護」與「權限強制執行」徹底解耦。此結構定義了代理人的運作藍圖（Blueprint）、規範了其代表他人採取行動的方式，並確立了人類層級的管理問責制。 本篇深度解析將探討 AI 代理人的功能性組成構件，以及在企業目錄中監管這些非人類系統的專門身分識別架構。

---

1. AI 代理人的功能性組成構件

在代理人與 Microsoft Entra ID 進行互動之前，其內部的程式碼架構便已決定了其感知數據與執行任務的方式。此功能性迴圈依賴四個核心組件：

• 推理引擎（模型）： 底層的大型語言模型（LLM），負責處理意圖、解析指令並做出系統性的決策。
• 編排層（Orchestration Layer）： 循環式的控制迴圈，負責管理數據輸入、提示模型，並判斷多步驟的目標何時達成。
• 情境記憶（Memory）： 動態儲存陣列，提供即時狀態與歷史互動紀錄，避免模型需要頻繁地重新訓練。
• 可擴充介面（工具）： 連接點（如網頁爬蟲、在地檔案系統及外部 API），允許代理人讀取並修改其身處的維運環境。

---

2. 拆解 Entra Agent ID 的階層結構

由於自主型工作流會引入不可預測的存取模式，微軟採用了多層級的身分識別結構，而非獨立的服務主體定義。此模型乾淨地將主體組態設定與個別運行的實例（Instances）隔離開來。

---

3. 權杖交換與身分驗證機制

在此架構中，身分驗證手段已從傳統的密碼金鑰驗證，轉向由業界標準協定（如 OpenID Connect (OIDC) 與 OAuth 2.0）完全驅動的、嚴格的多步驟權杖交換模型（Token-exchange model）。 當一個作用中的代理人身分需要查詢資源時，其運作流程將透過委派的冒充流（Delegated impersonation flow）展開：

1. 父級代理人身分藍圖利用其根憑證（如 FIC 或憑證）直接向 Microsoft Entra ID 進行身分驗證。
2. Entra ID 驗證藍圖後，核發一個針對特定子代理人身分的臨時交換權杖（Exchange token）.
3. 代理人身分將此交換權杖作為其用戶端聲明（Client assertion），用以提取查詢目標 API 所需的最終存取權權杖（Access token）。

得益於此交換機制，最終的存取權權杖會將特定的代理人身分實例列為主要執行用戶端，確保在企業 SIEM 平台中具備深度的歷史可追溯性。

維運身分驗證流

根據業務目標的不同，代理人會採用三種專門的 OAuth 設定檔之一來進行身分驗證：

身分驗證設定檔	技術流觸發機制	授權邊界
互動式 / 輔助型	因應即時、已登入之人類使用者的提示詞，透過「代理執行（On-Behalf-Of, OBO）」流觸發。	利用委派範疇（Delegated scopes）；代理人的權限絕不能超過與其互動之人類使用者的權限。
自主型背景維運	在沒有人類操作的情境下，透過預期排程或系統事件點（Hooks）獨立執行。	利用用戶端憑證（Client Credentials）流；嚴格在直接分配給該代理人身分的應用程式權限內採取行動。
代理人使用者設定檔	當與 Exchange 或 Teams 頻道等要求使用者物件的孤島直接互動時觸發。	繞過標準的人類互動式提示，純粹透過與父級身分的同盟關係進行驗證。

---

4. 治理、授權與影子存取向量

為了防止失去控制的「代理人野蠻生長（Agent sprawl）」，微軟建立了嚴格的管理機制，將結構化的技術組態與業務生命週期擁有權清晰分離：

• Sponsors（保證人）： 必須由特定人類使用者或群組擔任，對代理人的生命週期承擔絕對的業務問責。保證人負責批准權限展延、審查使用指標，並在資安事件發生時授權立即隔離。若缺乏指定的保證人，該身分在系統中將變得「治理隱形」，並在例行性存取審查中被阻斷。
• Owners（擁有者）： 負責藍圖或代理人實例的技術調整、整合配置及即時事件回應的人類技術維運人員。
• Managers（管理者）： 專門指定用於處理次級「代理人使用者帳戶」維運組態設定的技術人員。

威脅模型：可繼承權限與允許的危險範疇

為了簡化大型環境的管理成本，Entra ID 允許管理員直接在根級的 Agent Identity Blueprint 上配置可繼承權限（Inheritable permissions）。一旦在藍圖主體（Blueprint Principal）上獲得同意，這些權限便會自動級聯到所有衍生出的子代理人身分。 儘管維運效率極高，此架構卻引入了嚴重的影子存取風險（Shadow Access Risk）。由於繼承的權限是在核發權權杖時動態注入的，如果資安團隊直接檢查個別的代理人身分物件，只會看到一個完全乾淨、看似零權限的設定檔。審計單一實例的團隊將完全漏掉這些作用中的高權限範疇，除非他們回頭評估根藍圖的組態設定矩陣。

「雖然微軟明確禁止代理人持有諸如全域管理員（Global Administrator）等高階目錄角色，以及 RoleManagement.ReadWrite.All 等高風險 API 權限，但仍有數個等同於 Tier-0 的功能維持可分配狀態。例如，持有允許的 Application.ReadUpdate.All 範疇的代理人一旦被攻擊者控制，即可被用來向現有的企業應用程式中植入惡意的憑證。」

---

5. 世代差異與登錄表的演進

隨著企業在其目錄中執行資產發現審計，資安團隊必須區分目前在 Entra ID 中共存的兩個不同架構世代的代理人：

• 傳統代理人（Classic Agents）： 在 Agent ID 框架推出之前建置的舊版自動化物件（例如在早期版本的 Copilot Studio 中佈建的物件），它們運行在傳統的應用程式服務主體上。這些物件在目錄中會被標記為 Has Agent ID: No。它們與現代專屬 AI 的安全層（如代理人條件式存取或代理人身分保護）完全不相容。
• 現代代理人（Modern Agents）： 完全原生於新框架的非人類身分。它們由主藍圖提供技術支撐、擁有獨特的 Agent ID、支援權權杖交換冒充引擎，並完全相容於風險驅動的條件式存取。

為了精簡這項管理負擔，微軟正在推出 Agent 365（2026 年 5 月正式上市）。這個統一的控制平面將取代 Entra 系統管理中心舊有的「代理人登錄表（Agent registry）」介面，作為追蹤、審計與管理企業內部傳統與現代代理人模型的單一事實來源。