解構 Entra Agent ID
剖析微軟針對自主型與輔助型 AI 系統打造的階層式身分識別模型
戰略簡報： 隨著自主型 AI 系統的發展跨越了簡單的文字生成，轉向在企業網路中執行業務邏輯，傳統的服務主體（Service Principals）已無力獨撐大局。保障這些工作負載的安全需要一套全新的身分識別範式。Microsoft Entra Agent ID 引入了一套階層式的委派驗證框架，專為解決企業級 AI 員工的規模化、流動性權限以及損害範圍（Blast-radius）挑戰而設計。
身分識別架構的結構性轉變
有別於過去為了可預測的指令碼（Scripts）而建置的傳統機器身分，現代 AI 代理人（Agent）的角色更加動態，具備呼叫 API、利用工具集以及冒充人類使用者的能力。Entra Agent ID 框架並非將代理人視為綁定在應用程式註冊上的單一靜態憑證，而是將「憑證維護」與「權限強制執行」徹底解耦。此結構定義了代理人的運作藍圖（Blueprint）、規範了其代表他人採取行動的方式，並確立了人類層級的管理問責制。
本篇深度解析將探討 AI 代理人的功能性組成構件，以及在企業目錄中監管這些非人類系統的專門身分識別架構。
1. AI 代理人的功能性組成構件
在代理人與 Microsoft Entra ID 進行互動之前，其內部的程式碼架構便已決定了其感知數據與執行任務的方式。此功能性迴圈依賴四個核心組件：
- 推理引擎（模型）： 底層的大型語言模型（LLM），負責處理意圖、解析指令並做出系統性的決策。
- 編排層（Orchestration Layer）： 循環式的控制迴圈，負責管理數據輸入、提示模型，並判斷多步驟的目標何時達成。
- 情境記憶（Memory）： 動態儲存陣列，提供即時狀態與歷史互動紀錄，避免模型需要頻繁地重新訓練。
- 可擴充介面（工具）： 連接點（如網頁爬蟲、在地檔案系統及外部 API），允許代理人讀取並修改其身處的維運環境。
2. 拆解 Entra Agent ID 的階層結構
由於自主型工作流會引入不可預測的存取模式，微軟採用了多層級的身分識別結構，而非獨立的服務主體定義。此模型乾淨地將主體組態設定與個別運行的實例（Instances）隔離開來。
藍圖層（範本與核心安全）
Agent Identity Blueprint（代理人身分藍圖）： 作為全域的維運範本（類似於傳統的應用程式註冊 App Registration），藍圖是該代理人家族唯一的憑證金庫。它負責儲存憑證、用戶端密碼（Client Secrets）或同盟身分憑證（FIC）。個別運行的實例本身絕不管理自己的密碼，所有憑證皆專屬地存在於此根層級。藍圖同時定義了基礎組態數據，以及向下級聯到所有子實例的可繼承權限。
Agent Identity Blueprint Principal（代理人身分藍圖主體）： 藍圖在特定租戶（Tenant）內執行時的執行階段（Runtime）呈現（類似於企業應用程式 Enterprise Application）。部署後，此物件會自動獲得 AgentIdentity.CreateAsManager 角色，賦予其佈建與管理在地化子代理人身分生命週期的授權。當藍圖在租戶內請求權杖（Tokens）時，審計日誌會追蹤此主體的物件 ID（Object ID）以維持問責制。
實例層（執行角色）
Agent Identity（代理人身分）： 服務主體的一種特化子類型，作為個別 AI 代理人用來進行身分驗證的獨特帳戶。雖然藍圖掌控了加密金鑰，但 Agent Identity 才是實際承載權限集（Microsoft Graph 範疇、Azure RBAC 角色與 Entra 權限）的容器。它在登入日誌中註冊為執行動作的用戶端，將每項自動化操作對映到特定實例。在應用程式專屬權限模型下，非微軟平台在每個租戶中最多只能衍生 250 個代理人身分。
Agent User Account（代理人使用者帳戶）： 一個選配的、與特定代理人身分保持一對一精確綁定的次級 Entra 使用者帳戶。這項配置專門用於代理人必須與高度依賴人類互動的協作工具（嚴格要求使用者物件結構，如 Microsoft Teams 頻道、Exchange 信箱或共享行事曆）進行互動的情境。這些物件會返回 idtyp=user 的權權杖宣告，但完全繞過人類的身分驗證路徑（如 MFA 或密碼），轉而依賴其父級代理人身分進行身分同盟。
3. 權杖交換與身分驗證機制
在此架構中，身分驗證手段已從傳統的密碼金鑰驗證，轉向由業界標準協定（如 OpenID Connect (OIDC) 與 OAuth 2.0）完全驅動的、嚴格的多步驟權杖交換模型（Token-exchange model）。
當一個作用中的代理人身分需要查詢資源時，其運作流程將透過委派的冒充流（Delegated impersonation flow）展開：
- 父級代理人身分藍圖利用其根憑證（如 FIC 或憑證）直接向 Microsoft Entra ID 進行身分驗證。
- Entra ID 驗證藍圖後，核發一個針對特定子代理人身分的臨時交換權杖（Exchange token）。
- 代理人身分將此交換權杖作為其用戶端聲明（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）」介面，作為追蹤、審計與管理企業內部傳統與現代代理人模型的單一事實來源。
非人類工作負載的範式轉變
非人類目錄物件的演進標誌著資安防禦優先順序的顯著位移：
- 標準服務主體： 為可預測的指令碼而設計。核心防禦焦點在於防止憑證金鑰外洩。
- 受控身分（Managed Identities）： 為雲端資源而設計，徹底移除了可見的憑證。核心防禦焦點在於緩解因過度配置 RBAC 角色而導致的權限蔓延。
- 代理人身分（Agent Identities）： 為非確定性、自主化的 LLM 工作流而設計。核心防禦焦點轉向管理繼承的存取權限與藍圖的損害範圍。防禦者不僅必須審計該身分在第一天被配置了什麼，更必須審計當該代理人橫跨連接的工具、使用者與企業應用程式採取行動時，它能動態轉化為什麼樣的角色。
關於 Guardz
Guardz 為管理服務提供商 (MSP) 和 IT 專業人士提供一個人工智能驅動的網絡安全平台，專門設計來保護小型企業免受網絡攻擊。我們的統一檢測與響應平台能夠全面保護用戶、電子郵件、設備、雲端目錄和數據。透過簡化網絡安全管理，我們讓企業能夠專注於發展業務，同時減少安全管理的複雜性。Guardz 結合強大的網絡安全技術和豐富的專業知識，確保安全措施持續受到監控、管理和改進，預防未來的攻擊並降低風險。
關於 Version 2 Digital
Version 2 Digital 是亞洲最有活力的IT公司之一，公司發展及代理各種不同的互聯網、資訊科技、多媒體產品，其中包括通訊系統、安全、網絡、多媒體及消費市場產品。透過公司龐大的網絡、銷售點、分銷商及合作夥伴，Version 2 Digital 提供廣被市場讚賞的產品及服務。Version 2 Digital 的銷售網絡包括中國大陸、香港、澳門、台灣、新加坡等地區，客戶來自各行各業，包括全球1000大跨國企業、上市公司、公用機構、政府部門、無數成功的中小企及來自亞洲各城市的消費市場客戶。