Microsoft Built a New Entra ID Role for AI Agents. Silverfort Discovered the Role Could Take Over Any Service Principal in the Tenant, Including Privileged Ones the Role Was Never Supposed to Touch. Ninety-Nine Percent of Tenants Are Vulnerable to the Underlying Pattern. The AI Identity Platform Was Built on Standard Service Principal Primitives Without Strict Scoping.

WHAT SILVERFORT FOUND

The Microsoft Agent Identity Platform is a preview feature in Entra ID that gives AI agents their own identity primitives: blueprints, agent identities, and agent users. The design lets organizations govern AI agents the same way they govern other principals in their directory. To manage that new control plane, Microsoft introduced the Agent ID Administrator role.

According to Microsoft's documentation, the role is scoped to manage agent-related objects only. Silverfort researchers Noa Ariel and Yoav Shchori found that the documented scope and the actual behavior diverged. A user with only the Agent ID Administrator role could update the owner of any service principal in the tenant, not just agent-related ones. Once ownership was assigned, the user could add new credentials to the service principal and authenticate as that application. The result is full service principal takeover from a role marketed as agent-scoped.

The mechanism is straightforward and architectural. Agent identities in Entra ID are built on top of the standard application and service principal primitives that have existed in Azure AD for years. The Agent ID Administrator role was implemented to manage agent identities by interacting with those underlying primitives. The implementation did not strictly scope which service principals the role could touch. The shared foundation between agent identities and ordinary applications became the path for the role's permissions to extend beyond their intended boundary.

Silverfort demonstrated the impact with a test user assigned only the Agent ID Administrator role. The test user took over a privileged non-agent service principal that had been assigned the Global Administrator role. After taking ownership and adding credentials, the test user authenticated as that service principal. Privilege escalation from Agent ID Administrator to Global Administrator, executed within Microsoft's documented permission boundaries.

WHY THIS MATTERS BEYOND THE PATCH

Microsoft's response was prompt and complete. Silverfort disclosed on March 1. Microsoft confirmed on March 26. The patch shipped April 9. The Agent ID Administrator role can no longer manage owners of non-agent service principals. Anyone running Entra ID today is no longer affected by this specific vulnerability.

The architectural lesson outlives the patch. Two findings in Silverfort's tenant analysis matter independent of the Agent ID Administrator role. First, about 99% of tenants have at least one privileged service principal. Second, over half of tenants already use agent identities, and of those, nearly half have more than 100 agent identities deployed. The substrate for service principal takeover attacks exists everywhere. AI agent identity is being adopted at scale. The two are converging in real environments before the security model is mature.

The Entra UI did not visually flag the Agent ID Administrator role as "privileged" before the fix. IT administrators assigning the role to manage AI agent identity operations had no in-product warning that the role carried tenant-wide service principal management capabilities. Silverfort noted this discrepancy between the UI and the documented behavior is also being corrected. The lesson is not that Microsoft made a unique mistake. The lesson is that any new identity construct built on top of standard service principal primitives needs strict scoping verification before it ships, not after.

THE BROADER PATTERN

This is the latest entry in a sequence we have been documenting all month. AI infrastructure is being built and shipped faster than the security review of that infrastructure can keep pace. The vulnerabilities we have covered share a common shape. Functionality designed for AI use cases is built on top of pre-existing foundations whose security models were never extended to handle the new use cases. The gap between the new construct and the underlying primitives is where the bugs live.

On April 21 we covered OX Security's research on architectural RCE in Anthropic's Model Context Protocol, where the protocol's design choices created remote code execution exposure across 200,000 vulnerable servers. On April 25 we covered the LMDeploy SSRF vulnerability that was exploited within thirteen hours of disclosure, with the attacker building an exploit from advisory text alone. On April 26 we covered GlassWorm's third wave on the Open VSX marketplace that powers Cursor and Windsurf. Today's Entra ID story is the same pattern at the identity layer. AI agent identity primitives built on top of standard service principals inherited the security boundaries of standard service principals without inheriting the scoping discipline that experience with those primitives had developed.

The security industry spent the 2010s learning that microservices, container orchestration, and cloud IAM each required their own threat models. Each of those infrastructure shifts produced years of vulnerability work as practitioners learned the new failure modes. AI agent identity is the next shift. The Agent ID Administrator vulnerability is an early signal of what that learning curve looks like.

INDICATORS AND TIMELINE

WHAT ORGANIZATIONS SHOULD DO