Entra Agent ID Administrator: When an AI Role Owns the Whole Tenant

Microsoft introduced the Agent ID Administrator role earlier this year as part of its new Entra Agent Identity Platform. The role exists for one purpose: to let an admin manage the lifecycle of AI agent identities — blueprints, agent service principals, agent users — without granting them the much broader Application Administrator role. On paper, it is a textbook least-privilege design. A scoped role for a scoped problem.

Silverfort's research team published a finding on April 23, 2026 that the role's actual scope did not match its documented scope. A user assigned only the Agent ID Administrator role could assign themselves as owner of any service principal in the tenant, not just agent-related ones. Once owner, they could attach a new client secret. With the new secret in hand, they could authenticate as that service principal and inherit every directory role and Graph permission it held. Silverfort's snapshot of customer environments puts the exposure in concrete terms: about 99% of tenants have at least one privileged service principal that this primitive could have taken over.

Microsoft remediated the bug server-side on April 9, 2026 — meaning every tenant is fixed today, with no customer action required. But the patch closes the door without telling you whether anyone walked through it first. The window between role introduction and the fix is the audit problem this week.

What the role was supposed to do

To understand the bug, it helps to understand how Entra ID models applications. When an app is registered, two related objects are created in the home tenant: an application object that defines the app globally, and a service principal that represents the app's identity inside the tenant — the thing that holds permissions, gets role assignments, and authenticates to APIs. Service principals are how non-human workloads operate in Entra ID. CI/CD pipelines, SaaS-to-Azure integrations, security tools, automation runbooks — every one of them runs as a service principal. Privileged service principals frequently hold directory roles or high-impact Microsoft Graph permissions, which means whoever controls them controls a slice of the tenant.

The Agent Identity Platform extends this model. It introduces blueprints (templates for agent identities), blueprint principals (tenant-specific instances of those blueprints), agent identities (special service principals that AI agents authenticate as), and agent users (optional user-like objects for on-behalf-of flows). The Agent ID Administrator role was created to manage these new object types. Its documented scope was "agent stuff only."

The implementation said something different. Silverfort's researchers found that the role's microsoft.directory/servicePrincipals/owners/update permission did not check whether the target service principal was an agent identity. It applied to every service principal in the tenant. Add owner. Add credential. Authenticate. Done.

The takeover primitive

Service principal ownership has been a known privilege escalation path in Entra ID for years. Semperis published a detailed walkthrough in January 2026 demonstrating how a low-privileged user with ownership of one privileged service principal can pivot to Global Administrator. Owners can:

• Add and remove client secrets and certificates on the service principal.
• Authenticate as the service principal using app-only flows, bypassing user-centric controls like MFA and Conditional Access.
• Inherit every directory role assigned to the service principal — including Global Administrator, Privileged Role Administrator, and Privileged Authentication Administrator.
• Inherit every Microsoft Graph application permission the service principal holds, including RoleManagement.ReadWrite.Directory, Application.ReadWrite.All, and User.ReadWrite.All.
• Disable App Instance Property Lock if the service principal predates March 2024 or has the lock disabled.

The chain looks like this:

# Step 1: With Agent ID Administrator role, add yourself as owner
# of an arbitrary, non-agent service principal
az ad sp owner add \
    --id <target-service-principal-object-id> \
    --owner-object-id <your-user-object-id>

# Step 2: As owner, add a new client secret
az ad sp credential reset \
    --id <target-service-principal-object-id> \
    --append \
    --display-name "ops-rotation"

# Step 3: Authenticate as the service principal
az login --service-principal \
    --username <app-id> \
    --password <new-secret> \
    --tenant <tenant-id>

# Step 4: You now hold every permission the service principal holds.
# If it has Global Administrator, you have Global Administrator.

Silverfort's demo recording shows the entire flow in under two minutes: a test user with only Agent ID Administrator takes over a non-agent service principal that holds the Global Administrator role, then signs in. The path from "low-privileged role for AI agents" to "tenant compromise" is four API calls.

Why the UI made this worse

Two human factors compounded the technical scope gap. The first is that the Agent ID Administrator role's documentation correctly labeled it as "privileged," but the Entra portal UI did not display that label. Privileged roles in the UI carry a visible badge that signals to admins that assignment requires extra scrutiny — typically Privileged Identity Management activation, separation-of-duties review, justification logging. Without the badge, admins assigned the role with the same casualness they would assign Reports Reader. Microsoft has confirmed this UI inconsistency will be fixed.

The second is that the role's name implies a narrow scope. "Agent ID Administrator" sounds like a role you give to the IT contact for the team running the AI chatbot project. It does not sound like a role that needs the same review process as Application Administrator. In organizations operating under NIST SP 800-53, ISO 27001, or SOC 2, role assignments are part of the access review cycle. New roles introduced mid-cycle by the cloud provider often slip through, because the review baselines were established without them. This is not unique to Entra ID — every major SaaS platform has the same problem — but it is acutely visible here.

The audit you should run this week

The patch is in place. The question is whether the role was abused between its introduction and April 9. Silverfort recommends a 60-day audit window leading up to the fix. The work is two queries and a review.

Step 1: Find every account that held the Agent ID Administrator role

