How a new AI agent role in Microsoft Entra ID let any user silently take over the entire tenant

The Context

Microsoft Entra ID is the identity backbone for most large enterprises. It controls who can sign in, what applications they can access, and which automated systems can act on behalf of the organization. Within Entra ID, a "service principal" is the identity record for an application or automated process—the equivalent of a user account but for software. Service principals can be granted powerful permissions: reading all email, creating user accounts, or assigning administrative roles.

In 2025, Microsoft introduced the Microsoft Agent Identity Platform, currently in preview, to give AI agents their own first-class identities inside Entra ID. The platform introduced new object types for agents and a new built-in role, Agent ID Administrator, to manage them. The role was documented as scoped to agent-related objects only.

The problem: agent identities are implemented as a special subtype of service principal. That shared foundation meant the role's permissions did not stay within the agent boundary.

The Attack, Phase by Phase

Phase 1: The Architectural Root Cause

Microsoft designed the Agent ID Administrator role to handle the full lifecycle of AI agent identities: creating blueprints, managing agent users, and updating ownership of agent objects. The documentation was clear that the role was scoped to these agent-related objects.

What the documentation did not reflect was the underlying implementation. Agent identities are a special subtype of service principal—the same object type used by every other application in the tenant. When Microsoft built the owner-management permissions for the new role, the authorization layer never enforced a check asking "is this object an agent-backed service principal?" It simply checked whether the caller had permission to update service principal ownership, and the Agent ID Administrator role did.

The same ownership-write action was correctly blocked for application objects, confirming the gap was specific to the service principal management layer. The boundary existed in the documentation. It did not exist in the API.

Phase 2: The Exploitation Chain

An attacker holding the Agent ID Administrator role—through account compromise or a malicious insider—would begin by enumerating the tenant. Using the Microsoft Graph API (confirmed exploitable on both the beta and v1.0 endpoints) or the Azure CLI, they would identify service principals holding high-impact permissions: those assigned the Global Administrator directory role, or those with Graph API permissions such as RoleManagement.ReadWrite.Directory or Directory.ReadWrite.All.

The attacker would then call the owner-update API to add themselves as an owner of the target service principal. Ownership is the critical primitive: an owner can inject new credentials—a client secret or certificate—then authenticate as the service principal and inherit every permission it holds.

Silverfort demonstrated this end-to-end in a proof-of-concept video. A test user holding only the Agent ID Administrator role took ownership of a Global Administrator service principal, injected credentials, and signed in as that principal. Full tenant takeover from a role that was supposed to manage AI agents.

Phase 3: Compounding Factors and Silent Patch

Two factors made this significantly worse than a typical privilege escalation flaw.

First, the Entra admin interface did not display the Agent ID Administrator role as privileged, even though the official documentation classified it as such. Administrators assigning the role would not see the warning indicators that appear for roles like Global Administrator. The role that could take over the entire tenant looked, in the UI, like a routine operational grant.

Second, Microsoft's fix on April 9, 2026 was deployed silently. No public advisory. No CVE. No notification to security teams. The patch enforces a server-side "Forbidden" response for any ownership write against a non-agent service principal using this role—but it does not automatically remove owners or credentials injected before the patch. Any backdoor established before April 9 remains active until a human finds and removes it.

Phase 4: Disclosure and Remediation

Silverfort published its full technical disclosure on April 23, 2026, including a proof-of-concept video and detection queries for Azure Log Analytics. Microsoft awarded a bug bounty.

For any organization that had the Agent ID Administrator role assigned before April 9, the period before the patch should be treated as an active exposure window. Audit logs should be reviewed for service principal ownership changes and new credential creation events. Unexplained entries should be treated as active backdoors. Going forward, the role should be managed through Privileged Identity Management (PIM), which requires users to explicitly request and justify elevated access rather than holding it permanently.

What Made This Possible

1. Shared primitives without API-layer enforcement. Agent identities were built on top of service principals. The authorization check for ownership updates never verified whether the target was an agent-backed object. The boundary was documented but not enforced.

2. UI and documentation out of sync. The Entra admin interface did not flag the role as privileged. Administrators had no visual signal that assigning it required the same scrutiny as a Global Administrator grant.

3. Silent patching without retroactive audit guidance. Deploying a fix without a public advisory left security teams without the prompt they needed to check whether the vulnerability had already been exploited. The patch addressed future risk. It left past exposure unexamined.

What Should Have Stopped This

No single defense here depends on the role's documented scope being accurate. When documentation and implementation diverge, only controls that operate at the enforcement layer remain effective.

