Silverfort researchers discovered that the Agent ID Administrator role in Microsoft Entra ID could silently take ownership of any service principal in your tenant — including those holding Global Administrator rights.

99%Tenants w/ ≥1 privileged service principal

>50%Tenants already using agent identities

~100Avg agent identities per active tenant

Apr 9Full patch rollout across all clouds

Field Detail Vulnerability Scope overreach in Agent ID Administrator directory role Platform Microsoft Entra ID (Azure AD) — all cloud environments Attack Type Privilege Escalation / Service Principal Takeover Discovered By Silverfort researchers Noa Ariel & Yoav S. Reported to MSRC March 1, 2026 Microsoft Confirmed March 26, 2026 Patch Deployed April 9, 2026 (server-side, no user action required) Post-Patch Behavior Non-agent SP ownership assignment → "Forbidden" error Risk Level CRITICAL — full tenant compromise possible

What Is Microsoft Entra ID AI Agent Privilege Escalation?

As enterprises accelerate deployment of AI agents inside their Microsoft 365 and Azure environments, Microsoft has been quietly building out an identity framework to support them. The Microsoft Agent Identity Platform — a preview feature inside Entra ID — gives AI agents their own directory identities: blueprints, agent identities, and agent users. To manage these non-human entities, Microsoft introduced a dedicated role: the Agent ID Administrator.

The role seemed neatly scoped. According to Microsoft's documentation, it was intended strictly for agent-related objects. What Silverfort's identity security research team discovered, however, was that "neatly scoped" was a design fiction — and the gap between the documented intent and the actual implementation was wide enough to drive full tenant takeover through it.

This is the core of Microsoft Entra ID AI Agent Privilege Escalation: a role you would hand to a junior administrator to manage chatbots and automation agents could, before the April 9 patch, be weaponized to seize control of your most sensitive service principals — including those carrying Global Administrator rights.

The Technical Attack Path

Step 1 — Understand Service Principals

A service principal is a digital identity for software — the credential that automation pipelines, security tools, CI/CD systems, and API integrations use to authenticate and operate inside an Entra tenant. Service principals can be granted directory roles and Graph API permissions at the same elevated tiers as human users. In most enterprise tenants, service principals are the hidden load-bearing pillars of the identity architecture.

Step 2 — The Scope Gap

Agent identities in Entra ID are built on top of standard application and service principal primitives. When Silverfort researchers examined the Agent ID Administrator role, they found a critical architectural flaw: while the role was documented to manage only agent-related objects, its actual permissions extended to any service principal in the tenant. An attacker — or a malicious insider — holding only the Agent ID Administrator role could call the API to assign themselves as owner of a completely unrelated, high-privileged service principal.

Step 3 — Credential Injection and Takeover

Once ownership of a service principal is established, the attacker can add their own client secret or certificate to that principal's credentials. They then authenticate as that application — inheriting all permissions it holds. If the targeted service principal carries elevated Graph API permissions or privileged directory roles, the attacker now effectively controls those resources without ever touching a human account.

"We discovered that accounts with only the Agent ID Administrator role could take over arbitrary service principals — including ones that have nothing to do with agent identities — by becoming owner, then adding credentials and authenticating as that principal. That's full service principal takeover."— Noa Ariel, Security Researcher, Silverfort

Step 4 — Why the UI Made It Worse

Compounding the risk, the Entra ID management portal's UI did not flag the Agent ID Administrator role as "privileged" — even though Microsoft's own documentation stated otherwise. This discrepancy meant administrators could assign the role to team members without applying the elevated scrutiny typically reserved for privileged role assignments. Microsoft confirmed this UI gap would also be fixed as part of the remediation.

Who Was Exposed — The Real Numbers

The theoretical risk becomes operational risk very quickly when you examine Silverfort's telemetry from real customer environments. Approximately 99% of Entra ID tenants have at least one privileged service principal. The conditions for this escalation path were present in virtually every enterprise environment running Entra ID.

More than half of tenants already use agent identities — and of those, nearly half have over 100 agent identities deployed. As more organizations adopt the Agent ID Administrator role to manage their growing fleets of AI automation, the probability that a compromised or malicious account holding that role would have a viable escalation target was not theoretical. It was near-certain.

What Microsoft Fixed and What You Should Audit

Following Silverfort's responsible disclosure on March 1, 2026, Microsoft confirmed the vulnerability on March 26 and completed a full server-side rollout of the patch across all cloud environments on April 9, 2026. No customer action is required to receive the fix. Post-patch, any attempt by an Agent ID Administrator to assign ownership of a non-agent service principal is blocked with a "Forbidden" error.

Despite the patch, Silverfort and independent analysts recommend proactive auditing to detect any exploitation activity that may have occurred before April 9.

Remediation Checklist

Review Entra ID AuditLogs for any changes to service principal ownership — filter for Add owner to service principal actions in the 60 days preceding April 9, 2026

Check for unexpected secret or certificate additions on high-privileged service principals (Application Administrator, Global Admin scope)

Audit all current Agent ID Administrator role assignments — apply least-privilege; restrict to dedicated, monitored accounts only

Review which service principals hold admin-level directory roles or high-impact Graph API permissions in your tenant

Enable Entra ID Identity Protection and Privileged Identity Management (PIM) for all service principals with directory roles

Confirm your Entra UI now shows Agent ID Administrator as "privileged" following Microsoft's UI correction

Broader Implications: AI Identity Is the New Attack Surface

The Microsoft Entra ID AI Agent Privilege Escalation flaw is not an isolated implementation bug. It is a warning shot about the structural risk of building AI agent infrastructure on top of identity frameworks designed before non-human identities existed at scale.

As security analyst Dan Guccione noted to SC Media, "AI agent infrastructure is being constructed at speed, layered on top of outdated, existing identity security models, and the assumptions baked into traditional role design do not automatically transfer." The Agent ID Administrator role was designed to be scoped to agent objects — and it wasn't, because the underlying primitives are shared with the broader service principal layer. The abstraction leaked.

Security teams need to treat agent identity infrastructure with the same rigor applied to privileged human identity. Agentic AI is not a new application category — it is a new identity category, and identity security must evolve in parallel. Treating the current wave of Entra AI features as preview-only, low-stakes additions is the exact posture this vulnerability was designed to punish.

???? Legacy Link — Previous Coverage