"That's full service principal takeover," security researcher Noa Ariel said.
Agent ID Administrator role and the agent identity platform
Microsoft introduced a privileged built-in role named Agent ID Administrator as part of an agent identity platform designed to manage AI agent identities. The platform is intended to let AI agents authenticate securely, access required resources, and discover other agents. Silverfort, an identity security platform, reported that the role's permissions were broader than intended and could be abused.
How the privilege escalation worked
Silverfort's findings show that a user assigned the Agent ID Administrator role could become an owner of arbitrary service principals — not only agent-related identities — and then add their own credentials to those service principals to authenticate as them. The ability to assign ownership and inject credentials into a service principal is the mechanism Silverfort identified as enabling what Ariel called "full service principal takeover."
Risk profile: what an attacker could gain
Ownership of a service principal permits an attacker to operate with the service principal's existing permissions. Silverfort highlighted that the risk depends on the targeted service principal's privileges. When a service principal holds elevated authorities — particularly privileged directory roles or high-impact Microsoft Graph application permissions — taking over that principal can enable broader control over a tenant. "In tenants where high-privileged service principals exist, it becomes a privilege escalation path," Ariel warned.
Microsoft's patch and disclosure timeline
Silverfort disclosed the issue to Microsoft on March 1, 2026. Microsoft rolled out a fix across all cloud environments on April 9, 2026, to remediate the role's scope overreach. After the update, attempts to assign ownership of non-agent service principals using the Agent ID Administrator role are blocked and return a "Forbidden" error message.
Operational steps advised by Silverfort
Silverfort emphasized this episode as an architectural caution: when roles are layered on top of shared identity foundations without strict scoping, access can unintentionally extend beyond intended boundaries. The company recommended practical mitigations organizations should adopt immediately:
- Monitor sensitive role usage, with particular attention to roles that can change service principal ownership or create credentials.
- Track and log service principal ownership changes so suspicious assignments can be detected and investigated.
- Secure privileged service principals by limiting who can modify their configuration and by enforcing least privilege.
- Audit credential creation on service principals to identify unauthorized additions that would enable impersonation.
What this means for security teams, enterprises, and adversaries
Technologists and security teams: Expect to review role scoping for new identity types built on existing primitives and to increase monitoring for ownership and credential changes on service principals.
Affected enterprises and procurement leaders: Organizations that host high-privileged service principals will need to reassess who holds Agent ID Administrator (and similar) roles and ensure those roles cannot reach beyond their intended scope.
Adversaries and threat actors: The vulnerability underscored an attractive escalation route where non-human identities and shared identity foundations intersect; the window for that specific path has been closed by the April 9 remediation.
The episode is a clear reminder that introducing new, AI-focused identity types atop existing identity primitives changes the threat model. When role permissions are applied on shared foundations without strict scoping, access can extend beyond intent — and, as Silverfort showed, that gap can be enough to turn a convenience for agent management into a route for tenant-wide escalation.
Original reporting: https://thehackernews.com/2026/04/microsoft-patches-entra-id-role-flaw.html
