Microsoft fixes Entra ID role flaw that could let admins take over service principals

Microsoft has fixed a privilege escalation issue in Microsoft Entra ID that could let users with the Agent ID Administrator role take over service principals outside the role’s intended scope.

The flaw was discovered by Silverfort and affected the way the Agent ID Administrator role interacted with service principals. The role was designed to manage AI agent identities, but researchers found it could also be used to become the owner of unrelated service principals.

That matters because service principals often power automation, integrations, security tools, CI/CD pipelines, and other high-trust cloud workflows. If one of them has elevated permissions, taking control of it can give an attacker access far beyond the original role.

What happened in Microsoft Entra ID

The issue involved Microsoft’s Agent ID Administrator role, a built-in Entra ID role introduced for managing agent identities. Microsoft describes the role as one used to manage agent blueprints, agent service principals, agent identities, and agentic users.

Silverfort found that the role did not stay limited to those agent-related objects. A user with only Agent ID Administrator permissions could add themselves as an owner of arbitrary service principals in the tenant, even when those service principals had nothing to do with AI agents.

After gaining ownership, the user could add credentials to the service principal and authenticate as it. From there, the user could operate with whatever permissions that service principal already had.

At a glance

Item	Details
Affected platform	Microsoft Entra ID
Role involved	Agent ID Administrator
Issue type	Privilege escalation and service principal takeover
Researcher	Silverfort researcher Noa Ariel
Reported to Microsoft	March 1, 2026
Fix confirmed	April 9, 2026
Current status	Fixed across Microsoft cloud environments

Why service principal takeover is dangerous

A service principal acts as an application identity inside a Microsoft Entra tenant. It can receive permissions, access APIs, run automated workflows, and connect to other cloud resources.

In many enterprise environments, service principals hold powerful Microsoft Graph permissions or directory roles. Some can manage applications, read or write directory data, change access policies, or support critical business systems.

If an attacker takes over one of those identities, the impact depends on the permissions already assigned to it. In a poorly monitored tenant, this can turn a narrow administrative role into a broader path toward tenant compromise.

How the flaw worked

The Agent ID Administrator role exists because Microsoft Entra Agent ID treats AI agents as managed identities inside Entra ID. Microsoft says agent identities are special service principals that help AI agents authenticate and request tokens.

That shared foundation created the risk. Agent identities rely on service-principal-like structures, and the role needed permission to manage owners of agent-related objects. Silverfort found that those ownership permissions could reach beyond the intended agent boundary.

The researchers said the issue did not apply the same way to application objects. The problem appeared on the service principal surface, where ownership changes created the takeover path.

Microsoft has already patched the issue

Silverfort reported the behavior to Microsoft Security Response Center on March 1, 2026. Microsoft opened the case on March 3 and later confirmed the behavior.

The fix reached a pre-release stage on April 4, and Microsoft confirmed full rollout on April 9. After the patch, attempts to use Agent ID Administrator permissions to assign ownership over non-agent service principals are blocked.

Silverfort said Microsoft also acknowledged the issue through its disclosure program and awarded a bug bounty.

Why this matters for AI agent security

The issue shows how AI agent identity systems can inherit risks from existing identity components. AI agents need identities, permissions, owners, and lifecycle controls, but these controls must stay tightly scoped.

Microsoft’s Agent Identity Platform is still in preview, but its roles are already visible and assignable. That means administrators should review who has these roles, even if their organization has only started testing agent-based workflows.

Silverfort also said the Agent ID Administrator role was not widely used yet, but many tenants already contain privileged service principals. As AI agent adoption grows, role scoping and ownership monitoring will become more important.

What administrators should check now

• Review all users assigned the Agent ID Administrator role.
• Audit service principals with privileged directory roles.
• Check service principals with sensitive Microsoft Graph permissions.
• Monitor ownership changes on service principals.
• Review new credentials added to service principals.
• Limit privileged service principals to only the access they need.
• Use separate identities for different automation and AI agent workloads.

Enterprise impact

The flaw has already been fixed, so organizations do not need to apply a separate patch. However, the discovery still matters because it exposes a common weakness in identity management: powerful non-human identities often receive less scrutiny than user accounts.

Service principals can sit quietly in a tenant for years. They may support production systems, security products, internal tools, or third-party integrations. If their permissions grow over time without review, they can become high-value targets.

For security teams, this incident is a reminder to treat AI agent identities, app identities, and automation accounts as part of the same identity attack surface. Human users are no longer the only accounts that need strict monitoring.

FAQ