How Hackers Abuse Azure Agent ID Administrator Role to Hijack Service Principals and Exploit AI Agents for Espionage
- A critical security vulnerability in Microsoft Entra ID's Agent Identity Platform has been patched after researchers discovered that the Agent ID Administrator role could be exploited to hijack...
- The flaw allowed accounts with only the Agent ID Administrator role to take ownership of service principals unrelated to AI agent identities, add credentials and authenticate as those...
- Microsoft Entra ID's Agent Identity Platform, currently in preview, provides AI agents with their own identities in the directory so they can be governed and secured like any...
A critical security vulnerability in Microsoft Entra ID’s Agent Identity Platform has been patched after researchers discovered that the Agent ID Administrator role could be exploited to hijack arbitrary service principals across an organization’s tenant, enabling full privilege escalation.
The flaw allowed accounts with only the Agent ID Administrator role to take ownership of service principals unrelated to AI agent identities, add credentials and authenticate as those principals, effectively granting unauthorized access to elevated directory roles and sensitive Microsoft Graph permissions.
Understanding the Vulnerability
Microsoft Entra ID’s Agent Identity Platform, currently in preview, provides AI agents with their own identities in the directory so they can be governed and secured like any other principal. To manage this new control plane, Microsoft introduced the Agent ID Administrator role, which was documented as being scoped strictly to agent-related objects such as agent identities, agent users, and blueprints.
However, due to the shared underlying architecture between agent identities and standard service principals—both of which are implemented as service principal objects in Entra ID—a critical scoping gap emerged. Researchers from SilverFort found that this gap allowed the Agent ID Administrator role to modify ownership of any service principal in the tenant, not just those associated with agent identities.
How the Exploit Worked
An attacker holding only the Agent ID Administrator role could assign themselves as the owner of a targeted service principal. Once ownership was established, they could generate new credentials for that principal and use them to authenticate as the identity. If the compromised service principal held elevated privileges—such as directory roles or access to sensitive resources—the attacker could escalate their access across the entire tenant.
Response and Mitigation
Microsoft acknowledged the vulnerability and confirmed that it has been fixed across all cloud environments. The Agent ID Administrator role can no longer manage owners of non-agent service principals, closing the scope gap that allowed the privilege escalation path.
Broader Implications
While the Agent ID Administrator role is not yet widely used, most tenants have at least one privileged service principal, and many organizations are already using agent identities at significant scale. As adoption grows, the incident underscores the risks of introducing new control planes built on existing directory primitives without sufficient boundary validation.
Security researchers emphasized that this was not a misconfiguration but a fundamental identity control failure, where a role intended for a narrow purpose became a vector for tenant-wide compromise due to architectural overlap in the identity model.
