實證研究 發布於 AIA: 2026年4月29日

Entra agent 管理角色越界：如何接管服務主體

Silverfort 發現，Microsoft 為 Entra Agent ID 控制面（Entra 是 Microsoft 的身分管理平台）新增的 Agent ID Administrator 角色，原本應該只管理 agent 相關物件，卻能把自己加成任意非 agent 服務主體的擁有者；服務主體（service principal，應用程式在租戶裡用來登入、拿權限、呼叫 API 的身分）一旦被加上新的擁有者，攻擊者就能新增登入憑證，接著用那個服務主體的權限行動。Microsoft 已在 2026 年 4 月 9 日確認修補完成，所有雲端都已套用。這個案例的重點不只是某個預覽版角色有 bug，而是 AI agent 身分治理必須實際測試角色能碰到哪些底層物件、能做哪些操作，不能只看文件寫「這是 agent 角色」。

Privilege EscalationService Principal TakeoverIdentity & AccessEntra IDService Principals
9 項對應的 AIDEFEND 防禦手法
來源: Agent ID Administrator scope overreach: Service Principal takeover in Entra ID 
作者: Noa Ariel (Silverfort)
原文發布: 2026年4月23日

威脅分析

  • agent 身分其實建立在既有的服務主體機制上。 Entra Agent ID 引入 blueprint、agent identity 和 agent user 等新物件，但 agent identity 底層仍然和 Entra 裡的 application、service principal 這些既有目錄物件有關。問題就出在這裡：新角色看起來是管 agent，實際執行時卻碰到了更大的服務主體平面。
  • 文件說只管 agent 物件，但實際授權範圍跑太遠。 Agent ID Administrator 文件上的角色範圍（role scope）是 agent 相關物件。Silverfort 測到的是，這個角色可以把自己加成租戶裡非 agent 服務主體的擁有者（owner）。
  • 成為擁有者之後，就能接管服務主體。 這個邏輯順序很直覺：先把自己加成服務主體擁有者，再新增 secret 或憑證，最後用那個服務主體登入。如果目標服務主體本來就有高權限目錄角色，或有像 Directory.ReadWrite.All、RoleManagement.ReadWrite.Directory 這類高影響 Microsoft Graph 權限，結果就會變成權限升級。
  • 介面上的風險標示也會影響管理判斷。 Silverfort 指出，文件裡這個角色被標成 privileged，但 Entra UI 當時沒有把它顯示成 privileged。對管理員來說，這很容易降低審查強度，讓一個其實能影響服務主體擁有權的角色被當成普通 agent 管理角色指派出去。
  • Microsoft 已修補這個漏洞，但這種越界模式仍然值得防禦方注意。 修補後，Agent ID Administrator 已不能再管理非 agent 服務主體的擁有者。對防禦方來說，後續重點是：新的 AI 身分角色只要建立在既有目錄物件上，就要測到底層物件型別和實際 API 操作，而不是只相信文件裡的角色名稱。

適用的 9 項 AIDEFEND 防禦手法

