Microsoft just patched a built-in Entra ID role they shipped as scoped to "agent identities" — and which, in practice, let anyone holding that role take over almost any service principal in the tenant. The fix rolled out across all clouds on April 9. The disclosure went public last week. If your org turned on Microsoft's agent identity platform in the last quarter and assigned the role anywhere along the way, this is a detail to chase down before your next audit.
The role is Agent ID Administrator. Microsoft introduced it as part of the agent identity platform — the lifecycle management story for AI agents in Entra: blueprints, agent identities, the rest of it. The documented scope was tight: agent objects, agent users, agent blueprints. The actual scope, until April 9, was much wider. Anyone holding the role could become owner of any service principal in the tenant — agent or not — and as soon as they were owner, mint a credential and authenticate as that principal.
That second step is the takeover primitive. Silverfort's writeup puts it bluntly: "Ownership is a takeover primitive — become owner, then add a secret and authenticate as that service principal." If the principal you took over had elevated Graph permissions or held a directory role, you now hold those permissions too. In tenants where any privileged service principal exists — Silverfort says 99% of organizations have at least one — that becomes a tenant-takeover path.
The mechanics, briefly
Two API permissions did the work:
- microsoft.directory/agentIdentities/owners/update
- microsoft.directory/agentIdentityBlueprintPrincipals/owners/update
Both should have been gated by an "is this an agent-backed object" check. They weren't. The check existed for application objects — modifying an application directly was correctly blocked. But the authorization layer for service principal ownership didn't enforce the same boundary. So the role couldn't change the application, but it could hand itself the keys to the principal that authenticates as the application. Microsoft's patch closes the gap: as The Hacker News reported, ownership writes against non-agent service principals now return a "Forbidden" response.
The disclosure timeline reads like a clean responsible-disclosure case. Silverfort's Noa Ariel found the flaw on February 24, reported it to MSRC on March 1, MSRC confirmed the behavior on March 26, and the patch was rolling by April 4. Six weeks from report to global rollout is a reasonable cadence — maybe a little fast, given the blast radius.
Why this is the more interesting story than most agent-security posts
Two reasons this matters past the headline.
First, it lands on the trust model that everyone shipping agentic systems is implicitly buying into. The whole pitch of "agent identity" — and not just Microsoft's — is that agents are first-class principals with scoped permissions, that their access can be governed independently of whatever else lives in the directory. That pitch only holds if the boundary is real. Here the boundary was a line in the docs. Underneath, agent identities are service principals — the same primitive that powers every app registration, every workload identity, every CI/CD service account in the tenant. Build a new role on top of that primitive, miss one ownership-check edge case, and "agent-scoped" becomes "directory-scoped" without anybody noticing. Ariel's own framing: "When role permissions are applied on top of shared foundations without strict scoping, access can extend beyond what was originally intended." That is the architectural lesson; the bug is the proof.
Second, this is a preview of the bug class to expect for the next two years across every vendor's agent identity story. AWS, Google, Okta, ServiceNow, the rest — all of them are going to ship "agent identity" SKUs that bolt on top of the IAM primitives they already had. The boundaries are going to be subtle, and most security teams are not yet auditing role definitions for this kind of scope-overreach. CSO Online's writeup calls the architectural confusion explicitly: since agent identities are built on the same technical primitives as applications, the boundary between "agent" and "non-agent" objects wasn't properly defined. Expect that exact sentence to be rewritten about other vendors over the next year.
What to do this week
If your tenant uses Entra ID and you have the agent identity platform turned on, this is a good week to do four things.
- Audit who has Agent ID Administrator. The patch closes the takeover path forward, but anyone who had the role between role launch and April 9 had the capability. Read your audit logs for applicationOwner add events on non-agent service principals during that window. If you find any you can't account for, treat them as suspect credentials and rotate.
- Don't trust role names as scope statements. "Agent ID Administrator" sounded scoped. It wasn't. From here forward, treat any new role labeled with a product surface — agents, copilots, workflows — as a suggestion about scope. Verify against the actual permission set and the objects those permissions can touch.
- Inventory your privileged service principals. Per Silverfort, more than half the tenants they looked at have agent identities deployed at scale, with hundreds per tenant. Service principals with directory roles or app permissions like RoleManagement.ReadWrite.Directory are the high-value targets. Review the list. Demote the ones that don't need that level of access. Most don't.
- Push your vendor on the boundary, not the brand. If a sales pitch tells you a role is "scoped to agents" or "limited to copilots," ask: scoped at the API surface, or scoped at the documentation level? It is not a snarky question. It is the question.
The throughline
The first post in this series was about getting your own team to trust an agent. The second was about getting external customers to trust one. The third — last week's — was about when not to make an agent at all, and use cron and bash instead. The bug Microsoft just patched is the next failure mode in the same chain: the identity layer that the agent inherits from your existing platform is older, broader, and shares more primitives than the marketing implies. The trust model for an agent is the trust model for a service principal, plus a label. Sometimes the label is enforced. Sometimes it isn't.
Until your security tooling can audit "what can this role actually do" instead of "what is this role named," assume the label is decorative. Microsoft just gave us the worked example. The next vendor will too.