The role definition ID is db506228-d27e-4b7d-95e5-295956d6615f. Pull the current and historical assignments through Microsoft Graph or the Azure CLI:

# Current Agent ID Administrator assignments
az rest --method GET \
    --url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$filter=roleDefinitionId eq 'db506228-d27e-4b7d-95e5-295956d6615f'" \
    --query "value[].principalId" -o tsv

# Historical assignment events from AuditLogs (last 60 days)
# In the Azure portal: Entra ID > Monitoring > Audit logs
# Filter: Service = Core Directory, Activity = Add member to role
# Search the TargetResources for the role ID above

Document every principal that has held the role. For each one, note who assigned it, when, and what their normal job function is. Anyone outside the agent identity ownership team is a yellow flag.

Step 2: Hunt for ownership and credential changes performed during the exposure window

The high-signal events are "Add owner to service principal" and "Add service principal credentials." Silverfort's KQL query, adapted for clarity:

// Run in Log Analytics or Microsoft Sentinel
AuditLogs
| where TimeGenerated between (datetime(2026-02-15) .. datetime(2026-04-10))
| where OperationName in ("Add owner to service principal",
                         "Add service principal credentials",
                         "Update service principal")
| extend Initiator = tostring(InitiatedBy.user.userPrincipalName)
| extend Target = tostring(TargetResources[0].displayName)
| extend TargetType = tostring(TargetResources[0].type)
| where TargetType == "ServicePrincipal"
| project TimeGenerated, OperationName, Initiator, Target, Result
| order by TimeGenerated desc

// Cross-reference with the principals from Step 1.
// Any owner-add or credential-add by an Agent ID Administrator holder
// against a non-agent service principal is the indicator.

Cross-reference the initiators in this output with the principal list from Step 1. The pattern of concern: an Agent ID Administrator holder adding themselves (or another principal) as owner of a service principal that is not an agent identity, followed by a credential creation event on that same target. That sequence is the takeover primitive.

Step 3: Inventory privileged service principals

Whether or not you find evidence of abuse, the inventory work is overdue. The Agent ID Administrator finding is the latest reminder that service principals with directory roles or high-impact Graph permissions are crown jewels. They should be small in number, documented by purpose, monitored continuously, and protected with App Instance Property Lock.

# Service principals with directly-assigned directory roles
az rest --method GET \
    --url "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?\$filter=principalType eq 'ServicePrincipal'" \
    --query "value[].{principal:principalId, role:roleDefinitionId}" \
    -o json | jq

# Service principals in role-assignable groups (often missed)
az rest --method GET \
    --url "https://graph.microsoft.com/v1.0/groups?\$filter=isAssignableToRole eq true" \
    --query "value[].id" -o tsv | \
while read group_id; do
    echo "=== Group: $group_id ==="
    az rest --method GET \
        --url "https://graph.microsoft.com/v1.0/groups/$group_id/members" \
        --query "value[?'@odata.type'=='#microsoft.graph.servicePrincipal'].displayName"
done

# Service principals with high-impact Graph application permissions
# (RoleManagement.ReadWrite.Directory, Application.ReadWrite.All, etc.)
az rest --method GET \
    --url "https://graph.microsoft.com/v1.0/servicePrincipals?\$select=id,displayName,appRoleAssignments&\$expand=appRoleAssignedTo"

Anything in the resulting set should be on a watchlist. New owners, new credentials, and sign-in patterns from those service principals deserve standing alerts in your SIEM.

The architecture lesson

The bug is fixed. The pattern is not. Entra ID — and every cloud identity platform — sits on a layered model where the relationships between objects often grant more access than the object's own permissions imply. Group membership, ownership, application consent, conditional access bypasses on service principals: each is a separate, often-overlooked, escalation path. The Agent ID Administrator finding is one instance of a broader category. Future cloud roles introduced for new product surfaces will keep producing similar findings, because the base primitives (service principal ownership, application consent, role-assignable groups) are themselves takeover-grade.

For SMBs running Microsoft 365 with a small number of admins, the practical posture is uncomfortable but doable:

1. Treat every new built-in role as untrusted until you have audited its real scope. Documentation drift is normal. Test what the role can do, not what the docs say it can do, before adding it to your access review baseline.
2. Keep the count of privileged service principals small. Most organizations have far more than they need. CI/CD service principals do not need RoleManagement.ReadWrite.Directory. Vendor integrations rarely need Global Administrator. Review every one of them on a fixed cadence.
3. Enable App Instance Property Lock on every service principal you can. It is on by default for service principals created after March 2024. For older ones, turn it on. It is the only feature that prevents a compromised owner from silently adding credentials to the service principal object itself, which is invisible in the portal.
4. Monitor service principal ownership and credential changes as named-event alerts. Both events are rare in normal operation and high-signal under attack. Sentinel, Defender for Cloud Apps, and most third-party CSPM tools support this with off-the-shelf rules.
5. Assume the next finding is already shipping. AI infrastructure inside identity platforms is a fast-moving surface. Build your detection on the underlying primitives — owner adds, credential adds, anomalous app-only sign-ins — not on the specific role names that appear in this quarter's news.

The 60-day audit window is the immediate work. The architecture lesson is the durable one.