部落格 發布於 AIA: 2026年4月29日

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

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

Privilege EscalationService Principal TakeoverIdentity & AccessEntra IDService Principals
8 項對應的 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 操作，而不是只相信文件裡的角色名稱。

適用的 8 項 AIDEFEND 防禦手法

AID-M-009.003
Agent Identity, Delegation Lineage & Runtime Authorization
極高
這是最直接對應的防線，因為問題發生在 AI agent 身分角色和它能影響的目錄身分之間。agent 身分治理不能只記「某人有 Agent ID Administrator」，還要能回答：誰指派了這個角色、它要管理的是哪個 agent 物件或服務主體、原本核准的委派範圍是什麼、這次操作有沒有留在那個範圍內。像「新增擁有者」這類會改變控制權的動作，必須在真正執行前就被授權判斷擋住。
AID-H-019.002
Policy-Based Access Control
極高
核心失效點是授權政策沒有真的落實文件上的資源邊界。政策引擎不應只看使用者有沒有 Agent ID Administrator，還要同時看目標物件型別、目標是否真的是 agent-backed service principal、要求的操作是新增 owner 還是新增 credential，以及目前租戶情境。白話說，這個角色可以管理 agent 用的服務主體，但一碰到非 agent 服務主體，就應該預設拒絕。
AID-H-019.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-H-004.002
Service & API Authentication
高
服務主體被接管之所以有用，是因為攻擊者可以新增憑證，然後用那個應用程式身分登入。服務與 API 驗證控制應該限制誰能替服務主體新增 secret 或 certificate；對高權限服務主體，應優先使用短效或 federated credential，並對新憑證建立事件發出警示通知。能移除長效 secret 的地方，就不要保留長效 secret。
AID-D-004.003
Runtime Configuration & Policy Drift Detection and Monitoring
中
這裡最有訊號的偏移，是 agent 管理角色做了超出預期的事：改到非 agent 服務主體的 owner。偵測規則應該把實際目錄變更和核准的角色模型比對起來；如果某個角色開始修改它不該管理的物件類別，就要產生包含操作者、目標物件、操作類型和政策版本的警示。
AID-D-005.004
Specialized Agent & Session Logging
中
要查清楚這類事件，不能只看單一 AuditLog。平台需要把角色指派、Graph API 呼叫、目標服務主體、owner 變更、新增憑證，以及後續用該服務主體登入的事件串成同一條時間線。這樣 responder 才能判斷操作是否留在 agent identity 控制面，還是已經跨到一般服務主體管理平面。
AID-E-001.001
Foundational Credential Management
中
如果環境裡曾出現這種模式，回應不能只把角色拿掉。還要移除未授權新增的服務主體 secret 或 certificate、輪替受影響憑證、撤銷透過新憑證拿到的 session 或 token，並回頭檢查被接管服務主體後續做過哪些存取。

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

  • 先確認 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 變更，都應該被當成高風險身分事件。