Agent 365 is GA: what an IAM team has to decide about Entra Agent ID
Since 1 May 2026, Microsoft Agent 365 and Microsoft Entra Agent ID are generally available, and every agent built on the new platform gets its own identity in your tenant. The launch itself is well covered elsewhere, so I'll stick to the identity object model as Learn documents it, the token flows agents use, and what an IAM team has to decide now about sponsors, lifecycle, naming, Conditional Access, logging and licensing. Preview and GA status are as they stand this week.
Photo: Point Normal on Unsplash
What changed on 1 May
Agent 365 went GA on 1 May together with Microsoft 365 E7, as announced in March. On the same date the Agent registry and Agent collections blades in the Entra admin center were retired (MC1275311). The full agent inventory, including agents that have no Entra identity at all, now lives under Agents > All agents in the Microsoft 365 admin center, readable with the AI Reader role. Entra keeps the identity side: agent identities, blueprints, permissions, Conditional Access and governance stay under Entra ID > Agents, managed with the Agent ID Administrator role (registry convergence).
Four objects instead of one app registration
The key concepts page describes four objects. For an IAM team, what matters is where they differ from an ordinary app registration.
The agent identity blueprint is an application object. It holds the credentials (federated identity credential, certificate or secret), the inheritable permissions and the publisher information. Its only job in the tenant is to create and delete agent identities. The blueprint principal is the service principal of that blueprint in your tenant: it is the
The agent identity is a service principal with an agent subtype. It has no credentials of its own; the blueprint impersonates it. Its object ID and app ID are the same value, it is single-tenant even when the blueprint is multitenant, and it is what you grant permissions to. Where an app registration has one service principal per tenant, a blueprint has many agent identities, which is why Microsoft calls the number of blueprints a security boundary decision: a leaked blueprint credential is a leaked credential for every agent under it (agent identities vs. service principals).
The agent's user account (agent user) is optional, a user object paired 1:1 with one agent identity. It gets tokens with
One detail I would put in front of every IAM team: any blueprint principal in your tenant automatically gets the application permission
The agent identity blueprint is an application object. It holds the credentials (federated identity credential, certificate or secret), the inheritable permissions and the publisher information. Its only job in the tenant is to create and delete agent identities. The blueprint principal is the service principal of that blueprint in your tenant: it is the
oid in tokens the blueprint acquires and the actor you see in the audit log when agent identities are created.The agent identity is a service principal with an agent subtype. It has no credentials of its own; the blueprint impersonates it. Its object ID and app ID are the same value, it is single-tenant even when the blueprint is multitenant, and it is what you grant permissions to. Where an app registration has one service principal per tenant, a blueprint has many agent identities, which is why Microsoft calls the number of blueprints a security boundary decision: a leaked blueprint credential is a leaked credential for every agent under it (agent identities vs. service principals).
The agent's user account (agent user) is optional, a user object paired 1:1 with one agent identity. It gets tokens with
idtyp=user, so it can reach APIs that only accept users, and it can hold a mailbox and licences. It has no password or passkey, can only authenticate through its parent agent identity, and can't hold privileged admin roles (agent users). In Agent 365 the agent user scenario (the "AI teammate" with its own mailbox) is still a Frontier preview feature, so most tenants will see agent identities first and agent users later.One detail I would put in front of every IAM team: any blueprint principal in your tenant automatically gets the application permission
AgentIdentity.CreateAsManager, and that grant can't be revoked. The only ways to stop it creating agent identities are disabling the principal or removing it (creation channels). For third-party agents, the principal arrives when a user consents, so in practice your app consent policy decides which blueprint principals end up in your tenant. Which token the agent actually holds
Every agent flow starts the same way: the blueprint uses its credential to get an exchange token for
api://AzureADTokenExchange/.default, with an fmi_path pointing at the agent identity. What happens next decides who the token subject is, and therefore which Conditional Access policy applies (Conditional Access for agent identities).- On-behalf-of: the user is the subject and the agent identity is the actor. Policies assigned to users apply, agent-targeted policies don't. These sign-ins show up as non-interactive user sign-ins.
- App-only: the agent identity is the subject. You target the agent identity or its blueprint. These land in service principal sign-ins.
- Agent user: the agent identity exchanges its token for one issued to its agent user (grant type
user_fic). The agent user is the subject, logged under non-interactive user sign-ins.
/authorize, have no redirect URIs and can't do SSO to web apps through the Entra sign-in page. Sponsors and owners
A sponsor is required when creating a blueprint or an agent identity (owners, sponsors and managers). In a delegated create the calling user becomes sponsor if nobody else is named; admins with Agent ID roles are deliberately not made sponsor automatically. Sponsors are the business accountability: they can disable the agent and manage its sponsors but can't touch credentials or configuration. Owners are optional technical administrators, users or service principals, not groups.
Where it goes wrong is the group type. A group sponsor must be a dynamic membership group or an assigned Microsoft 365 group. The assigned security group that most teams already use for "the people responsible for application X" isn't accepted, and neither is a role-assignable group. My advice is to make the sponsor a Microsoft 365 group of the business team that asked for the agent, and make the owner the engineers or the deployment pipeline's service principal. Agent user sponsors are a different relationship (they behave like B2B guest sponsors and can't modify the account), so set the same group on both objects.
Two more constraints affect how you delegate: agent identities and blueprints can't be added to administrative units, and custom roles don't support agent identity actions. Scoped delegation runs through ownership. The admin consent workflow also doesn't work for permissions requested by agent identities, so requests will reach your team outside the usual queue.
Where it goes wrong is the group type. A group sponsor must be a dynamic membership group or an assigned Microsoft 365 group. The assigned security group that most teams already use for "the people responsible for application X" isn't accepted, and neither is a role-assignable group. My advice is to make the sponsor a Microsoft 365 group of the business team that asked for the agent, and make the owner the engineers or the deployment pipeline's service principal. Agent user sponsors are a different relationship (they behave like B2B guest sponsors and can't modify the account), so set the same group on both objects.
Two more constraints affect how you delegate: agent identities and blueprints can't be added to administrative units, and custom roles don't support agent identity actions. Scoped delegation runs through ownership. The admin consent workflow also doesn't work for permissions requested by agent identities, so requests will reach your team outside the usual queue.
Lifecycle, deprovisioning and naming
Disabling a blueprint blocks every agent identity under it. Deleting a blueprint or its principal triggers a cascade that soft-deletes its agent identities and agent users, asynchronously, sometimes hours or days later, logged as "Delete service principal" by an actor called Delete Agent Identities Task with no app ID (agent identity deletion). Restoring the blueprint principal doesn't undo deletions that already ran. Deletion isn't possible from the admin center; you use Graph or Entra PowerShell. Soft-deleted agent identities keep counting toward the 250 per blueprint limit that applies to non-Microsoft platforms using app-only permissions. The FAQ also still says agent users stay behind when an agent identity is deleted, so add an explicit check for orphaned agent users to your deprovisioning runbook.
For sponsors who leave, Lifecycle Workflows has mover and leaver tasks that notify the manager or co-sponsors and transfer sponsorship to the manager. Add them to your existing leaver workflow.
On naming: the agent identity display name shows up in Teams and Outlook and can be changed by owners, so don't encode classification in it. Put environment, data sensitivity and approval status in custom security attributes, because that's what Conditional Access can filter on, and keep the blueprint name as "the kind of agent".
For sponsors who leave, Lifecycle Workflows has mover and leaver tasks that notify the manager or co-sponsors and transfer sponsorship to the manager. Add them to your existing leaver workflow.
On naming: the agent identity display name shows up in Teams and Outlook and can be changed by owners, so don't encode classification in it. Put environment, data sensitivity and approval status in custom security attributes, because that's what Conditional Access can filter on, and keep the blueprint name as "the kind of agent".
Conditional Access and ID Protection as of May 2026
In the policy editor everything agent-related is still labelled preview: Agents (Preview), All agent identities (Preview) and the Agent risk (Preview) condition. For agent identities you can target all, individual agents, blueprints (which covers future agents from that blueprint) or custom security attributes, and the only grant control is Block. For agent users there is exactly one scope, all agents acting as users, with Block on all resources. Learn doesn't say outright that "All users" policies skip agent users, but given that separate scope I would assume they don't cover them and build the agent user policy explicitly. Human-centric controls such as MFA and device compliance are intentionally not applied. None of this applies while security defaults are on.
ID Protection for agents is preview, with six offline detections and a Risky Agents report. Confirming compromise sets the agent to high risk, which a block-on-high-agent-risk policy then enforces.
This is the policy I would create first, in report-only, straight from the disable agent identities guidance:
ID Protection for agents is preview, with six offline detections and a Risky Agents report. Confirming compromise sets the agent to high risk, which a block-on-high-agent-risk policy then enforces.
This is the policy I would create first, in report-only, straight from the disable agent identities guidance:
POST https://graph.microsoft.com/beta/identity/conditionalAccess/policies
Content-type: application/json
{
"displayName": "Block all agent identities from accessing resources",
"conditions": {
"clientApplications": {
"includeAgentIdServicePrincipals": ["All"],
"excludeAgentIdServicePrincipals": [],
"agentIdServicePrincipalFilter": null
},
"applications": {
"includeApplications": ["All"],
"excludeApplications": []
}
},
"grantControls": {
"operator": "AND",
"builtInControls": ["block"]
},
"state": "enabledForReportingButNotEnforced"
}
The agent user equivalent uses
"includeUsers": ["AllAgentIdUsers"] under conditions.users. Logs
Audit events keep their base type: a blueprint is "Add application" (
agentType = agenticApp), an agent identity is "Add service principal" (agenticAppInstance), an agent user is "Add user" (agentIDuser). In Graph you need the Prefer: include-unknown-enum-members header to see the last value. In the sign-in logs, filter on Agent type (Agent ID logs). If you query Graph instead, use the enum value from the agentSignIn reference, agenticAppInstance for an agent identity. The sample on the Agent ID logs page filters on AgentIdentity, which is the label the portal shows, and Graph rejects that with a 400 ("not a valid enumeration type constant"): GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=createdDateTime ge 2026-05-13T00:00:00Z and signInEventTypes/any(t: t eq 'servicePrincipal') and agent/agentType eq 'agenticAppInstance'&$top=10
Keep the
Microsoft Graph activity logs don't distinguish agents yet, so join them with the sign-in logs if you want to know which calls came from an agent.
createdDateTime window and $top in there: without them the query searches the full service principal sign-in history and can run into the client timeout before it returns anything.Microsoft Graph activity logs don't distinguish agents yet, so join them with the sign-in logs if you want to know which calls came from an agent.
Licensing as it stands
Agent 365 is USD 15 per user per month, Microsoft 365 E7 (E5, Microsoft 365 Copilot, Agent 365 and Entra Suite) is USD 99. Licensing is per user, and agents acting for a licensed user don't need their own licence. The Entra side has been rewritten several times on Learn since 30 April. The version live this week says Agent ID itself is available to all Entra customers, Conditional Access for agents needs Entra ID P1, ID Protection for agents P2 (or Microsoft 365 E5 for both), while the GA post (MC1296867) says the governance features for agents need Agent 365. Expect this to move, and recheck before you sign anything.
Update June 2026: Microsoft added the service plans "Entra Conditional Access for Agents" and "Entra ID Protection for Agents" to Agent 365 and Microsoft 365 E7, rolling out July to August 2026; tenants using either capability without Agent 365 or E7 need that licence to keep using them (MC1395007).
To start: create the block policy above in report-only, let it run for a few days, and use the report-only results to list every agent identity and blueprint that is actually requesting tokens. For each one, check that the sponsor is a group of a supported type, and review which users can consent to apps, because that decides which blueprint principals get into your tenant in the first place.
Update June 2026: Microsoft added the service plans "Entra Conditional Access for Agents" and "Entra ID Protection for Agents" to Agent 365 and Microsoft 365 E7, rolling out July to August 2026; tenants using either capability without Agent 365 or E7 need that licence to keep using them (MC1395007).
To start: create the block policy above in report-only, let it run for a few days, and use the report-only results to list every agent identity and blueprint that is actually requesting tokens. For each one, check that the sponsor is a group of a supported type, and review which users can consent to apps, because that decides which blueprint principals get into your tenant in the first place.
Sources
- agentSignIn resource type (Microsoft Graph beta)
- Microsoft blog: Introducing the first Frontier Suite built on intelligence and trust (9 March 2026)
- MC1275311: Agent registry and Agent collections retire in the Entra admin center
- MC1296867: Microsoft Agent 365 generally available
- Agent registry convergence with the Microsoft 365 admin center
- Key concepts of Microsoft Entra Agent ID
- Agent identities, service principals and applications
- Agent users in Microsoft Entra Agent ID
- Agent identity creation channels
- Conditional Access for agent identities
- Owners, sponsors and managers of agent identities
- Agent identity deletion
- ID Protection for agents (risky agents)
- Disable agent identities with Conditional Access
- Sign-in and audit logs for agents
- Microsoft Entra licensing: Agent ID
- MC1395007: Conditional Access and ID Protection for agents service plans in Agent 365 and Microsoft 365 E7