when an "agent-only" admin role isn't
silverfort's noa ariel published a finding this week that's worth more than the patch it triggered. microsoft's entra agent id administrator role, introduced for the preview agent identity platform that gives ai agents their own identities in entra id, could take ownership of any service principal in the tenant. not just agent-related ones. become owner, add a credential, sign in.
the role definition id is `db506228-d27e-4b7d-95e5-295956d6615f`. on paper, microsoft's docs scoped it to "agent-related objects only." in practice, the action `microsoft.directory/agentIdentities/owners/update` checked whether the role could change owners on agent objects, but didn't strictly limit which objects qualified as "agent-backed." the permission leaked onto the general service-principal plane.
silverfort's own description: "we discovered that accounts with only the agent id administrator role could take over arbitrary service principals, including ones that have nothing to do with agent identities, by becoming owner, then adding credentials and authenticating as that principal."
the disclosure timeline: vulnerability identified february 24, msrc report march 1, fix shipped april 4 to pre-release, fully rolled out april 9. mainstream press picked it up april 28. no cve. no microsoft advisory. silent fix.
why this matters more than the patch
every identity provider racing to ship ai-agent identities is structurally exposed to this class of failure. okta is doing it. auth0 is doing it. ping is doing it. google workspace cloud identity announced it last week. they're all building new primitives ("agent identity," "machine-bound identity," "non-human-identity") on top of existing object substrates ("service principals," "service accounts," "machine accounts"). when the new role's scoping logic checks the new primitive but not the underlying substrate, you get this exact bug.
silverfort's tenant scan: about 99% of customer tenants have at least one privileged service principal. a bit more than half use agent identities, with almost half of those tenants running 100+ agent identities. where both conditions exist (and that's most enterprise environments), the agent id administrator role is a privilege-escalation primitive that microsoft's docs explicitly said it wouldn't be.
the entra ui also didn't mark agent id administrator as "privileged" though the docs did. that's a separate scoping bug at the documentation-vs-ui layer, and microsoft has committed to fixing it.
what soc teams should do
three actions, in priority order:
- retroactive auditlog forensics. query `auditlogs` for `add owner to service principal` and `add credentials to service principal` events between agent id administrator role introduction (preview ga window) and april 9. flag any case where the actor held only the agent id administrator role and the target service principal was not an agent identity. these are candidate exploited cases. microsoft did not push customer notifications about the fix, so this is on you.
- enumerate privileged service principals. silverfort's blog includes the exact azure cli + jq snippets. the two checks are: which service principals hold privileged directory roles (use `isPrivileged` on `roleDefinitions` via the graph beta api), and which hold high-impact graph permissions (`Directory.ReadWrite.All`, `RoleManagement.ReadWrite.Directory`, `Application.ReadWrite.All`, etc). these are the targets a successful exploit would have gone after first.
- validate role-scope enforcement, don't just read docs. assign agent id administrator to a low-privilege test account in a test tenant. attempt operations against non-agent service principals. log the success/failure outcomes. if the test account succeeds at any operation the docs say it can't perform, you have a fresh unscoped-role finding worth a vendor disclosure.
the substrate problem, generalized
the lesson is wider than entra. when threat-modeling ai-agent identity infrastructure in 2026:
- assume the role-scope description in vendor docs does not match actual enforcement. test directly.
- look at the underlying object substrate (service principal, service account, machine account) and ask: does the new ai-agent-specific role grant any operations that the underlying object type would otherwise require a higher-privileged role to perform?
- if yes, the new role is a privilege-escalation primitive whether the vendor advertised it that way or not.
ai-agent runtime security is a 2026 line item with two distinct attack surfaces: identity-layer (silverfort's finding) and execution-layer (yesterday's comment-and-control prompt injection finding). they need separate threat models. they need separate testing programs. they need separate budgets.
most importantly, the silverfort fix is in. but the class of failure isn't. expect more findings in this shape across the rest of the identity-provider field through q3.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you're threat-modeling AI-agent identity infrastructure.
Related reading
• Comment and Control: Prompt Injection via Ordinary GitHub Comments
• Vercel x Context.ai, Week Two: Trend Micro Names the OAuth Gap
• Your AI Infra Patch Window Is Now Sub‑Day
Sources
• Silverfort: Agent ID Administrator scope overreach (primary research)
• Security Affairs: Microsoft fixes Entra ID flaw enabling privilege escalation
• The Hacker News: Microsoft Patches Entra ID Role Flaw That Enabled Service Principal Takeover
• SC Media: Microsoft patches Entra ID bug that let AI agents escalate privileges
• CSO Online: Microsoft patched an 'agent-only' role that was not