Silverfort researchers Noa Ariel and Yoav S disclosed details on April 27 of a scope-overreach flaw in Microsoft Entra ID’s new Agent ID Administrator built-in role. Tracked as CVE-2026-35431, the bug let any account holding the role take ownership of arbitrary service principals across the tenant — including ones with no relationship to AI agents at all — then add credentials and authenticate as the principal. In a tenant where any privileged service principal exists (most do), that’s a tier-0 escalation path, and Silverfort demonstrated hijacking a service principal that held the Global Administrator role.

Microsoft introduced Agent ID Administrator earlier this year as part of the Microsoft Agent Identity Platform (Preview) — the Entra-side plumbing for managing identities of AI agents, copilots, and similar autonomous workloads. On paper the role was scoped to “agent-related objects” (Blueprints, Agent Identities, the new agent primitives). In practice, those agent identities are implemented on top of the same primitive every other workload identity in Entra rides on: the service principal. The role’s permission set let it manage owners of service principal objects, but the filter that was supposed to restrict that to agent-backed service principals didn’t exist. Microsoft Graph and az ad sp happily let role holders set themselves as owner of the AAD Connect Sync principal, the Exchange Online RBAC principal, third-party app registrations, and anything else exposed in the directory.

The attack chain

According to Silverfort’s writeup, the full takeover takes three Graph calls:

  1. Enumerate. The attacker (already holding the Agent ID Administrator role — assigned, social-engineered, or recovered from a compromised lower-privileged account) queries /v1.0/servicePrincipals filtering for appRoles/any(r:r/value eq 'RoleManagement.ReadWrite.Directory') or similar privilege markers, looking for service principals that hold high-impact Microsoft Graph application permissions or Azure RBAC roles.
  2. Take ownership. A POST /v1.0/servicePrincipals/{id}/owners/$ref adds the attacker’s user object as an owner of the chosen target. The role check that should have rejected this for non-agent SPs was missing.
  3. Inject credentials. As an owner the attacker can POST /addPassword (or upload a certificate via addKey) to the service principal, then immediately authenticate via the client-credentials flow as that principal — inheriting every Graph permission, every Azure RBAC role, and every directory role the SP holds.

There is no audit log entry that distinguishes “owner added by Agent ID Administrator role” from “owner added by Application Administrator.” Detection has to come from anomaly hunting on Add owner to service principal events in AuditLogs correlated against role assignment of the actor.

Disclosure timeline

  • Feb 24, 2026 — Silverfort discovers the scope gap during a routine review of new Entra built-in roles.
  • Mar 1, 2026 — Reported to Microsoft Security Response Center.
  • Mar 26, 2026 — MSRC confirms the vulnerability.
  • Apr 9, 2026 — Microsoft rolls out the fix to all cloud environments. Owner-add operations from the Agent ID Administrator role against non-agent service principals now return 403 Forbidden.
  • Apr 27, 2026 — Silverfort publishes the technical writeup; CVE-2026-35431 assigned.

Impact

The role is opt-in and not yet broadly assigned — Agent Identity Platform is still in Preview — so the population of currently exposed tenants is small. But anyone who turned on the preview, assigned the role to a developer or a delegation-of-duty admin, and trusted the documentation that it was “agent only” was running with what amounted to an unannounced second Application Administrator role. Microsoft’s documentation for the role didn’t list service principal ownership management as in-scope.

There is no on-prem fix to apply — this was a cloud-side authorization bug and the patch lives in the Entra control plane.

What to do now

  • Patch is automatic. Verify the fix took by, as a non-Global-Administrator user holding only Agent ID Administrator, attempting to add yourself as an owner of any non-agent SP via Graph. Expect Authorization_RequestDenied.
  • Audit assignment of the Agent ID Administrator role in your tenant. Anyone who held it between role GA and April 9 had latent Application Administrator-equivalent power.
  • Hunt for retroactive abuse. Pull AuditLogs for Add owner to service principal and Update application – Certificates and secrets management between February 2026 and April 9, filter by actors who held Agent ID Administrator, and review every target SP for ownership or credential additions you didn’t expect.
  • Treat all Entra “agent” / “AI” preview roles as suspect until they have weeks-old documentation and a few independent reviews. The pattern Silverfort caught — new role layered on top of an old primitive without re-deriving the scope filter — is the same one that produced CVE-2025-55241 (Entra ID cross-tenant token forgery) last September. The agent-identity surface is brand new and is going to grow more of these.

References