Apr 29, 2026 · 8 min read
Microsoft Built an Admin Role Just for AI Agents—Researchers Showed It Could Take Over Global Admin Accounts in 99% of Companies
A built in Entra ID role meant to manage AI agent identities had a scope error. Silverfort proved it could take ownership of any service principal in a tenant—including Global Administrator. Microsoft fixed it on April 9. The implications for how enterprises govern AI agents have not gone away.
What Microsoft Built
As enterprises started deploying AI agents at scale, Microsoft introduced a new directory role in Entra ID called Agent ID Administrator. The role was meant to give a dedicated team the ability to create, configure, and retire the identities used by AI agents—new objects called Blueprints and Agent Identities. The pitch was straightforward: agents need their own identity lifecycle, and you do not want to grant Global Administrator just to manage them.
In a tenant running 100 active agents, that role looks like good least privilege design. The problem, according to research disclosed by Silverfort on April 27, 2026, is that the role's permission boundary did not match its name.
The Scope Gap
Silverfort researchers Noa Ariel and Yoav S. discovered that the Agent ID Administrator role could modify ownership on almost any Application Service Principal in a tenant—not just the ones tied to AI agents. Service principals are the identities that applications use to authenticate to Microsoft 365, Azure, and any service registered in Entra ID. They are the silent backbone of enterprise SaaS authentication, and many of them carry highly privileged API permissions.
Once an attacker held the Agent ID Administrator role, the path to full tenant takeover was four steps:
- Enumerate. Use Microsoft Graph or Azure CLI to list service principals carrying high impact permissions like RoleManagement.ReadWrite.Directory or Application.ReadWrite.All.
- Assume ownership. Add yourself as an owner of the target service principal—an operation the role allowed but should have blocked.
- Inject credentials. Add a new client secret or certificate to the application registration. Owners can do this without any other approval.
- Authenticate. Sign in with the new credentials. You now hold the application's permissions, including any directory roles it had.
Silverfort demonstrated the chain end to end against a Global Administrator account. Once you have credentials for an application that holds Global Admin, the rest of the tenant is yours: every mailbox, every SharePoint site, every Teams channel, every conditional access policy.
Why 99% Matters
Silverfort's prevalence numbers are the part security teams need to internalize. About 99% of Entra tenants studied have at least one privileged service principal. More than half of organizations have already deployed AI agent identities, with some running over 100 active agents. If you are running Microsoft 365 in any meaningful way, your tenant has the conditions this attack requires.
The privileged service principals are not exotic. They are the SSO connector for your HR platform, the application that syncs Active Directory to a SaaS app, the bot that posts to a Teams channel from your CI pipeline. Every one of them is an authentication surface, and every one can be a foothold once an attacker can rewrite its credentials.
Timeline
- February 24, 2026: Silverfort identifies the flaw.
- March 1, 2026: Reported to Microsoft Security Response Center.
- March 26, 2026: Microsoft confirms the issue.
- April 9, 2026: Microsoft rolls out the fix to all cloud environments.
- April 27, 2026: Silverfort publishes the research.
The fix blocks the Agent ID Administrator role from managing ownership on standard, non agent service principals. There is no patching action required for tenants—Microsoft applied the change at the platform level. But the audit work is on the customer.
What to Audit Right Now
If you administer an Entra ID tenant, run three checks today:
- Who held the Agent ID Administrator role between February and April 9? Check role assignment audit logs. Anyone in that window could have exploited the flaw before the fix.
- Service principal ownership changes. Search the Entra ID audit log for "Add owner to service principal" events. Any addition to a non agent service principal during that window deserves explicit review.
- New client secrets or certificates on privileged service principals. Filter for "Add password to application" or "Add key to application" events. New credentials added to high privilege apps during the vulnerable window are the strongest indicator of exploitation.
Microsoft's KQL queries for Sentinel and the Entra ID audit log schema are documented at learn.microsoft.com/entra/identity/monitoring. The base operations all generate audit events that retain for at least 30 days, so most tenants still have evidence of any exploitation that happened pre patch.
The AI Agent Identity Problem
The Entra finding is one example of a much bigger trend. Every major cloud platform is racing to add native AI agent capabilities, and each one needs a new identity model. Agents call APIs, hold tokens, and act on behalf of users. They cannot share user identities because they run continuously and at machine speed. They cannot share traditional service principals because their lifecycle is more dynamic. So the platforms are inventing new identity primitives—and inventing them under deadline pressure.
When you ship a new identity primitive, you also ship a new permission model, a new audit log schema, and a new set of edge cases. Silverfort found one. There will be more. The next version of this story will involve Google's Agent Engine, AWS's Bedrock Agents, or whatever Salesforce ships under the Einstein brand.
What This Means for the Email Layer
A tenant takeover of Microsoft 365 is the worst case for email privacy. Once an attacker holds Global Administrator, they can read every mailbox, configure mail forwarding rules, register a malicious application that pulls inbox content, or quietly reconfigure Conditional Access to allow logins from anywhere. The Storm 2755 "payroll pirate" campaign documented earlier this year used exactly this kind of OAuth application abuse to hijack salary deposits, and the underlying primitive—a service principal with elevated mail permissions—is what Silverfort showed could now be hijacked through the Agent ID role.
Detection at the email layer matters because email is often where the attacker goes to monetize a tenant compromise. Outbound spam, business email compromise, and follow on phishing campaigns all flow from a compromised tenant's mail infrastructure. Defending the identity layer is the same project as defending the inbox.
The Lesson for Every Cloud Identity Stack
"This role is for AI agents only" was a design intent. The actual permission boundary was wider than the intent. That mismatch is the core failure mode for every privileged role in every cloud identity system, and it is rarely caught by red teams that only test what is in the documentation. Silverfort's research worked because the team treated the role's name as a hypothesis to be tested rather than a fact to be accepted.
The fix is in. The audit work is on you. And the next "scoped" role that ships with an AI feature deserves the same scrutiny.