A recently disclosed vulnerability in Microsoft Entra ID (formerly Azure AD) allowed users with a new Agent ID Administrator role to take over arbitrary service principals, potentially leading to tenant-wide privilege escalation. The issue, discovered by researchers at Silverfort, highlights the growing security challenges around managing non-human identities and AI agents in modern cloud environments.
Agent identity in Microsoft Entra ID and the Agent ID Administrator role
To support AI agents and automated services, Microsoft introduced an agent identity platform inside Microsoft Entra ID. Unlike human users, these identities represent software components or services that must authenticate, access resources, and interact with other agents within a tenant in a controlled way.
The built-in Agent ID Administrator role was designed to manage the full lifecycle of these AI agent identities: creation, update, key and credential management, and decommissioning. By design, its permissions were meant to apply only to agent-specific identities, not to all application identities in the directory.
How the vulnerability enabled unauthorized service principal control
Silverfort’s analysis uncovered a flaw in how the scope of the Agent ID Administrator role was defined. Due to this misconfiguration, a user holding this role could operate far beyond AI agent identities and interact with regular service principals used by applications and services.
From managing AI agents to full service principal takeover
According to Silverfort researcher Noah Ariel, an Agent ID Administrator could assign themselves as an owner of any service principal in the tenant, including those unrelated to AI agents. Once ownership was obtained, the administrator could then add new credentials—such as client secrets or certificates—allowing them to authenticate as that service principal.
This effectively enabled a full takeover of the service principal, including all of its existing permissions in Microsoft Entra ID. If the compromised service principal was highly privileged—for example, holding directory roles or powerful Microsoft Graph permissions—the attacker could use it as a channel for far-reaching privilege escalation and expanded control over the tenant.
Why compromised service principals are so dangerous
In modern cloud architectures, service principals are widely used for CI/CD pipelines, automation jobs, SaaS integrations, backup systems, and critical business applications. For operational convenience, these identities often hold broader and more persistent permissions than individual user accounts.
Once a service principal is compromised, an attacker gains access to everything that application can do: reading and modifying directory configuration, accessing mailboxes and calendars, manipulating files in cloud storage, or retrieving secrets from key vaults. Industry reports such as the Verizon Data Breach Investigations Report and various cloud incident analyses consistently show that abuse of credentials and overprivileged service accounts is a common factor in major breaches.
When such an identity also has the ability to manage other identities, roles, or application registrations, it becomes a durable foothold for lateral movement, persistence, and stealthy long-term control of cloud resources.
Microsoft’s response and remediation in Microsoft Entra ID
Silverfort reported the vulnerability to Microsoft on 1 March 2026 under a responsible disclosure process. After investigation, Microsoft rolled out a fix across its cloud environments on 9 April 2026, correcting the oversized scope of the Agent ID Administrator role.
Post-patch, attempts by an Agent ID Administrator to take ownership of a non-agent service principal are now blocked, returning a 403 Forbidden error. This enforcement prevents the role from being used to hijack regular application identities and limits its capabilities to the intended AI agent identity domain.
Lessons for role design and securing non-human identities
The incident underscores the importance of rigorously validating role scopes and permissions whenever new identity types—such as AI agents—are built on top of existing constructs like service principals. Non-human identities, including service accounts, microservices, containers, robots, and automation tools, are rapidly outnumbering human users in many organizations, increasing the attack surface.
When privileged roles for these identities are mapped onto shared directory components without strict separation, any mistake in defining scope can lead to unintended access expansion. Combined with weak governance over high-impact service principals, such vulnerabilities significantly raise organizational risk.
1. Monitor use of sensitive roles. Closely track actions involving service principal ownership, credential changes, and role assignments in Microsoft Entra ID. Unusual activity tied to agent-related roles should trigger alerts in your SIEM or monitoring platform.
2. Track changes in service principal ownership. Treat any change of owner, especially outside a small set of trusted administrators, as a high-value event. Ownership often implies the ability to add credentials or modify permissions.
3. Harden privileged service principals. Apply the principle of least privilege, regularly review assigned roles and Microsoft Graph permissions, and store secrets and keys only in secure vaults with tight access controls and rotation policies.
4. Audit service principal credential lifecycle. Ensure that authentication and audit logs in Microsoft Entra ID and your SIEM clearly show when keys, secrets, and certificates are created, updated, or deleted, enabling rapid detection of anomalous changes.
The emergence of AI agents and the rapid growth of non-human identities make cloud identity governance a strategic priority. The Microsoft Entra ID Agent ID Administrator vulnerability is a clear reminder that any new feature built on existing identity primitives must undergo thorough permission-scoping and security review. Organizations should not rely solely on vendor patches, but also establish layered access controls, continuous monitoring, and regular reviews of roles and service principals to maintain a resilient cloud security posture.
