A scoping flaw in Microsoft's new Agent ID Administrator role let any holder claim ownership of arbitrary service principals — including ones wired to Global Admin. Microsoft has shipped a fix, but the underlying lesson about non-human identity sprawl is the part that should keep you up.
Microsoft quietly closed a nasty privilege escalation path in Entra ID this month, and most defenders missed it because the affected role was new enough that very few people had written detections for it yet. The Agent ID Administrator role — a directory role introduced alongside the Microsoft Agent Identity Platform preview to manage AI agent identities — turned out to grant far more authority than its name suggested. For a window of time, anyone holding it could quietly seize ownership of essentially any service principal in the tenant, including service principals already bound to the most powerful directory roles. From there, the path to full tenant compromise was a short walk.
Microsoft has corrected the behavior across all clouds. The investigative work was published by Silverfort. The takeaway is bigger than one role.
The role that did too much
The Agent Identity Platform is Microsoft's emerging framework for giving AI agents first-class directory identities — blueprints, agent identities, and agent users. To administer those non-human principals without handing out Application Administrator or Cloud Application Administrator (which would over-grant), Microsoft introduced a narrower role: Agent ID Administrator. The published documentation describes it as scoped strictly to agent objects.
The catch is that agent identities are not really a separate identity primitive. Underneath, they are built on the same service principal and application objects that have powered Entra ID for a decade. That implementation choice is sensible from a platform engineering standpoint and disastrous from an authorization standpoint. The role's permission set included the ability to manage owners on agent identity objects — but the API call that backed it operated against the underlying servicePrincipal type with no filter to verify the target was actually an agent. The boundary existed in the documentation. It did not exist in the code.
How the takeover worked
The exploitation primitive was almost embarrassingly direct.
A user holding the Agent ID Administrator role could call the standard service principal owners endpoint and add themselves as an owner of any service principal in the tenant. The API accepted the call because, from its perspective, the caller had the right delegated permission. Once added as an owner, the attacker could mint new client secrets or certificates against the target application — owners are explicitly allowed to manage credentials. With those credentials, they could authenticate as the target service principal in any context that accepted client credential flow.
If that target service principal was a low-value app, the impact was contained. If it was a service principal already assigned a privileged directory role — and most mature tenants have at least a handful, sitting under integrations for backup software, IdP federation, lifecycle automation, security tooling, or legacy line-of-business apps — the attacker now operated as a Global Administrator, Privileged Role Administrator, or whatever role the compromised principal carried, with no further interaction required from a human.
The original role assignment that started the chain was not flagged as privileged in the Entra UI, because the documentation treated Agent ID Administrator as a narrow, low-risk role. That mislabeling is part of what makes this class of bug so corrosive: defenders who reviewed privileged role membership using the platform's own indicators would not have seen the path.
Why this matters beyond the patch
The specific bug is fixed. Microsoft's update prevents the Agent ID Administrator role from modifying ownership on service principals that are not agent objects. If you operated a tenant with the preview enabled, your audit logs from the affected window are worth a careful read — successful addOwner or addPasswordCredential actions on non-agent service principals by Agent ID Administrator role holders are the signal you want.
The structural problem is not fixed, because it cannot be fixed in a patch. Service principal ownership is one of the most powerful and least monitored privileges in a Microsoft 365 environment. An owner can issue new credentials silently. Those credentials carry the full permission surface of the application — Graph permissions, directory roles, federated trust relationships, conditional access exemptions. Many of those permissions were granted years ago by administrators who no longer work at the company, in response to deployment guides that asked for "App Administrator" because that was the easiest way to get the integration running on a Friday afternoon.
Every tenant we assess at Maverc has at least one of these. Most have several. They are the soft underbelly of the modern identity perimeter, and any new role, feature, or preview that introduces a path to manipulate them deserves the same scrutiny as a new privileged role being added to Active Directory.
What to do this week
The remediation work is not exotic. It is the kind of hygiene that pays off every time a vulnerability like this lands.
- Inventory privileged service principals. Pull every service principal in the tenant and cross-reference against the directory role assignments and the high-impact Microsoft Graph application permissions (Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All, Application.ReadWrite.All, and the equivalents for Exchange, SharePoint, and Teams). The Silverfort writeup includes an Azure CLI script that uses Graph beta and jq to enumerate service principals holding privileged directory roles — adapt and run it as a baseline check.
- Lock down ownership. For any service principal with elevated permissions, the owner list should be intentional, short, and reviewed quarterly. Remove individual user owners where you can; prefer ownership by a tightly governed PIM-eligible group.
- Alert on credential and ownership changes. The Entra audit log events you want are Add owner to service principal, Add service principal credentials, and Update application — Certificates and secrets management. Wire them into the SIEM with a filter that escalates when the affected principal carries a privileged role or high-risk Graph permission. These should not be quiet events.
- Treat preview features as production risk. The Agent Identity Platform is a preview, but it was deployable into production tenants. Previews come with weaker documentation, weaker tooling, and less-mature internal review. Pilot them in isolated tenants before enabling broadly, and assume the role definitions are subject to change without notice.
- Map your AI agents like you map your humans. The next twelve months will see more directory roles built specifically to govern AI agents. Each one will live next to your existing privileged roles. Bring them into the same governance model — PIM, access reviews, just-in-time elevation, conditional access — that you apply to human administrators.
How Maverc helps
Identity hardening for Microsoft tenants — Entra ID, Microsoft 365, and the GCC and GCC High variants used across the defense industrial base — is a core Maverc engagement. We run inventories of privileged human and non-human identities, build the detection coverage for ownership and credential abuse, and help clients shrink the standing privilege footprint that makes a flaw like this one so dangerous in the first place.
If you are not sure how many privileged service principals live in your tenant today, that is the question to start with. The right answer is almost never "I do not know," and almost never "more than ten."
