Microsoft fixes Entra ID flaw enabling privilege escalation
April 28, 2026 
Microsoft fixed a Microsoft Entra ID flaw where the Agent ID Administrator role could enable privilege escalation and account takeover.
Microsoft addressed a flaw in Microsoft Entra ID that could let attackers take over service accounts. The issue involved the Agent ID Administrator role, which manages AI agent identities and access, and could be abused for privilege escalation.
Microsoft’s Agent Identity Platform lets AI agents have identities in Microsoft Entra ID, managed by the Agent ID Administrator role. Researchers found this role could take over any service principal by assigning ownership and adding credentials, enabling full compromise and privilege escalation. Microsoft fixed the issue, restricting the role to only agent-related objects.
“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. In tenants where high-privileged service principals exist, it becomes a privilege escalation path.” reads the report published by Silverfort. “While the Agent ID Administrator role isn’t yet widely used, most tenants have at least one privileged service principal. We also observed that many tenants already use agent identities, sometimes at significant scale. As adoption of the Agent ID Administrator role grows, this scope gap could become a meaningful identity security risk. “
Microsoft introduced Agent ID in Microsoft Entra ID to manage AI agents as identities, with objects like blueprints, agent identities, and agent users. These rely on standard directory components such as service principals. The Agent ID Administrator role was meant to manage only agent-related objects, but researchers found it could take ownership of any service principal, enabling credential injection and full takeover. This created a privilege escalation risk, especially since the role wasn’t clearly marked as privileged in the UI. The issue stemmed from a scoping gap between agent and standard identities. Microsoft has since fixed the flaw, blocking such actions.
The flaw enabled full service principal takeover, a powerful attack path. By gaining ownership, an attacker could add credentials and authenticate as that identity, inheriting all its permissions, such as API access, integrations, or even directory-level roles. The impact depends on how privileged the targeted service principal is, but in many environments, this can lead to serious escalation.
Before the fix, the Agent ID Administrator role in Microsoft Entra ID could take ownership of non-agent service principals, effectively granting capabilities similar to high-privilege roles. If the targeted service principal had admin rights or sensitive Graph permissions, attackers could fully compromise it.
This risk is significant because most organizations already have privileged service principals, and many also use agent identities. As adoption of the role grows, the likelihood of exploitation increases, making the issue a critical identity security concern.
The researchers published a video PoC for this flaw, where the researchers find a privileged service principal, take it over, and then sign in.
Microsoft fixed the issue, but it highlights a key lesson: new identity models, like those in Microsoft Entra ID, often rely on existing components, which can create unintended permission gaps. Here, weak scoping allowed broader access than intended, especially risky in environments with privileged service principals.
The problem was hard to detect because ownership changes can look like normal admin activity, roles weren’t clearly marked as highly privileged, and no alerts flagged out-of-scope actions.
To reduce risk, organizations should closely monitor sensitive roles, track service principal ownership and credential changes, and treat privileged service principals as critical assets. This case reinforces the need to validate role permissions and continuously audit identity controls.
Before the disclosure timeline:
- April 9, 2026 – MSRC has confirmed the fix has been fully rolled out
- February 24, 2026 – Vulnerability identified
- March 1, 2026 – Report submitted to Microsoft (MSRC)
- March 3, 2026 – Case opened by Microsoft
- March 26, 2026 – Microsoft confirmed the behavior
- April 4, 2026 – Fix reached pre-release stage and the behavior was no longer reproducible
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
Pierluigi Paganini
(SecurityAffairs – hacking, Microsoft)