AID-M-009.003
Agent Identity, Delegation Lineage & Authorization Context
極高
這是最直接的 identity-context 對應，因為問題發生在 AI agent 角色與它能影響的目錄身分之間。保留角色指派者、目標 agent 物件或服務主體、原始授權、委派範圍與精確的新增擁有者動作；AID-H-018.002 再消費這些上下文，負責副作用發生前的授權判斷。
AID-H-018.002
Policy-Based Access Control
極高
核心失效點是授權政策沒有真的落實文件上的資源邊界。政策引擎不應只看使用者有沒有 Agent ID Administrator，還要同時看目標物件型別、目標是否真的是 agent-backed service principal、要求的操作是新增 owner 還是新增 credential，以及目前租戶情境。白話說，這個角色可以管理 agent 用的服務主體，但一碰到非 agent 服務主體，就應該預設拒絕。
AID-H-018.006
Continuous Authorization Verification (Anti-TOCTOU)
高
這條攻擊鏈有兩個敏感步驟：先成為 owner，再新增登入憑證。每一步都要在執行當下重新授權，不能因為前面看過一次角色就一路放行。就算某個帳號可以管理 agent identity，系統在新增 owner、建立 secret 或 certificate、以及後續用該服務主體登入前，都應該重新確認目標物件是不是 agent 相關，且這個操作是否符合目前授權。
AID-H-004.001
User & Privileged Access Management
高
Agent ID Administrator 是可以指派給人的管理角色，所以要用 privileged access 的標準看待：需要核准流程、臨時啟用而不是長期常駐權限、升級驗證、定期 access review，以及清楚盤點哪些管理員可以操作 agent 身分。不要因為 UI 沒標成 privileged，就把它當成低風險角色。
AID-E-001.003
AI Agent & Workload Principal and Issuance Disablement
高
若 service principal 已透過這條路徑遭接管，必須在所有權威 identity、federation 與 authorization plane 停用那個確切的 agent 或 workload principal，並封鎖所有新的 credential／token 簽發路徑。只移除攻擊者新增的 secret 還不夠，因為 principal 仍可能取得替代存取；已簽發 token 與 delegated grant 分別由 AID-E-001.002、AID-E-001.004 處理。
AID-E-001.004
Delegated Grant & Connected-App Authorization Revocation
高
攻擊者一旦成為 service principal 或 app registration 的 owner / administrator，事件處理不能只輪替機敏憑證 (secrets)。團隊還要盤點並撤銷 delegated OAuth grant、connected-app consent、app-role assignment 和 SaaS app grant，避免一般 token 或 secret 失效後，攻擊者仍能靠既有委派授權繼續存取。這是補強基礎憑證清理，不是取代它。
AID-D-011.004
Non-Human Identity & Delegated Token Abuse Detection
中
這次接管最需要監看的訊號，是非人類身分（NHI）與委派 token 是否遭到濫用。平台應把服務主體（service principal，應用程式在租戶裡用來登入、取得權限並呼叫 API 的身分）的憑證簽發、交換與更新，和後續登入行為串在一起分析。只要有人替高權限服務主體新增密碼或憑證，接著又從不符合政策的 client、權限範圍或工作負載登入，就要發出高風險身分警示。
AID-D-005.004
Specialized Agent & Session Logging
中
要查清楚這類事件，不能只看單一 AuditLog。平台需要把角色指派、Graph API 呼叫、目標服務主體、owner 變更、新增憑證，以及後續用該服務主體登入的事件串成同一條時間線。這樣 responder 才能判斷操作是否留在 agent identity 控制面，還是已經跨到一般服務主體管理平面。
AID-E-001.001
Root & Long-Lived Credential Object Eviction
中
如果環境裡出現這種模式，必須到權威簽發端移除攻擊者新增的服務主體 secret 或 certificate，並輪替所有受影響的 root 或長效 credential object。已透過這些憑證簽發的 token 或 session 由 AID-E-001.002 另外撤銷，不能把兩種結果混在一起。

身為資安防禦者，我們應該這麼做

  • 先確認 Microsoft 的修補已套用到你使用的 Entra 雲端與租戶，接著盤點所有 Agent ID Administrator 和類似 agent 身分管理角色的指派。即使 UI 沒標成 privileged，也要先用高權限角色的標準管理。
  • 找出有高權限目錄角色或高影響 Microsoft Graph 權限的服務主體，特別檢查最近是否有人新增 owner 或新增登入憑證。
  • 新增警示：只要 Agent ID Administrator 帳號對非 agent 服務主體新增 owner 或 credential，就要立刻觸發調查。這個角色預期能碰到的目標類別應該只限 agent 相關身分。
  • 審查服務主體憑證建立流程。高權限服務主體新增 secret 或 certificate 應該要有核准、工單和部署流程對應；如果是在部署流程外建立，就當成高風險事件處理。
  • 把角色指派、owner 變更、credential 建立和後續 sign-in 串成同一條身分安全時間線。這些事件分開看很像日常管理活動，串起來才看得出接管鏈。
  • 每次導入新的 AI agent 身分功能，都要把文件上的角色範圍拿去對照底層目錄物件實測。不要假設產品名稱裡有 agent，實際有效權限邊界就一定只停在 agent。

1 個額外的防禦考量

新 AI 身分角色的目錄權限模擬

除了上面對應的技術，導入預覽版 AI 身分功能的團隊還應該額外做一件事：在廣泛指派任何新角色前，先模擬它對各種底層目錄物件到底能做什麼，而不是只看文件上的角色描述。
建議做法: 建立預先測試流程，把每個新的 AI agent 角色拿去測 agent 物件、非 agent 服務主體、應用程式物件（application object）、代管身分（managed identity）、登入憑證、應用程式角色指派（app role assignment）和擁有者變更。只要出現文件沒說會允許的結果，就先暫停推出。

結論

Silverfort 這個發現很清楚地說明，AI agent 身分治理不能只停在新名詞表面。Entra Agent ID 確實建立了 agent-facing 的新概念，但這些概念仍然繼承 application、service principal、owner、credential 和 Microsoft Graph 權限這些既有機制。AIDEFEND  在這個案例中對應到 agent 身分脈絡、policy-based 授權、每一步敏感操作重新授權、privileged access 管理、服務驗證、偏移偵測、鑑識記錄，以及事後憑證清理。實務上要抓住的重點很簡單：每個 agent 角色都要有實測過的資源邊界；任何高權限服務主體的 owner 或 credential 變更，都應該被當成高風險身分事件。