• Privileged Identity Management for all privileged roles. PIM requires users to request elevated access for a defined window and justify the request. Any use of the Agent ID Administrator role would have generated an approval event and a time-limited grant, creating an audit trail and limiting the window for abuse.
• Least-privilege service principal hygiene. Service principals holding Global Administrator or broad directory-write permissions are high-value targets. Regularly auditing which principals hold these permissions and removing unnecessary grants reduces the attack surface.
• Alerting on service principal ownership changes. Adding an owner to a service principal is a rare, high-signal event. An alert on any ownership change to a privileged service principal would have surfaced exploitation in real time.
• Treating new preview-stage roles as privileged by default. A policy of treating any role that can modify service principals as privileged—regardless of UI indicators—would have closed this gap before the discrepancy was discovered.

The Takeaway

This vulnerability is a preview of a problem that will recur. As AI agent infrastructure is layered on top of existing identity systems, new roles will be introduced to manage new object types. When those object types are implemented as subtypes of existing primitives, the authorization boundary must be enforced at the API layer. Stating it in documentation is not enforcement.

The silent patch compounds the systemic lesson. Enterprises rely on public advisories and CVE disclosures to trigger internal audits. When a fix is deployed without that signal, the governance loop breaks. Security teams cannot respond to a risk they were not told existed.

Pattern to remember: When a new role is built to manage a new object type that shares primitives with existing objects, the scope boundary must be enforced in code, not just stated in documentation.

What changed: A role's product-scoped name is no longer a reliable signal of its actual permission boundary; defenders must verify scope at the API layer, not the documentation layer.

The Technical Mechanism

The Agent ID Administrator role is a built-in Entra ID directory role introduced as part of the Microsoft Agent Identity Platform (currently in preview). Its documented purpose is to manage the full lifecycle of AI agent identities: creating and managing blueprints, agent identities, and agent users.

The flaw resided in the authorization logic for the UpdateOwners action on service principal objects. In Entra ID's object model, agent identities are implemented as a specialized subtype of service principal. The role's permission to update ownership of agent identity objects was expressed as a permission against the service principal object type, without a predicate restricting it to agent-backed instances. The authorization layer evaluated the caller's role permissions against the target object type (service principal) but did not evaluate whether the target object was an agent-backed service principal or a conventional application service principal.

The exploitation path:

1. Caller authenticates with an account holding the Agent ID Administrator role.
2. Caller enumerates service principals via GET /v1.0/servicePrincipals or GET /beta/servicePrincipals, filtering for those with appRoles or oauth2PermissionScopes indicating high-impact Graph permissions (RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All, Directory.ReadWrite.All) or those assigned privileged directory roles.
3. Caller invokes POST /v1.0/servicePrincipals/{id}/owners/$ref to add themselves as owner of the target.
4. Caller invokes POST /v1.0/servicePrincipals/{id}/addPassword or POST /v1.0/servicePrincipals/{id}/addKey to inject a client secret or certificate.
5. Caller authenticates as the target service principal using the injected credential and inherits all assigned permissions.

The same UpdateOwners action was correctly blocked against application objects (/applications/{id}/owners), confirming the gap was specific to the service principal management surface. Microsoft's server-side fix enforces a check that the target service principal is agent-backed before allowing the ownership write. Any attempt against a non-agent service principal now returns 403 Forbidden.

The fix does not retroactively remove owners or credentials added before April 9, 2026.

CVE and Advisories

No CVE was assigned for this vulnerability. Microsoft deployed a silent server-side fix on April 9, 2026, with no public advisory issued through MSRC or the Microsoft Security Update Guide at the time of Silverfort's disclosure on April 23, 2026.

The vulnerability was confirmed by MSRC on March 26, 2026, following responsible disclosure by Silverfort on March 1, 2026. Microsoft awarded a bug bounty.

MITRE ATT&CK Mapping

Indicators of Compromise

Detection requires querying Entra ID audit logs. Silverfort published detection queries for Azure Log Analytics in their April 23, 2026 disclosure.

Key Audit Log Signals

• Add owner to service principal events where the target service principal is not an agent identity object and the initiating user holds the Agent ID Administrator role.
• Add password credential to service principal or Add key credential to service principal events on privileged service principals (those holding Global Administrator, Application Administrator, or high-impact Graph API permissions), particularly where the initiating identity is not a recognized automation account.
• Assignments of the Agent ID Administrator role to user accounts, especially where no corresponding PIM justification record exists.

Detection Difficulty

Because the exploitation chain uses standard, documented Graph API calls and the role was legitimately assignable, there are no anomalous network indicators. Detection depends entirely on log review. The silent patch means SOC teams must proactively query historical logs rather than responding to an advisory trigger. Any ownership-addition event on a privileged service principal before April 9, 2026 that cannot be attributed to a known administrative action should be treated as a potential indicator.

Attribution

This was a design and implementation flaw in a Microsoft product, not an attack by a threat actor. The vulnerability was discovered by Silverfort researchers Noa Ariel and Yoav S on February 24, 2026, and responsibly disclosed to MSRC on March 1, 2026. Microsoft confirmed the issue on March 26, 2026, deployed a fix on April 9, 2026, and awarded a bug bounty. No in-the-wild exploitation has been reported.

Primary Sources