Microsoft Fixes Entra Agent ID Administrator Flaw That Could Hijack Service Principals

Microsoft has fixed a Microsoft Entra Agent ID Administrator role issue that could let users take over service principals across a tenant. Silverfort researchers found that the role, introduced for Microsoft’s Agent Identity Platform, had broader control than intended and could modify ownership on non-agent service principals.

The flaw mattered because service principals often hold powerful permissions in Microsoft Entra ID. If an attacker gained the Agent ID Administrator role, they could add themselves as an owner of a high-privileged service principal, create credentials for it, and authenticate as that application.

Microsoft has deployed a fix across cloud environments. According to Silverfort, the patched behavior now prevents the Agent ID Administrator role from managing owners of service principals that are not agent identities.

The issue came from a permission boundary gap

Microsoft Entra Agent ID is designed to give AI agents first-class identities inside Entra ID. Microsoft documentation describes administrative relationships for agents, including owners, sponsors, and managers, and notes that service principals can also serve as owners for automated agent management.

Silverfort found that the Agent ID Administrator role did not stay limited to agent-related objects. Because agent identities rely on existing application and service principal building blocks, the role could reach beyond its intended scope.

That created a service principal takeover path. A user with the Agent ID Administrator role could assign themselves as owner of a separate service principal, even if that identity had nothing to do with AI agents.

How attackers could abuse the role

Once a user becomes an owner of a service principal, they can often add credentials or secrets. That gives the attacker a way to sign in as the application identity and use its assigned permissions.

The impact depends on the target service principal. If it only has low-risk permissions, the damage may stay limited. If it holds privileged directory roles or sensitive Microsoft Graph permissions, the attacker can move toward full tenant compromise.

Silverfort said the attack path would naturally push attackers toward the most powerful non-human identities in the environment. These often include automation accounts, enterprise apps, backup tools, security platforms, deployment systems, and managed service integrations.

Attack stage	What happens
Initial access	Attacker obtains or abuses an account with Agent ID Administrator
Ownership change	Attacker adds themselves as owner of a non-agent service principal
Credential creation	Attacker adds a new secret or certificate to that service principal
Authentication	Attacker signs in as the service principal
Privilege escalation	Attacker uses the service principal’s roles or Graph permissions

Why service principals create high-impact risk

Service principals act as application identities in Microsoft Entra ID. Microsoft explains that application objects define an app, while service principals represent that app inside a tenant and allow it to authenticate and access resources.

Many organizations rely on service principals for automation. They may run deployments, sync data, access cloud resources, manage security tools, or integrate third-party platforms.

This makes them attractive targets. Unlike human users, service principals may not use phishing-resistant MFA, may hold long-lived credentials, and may receive less direct monitoring than administrator accounts.

Microsoft patched the role behavior

Silverfort said Microsoft acknowledged the issue and changed the Agent ID Administrator role so it can no longer manage owners of non-agent service principals. The company also plans to fix a discrepancy in the Microsoft Entra interface where the role’s privileged indicator did not clearly reflect the risk.

The fix closes the direct Agent ID Administrator overreach path. However, it does not remove the broader identity security risk around service principal ownership and credential abuse.

Security teams should still treat privileged service principals as critical assets. Any identity that can add owners or credentials to an application identity can potentially create a durable backdoor into cloud resources.

What administrators should check now

Organizations should review whether any users received the Agent ID Administrator role before Microsoft’s fix. They should also inspect recent audit logs for suspicious service principal ownership changes, credential additions, or role assignments.

Security teams should prioritize service principals with directory roles, broad Microsoft Graph permissions, or access to critical cloud services. Those identities deserve the same level of review as privileged user accounts.

Recommended actions include:

• Review all accounts assigned the Agent ID Administrator role.
• Audit service principal owner changes from the last several months.
• Check for newly added secrets, certificates, or federated credentials.
• Identify service principals with privileged directory roles.
• Remove unnecessary owners from high-impact service principals.
• Rotate credentials on service principals that show suspicious changes.
• Monitor audit logs for owner and credential updates.
• Apply least privilege to all application identities.

Summary

1. Silverfort found a scope overreach issue in Microsoft’s Agent ID Administrator role.
2. The role could manage owners of non-agent service principals.
3. Attackers could use that access to add credentials and sign in as targeted application identities.
4. Microsoft patched the behavior across cloud environments.
5. Organizations should still audit privileged service principals and monitor ownership changes.

FAQ