Microsoft Entra Agent ID introduces dedicated identity concepts for AI agents in Entra ID. While agent identities are based on the existing service principal infrastructure, they add agent-specific objects and relationships such as agent blueprints, blueprint principals, agent identities, agent users, and dedicated authentication flows. From a security perspective, the important question is not only whether such agents exist in a tenant. It is also important to understand how agent identities differ from traditional service principals, such as enterprise applications. This includes identifying who controls them, how they authenticate, and what they can access. Introduction This post does not aim to provide a complete technical introduction to every Entra Agent ID object or authentication flow. These concepts are only summarized briefly to provide enough context for the security-relevant observations in the following sections. New Agent ID Objects With Entra Agent ID, Microsoft introduced several new objects and relationships for representing AI agents in Entra ID. These objects differ from the traditional App Registration and Enterprise Application model. In the traditional model, the relationship is usually relatively simple: an app registration defines the application, and an enterprise application represents the tenant-specific service principal. With Entra Agent ID, this model becomes more layered. Depending on the scenario, the relevant objects may include an agent blueprint, a blueprint principal, one or more agent identities, and optionally agent users. The blueprint acts as the template for the blueprint principal and contains global configuration, including credentials and required resource access. Conceptually, this is similar to the role of an app registration. The blueprint principal represents a tenant-specific instance of the blueprint. It is comparable to an enterprise application, but it mainly manages agent identities for the blueprint rather than acting as the agent identity itself. The agent identity is the primary account used by an AI agent to authenticate to various systems. A blueprint principal can be associated with multiple agent identities. An agent user is an optional secondary account that an AI agent can use to authenticate to various systems. It behaves more like a regular user account than a service principal. Credentials The new objects also need a way to authenticate. Different credential types are supported: Client Secrets Certificates Federated Credentials An important difference compared to the traditional enterprise application model is that credentials are configured only on the blueprint itself. Based on my testing, credentials could not be added directly to the blueprint principal or agent identity: New Authentication Flows Entra Agent ID also introduces dedicated authentication flows. The important difference is that agent identities and agent users do not authenticate like traditional service principals. Instead, agent identities use a token-exchange model. The agent identity blueprint authenticates with its own credential and obtains an exchange token for a specific child agent identity. The agent identity then uses this exchange token as a client assertion to obtain the final access token for the target resource. This separation matters because the blueprint holds the authentication credentials, while the agent identity holds the permissions. A compromise of the blueprint credentials may therefore affect all child agent identities associated with it. There are three authentication flows: Autonomous agent app OAuth flow 1 On-behalf-of OAuth flow 2 Agent’s user account OAuth flow 3 For this research, I patched the PowerShell authentication tool EntraTokenAid to support these authentication flows. It is used for the examples in this blog post. Security-Relevant Capabilities Agent identities and agent users can receive different forms of authorization, including group memberships, Entra ID role assignments, OAuth2 delegated permission grants, and application permission grants (app roles). Entra ID Roles Microsoft restricts the assignment of certain highly privileged Entra ID roles to agent identities and agent users. For example, the Global Administrator or Group Administrator role cannot be assigned. In addition, agent identities and agent users cannot be added as members or owners of role-assignable groups. However, some privileged roles can still be assigned, such as Exchange Administrator and Windows 365 Administrator. The latter may be particularly relevant because it can manage security groups. During testing, I also noticed a documentation gap: the Security Reader role is missing from the official list of roles that can be assigned to agent identities and agent users. A pull request was created to address this 4 . Azure RBAC Roles Agent identities can be assigned Azure RBAC roles, such as Owner. During testing, I did not observe any Azure RBAC role assignment ...