Microsoft Entra Agent ID and Keycloak solve the same problem in different places. Entra Agent ID, generally available since April 2026, makes every AI agent a first-class object in your Microsoft Entra directory, with its own identity type, blueprints, Conditional Access and risk detection. Keycloak, the open-source identity and access management server behind many identity management as a service offerings, treats an agent as an OAuth client: you give each agent class a confidential client, authenticate it without stored secrets, and use token exchange when it acts for a user. If your agents live mostly inside Copilot Studio, Azure AI Foundry and Microsoft 365, Entra Agent ID is the natural fit. If they run across clouds or inside a multi-tenant SaaS product, Keycloak gives you the same building blocks through open standards without making every agent a Microsoft directory object.
Key Takeaways
- In April 2026, Microsoft made Entra Agent ID generally available, with agent identities, blueprints and three OAuth flows for agents.
- Microsoft documents a per-user Microsoft Agent 365 license for its agent governance features, with enforcement described as coming soon.
- Keycloak 26.x maps agents to confidential clients, federated client authentication and standard token exchange.
- Keycloak has no built-in agent risk scoring, so you bring your own detection.
What is Microsoft Entra Agent ID?
Microsoft’s Entra release notes (“What’s new in Microsoft Entra”) list the Agent ID platform as generally available in April 2026, saying “The Microsoft Entra Agent ID platform is now generally available.” It adds identity types built for AI agents to Entra ID, so an agent is no longer a generic app registration or, worse, a shared user account. Across its “Microsoft Entra Agent ID key concepts” and “Agent identities” pages, Microsoft’s documentation defines four object types:
- Agent identity blueprint. A template that holds the credentials and configuration shared by a class of agents. Microsoft says the blueprint “holds credentials and uses them to acquire tokens on behalf of all agent identities created from it.”
- Blueprint principal. The blueprint’s presence in a particular tenant, which lets it acquire tokens and show up in audit logs.
- Agent identity. A special kind of service principal for one agent instance. It has no credentials of its own, and it authenticates only through the blueprint.
- Agent’s user account. An optional, one-to-one companion user object for agents that need a mailbox, a Teams presence or anything else that only works for users.
Some products create these for you. Microsoft’s “How are agent identities created?” page lists Copilot Studio, Security Copilot and Azure AI Foundry as channels that can create agent identities, and in Copilot Studio’s case the blueprint is added automatically when the product is enabled. Microsoft’s documentation also describes options for agents built outside its platform, such as an SDK sidecar or workload identity federation.
Parts of the admin experience are still labeled preview in the documentation, including the blueprint and agent identity creation wizards, even though the core service is generally available.
How do Entra agents authenticate?
Microsoft’s “Authentication protocols in agents” documentation describes three flows, all of them for confidential clients:
- Agent on-behalf-of, for interactive agents acting for a signed-in user, built on the OAuth 2.0 on-behalf-of (
jwt-bearer) pattern. - Autonomous app flow, a
client_credentialsflow for agents acting as themselves. - Agent’s user account flow, which uses a Microsoft-specific
user_ficgrant for agents that need to act as their own user object.
In each case the blueprint authenticates first and then exchanges its token for one that represents a specific agent identity. Credentials live only on the blueprint: federated identity credentials (FIC, where a token from a trusted issuer such as a managed identity replaces a stored secret), certificates, or client secrets. Microsoft recommends managed identities and says client secrets should not be used in production. Interactive /authorize sign-in and public clients are not supported. Microsoft’s “Agent identities” page adds that an agent identity can only be issued tokens in the tenant where it was created, although a blueprint can be multitenant and create agent identities in each tenant.
How does Keycloak model AI agent identity?
Keycloak has no dedicated “agent” object. In our view that matters less than it sounds, because an agent that calls APIs is an OAuth client, and Keycloak has had well-tested OAuth client machinery for years. The mapping to Entra’s concepts looks like this.
| Entra Agent ID concept | Closest Keycloak 26.x equivalent | Status in Keycloak 26.7 |
|---|---|---|
| Agent identity blueprint | A client naming convention plus shared client scopes and client policies per agent class | No parent/child client object |
| Agent identity | One confidential client with a service account per agent, or per agent class (see how Skycloak manages applications) | Supported |
| Federated identity credential | Federated client authentication with OIDC identity providers or Kubernetes service accounts | Supported since 26.6 |
| FIC from SPIFFE workloads | Federated client authentication with SPIFFE JWT-SVIDs | Preview |
| Autonomous app flow | client_credentials grant |
Supported |
| Agent on-behalf-of | Standard token exchange (RFC 8693) | Supported since 26.2 |
Delegation chain (act claim) |
Token exchange delegation | Experimental in 26.7 for user-to-administrator delegation only (may_act); client delegation with act is not released yet |
| Agent’s user account | A regular user, linked by convention | Supported, but not agent-aware |
| Conditional Access for agents | Client policies and authentication flows | Supported, but rule-based rather than risk-based |
| ID Protection for agents | Keycloak events exported to your SIEM | No built-in risk scoring |
A few of these need more than a table row.
Secretless agent authentication. The Keycloak 26.6.0 release notes say federated client authentication “is now promoted to supported, including support for client assertions issued by external OpenID Connect identity providers and Kubernetes Service Accounts.” That is the Keycloak counterpart of Entra’s FIC: an agent running in Kubernetes, or in a cloud that issues OIDC tokens to workloads, can prove who it is with a token it already has, and you never store a client secret. SPIFFE support stays in preview because, in the release notes’ words, “the OAuth SPIFFE Client Authentication specification is still in draft status.” Our guide to workload identity federation with SPIFFE JWT-SVIDs covers the setup.
Acting for a user. Standard token exchange became a supported feature in Keycloak 26.2, and it covers the on-behalf-of pattern: the agent sends the user’s token to Keycloak and receives a new token for a specific downstream API, with the user still as the subject. Keycloak 26.7 also added an experimental token exchange delegation feature, but in 26.7 it covers a user delegating to an administrator, recorded in a may_act claim. Delegation to a client, which would record the agent in an act claim so the downstream API sees both the user and the agent, appears only in the development notes for the next release, so plan on standard token exchange for agents today. See our practical guide to Keycloak token exchange for the request shapes.
Autonomous agents. A background agent with no user is a plain client_credentials client with a service account, which is exactly how Keycloak already handles machine-to-machine authentication.
How do governance and security compare?
Entra’s strongest advantage is governance that comes built into the directory. Microsoft’s “Conditional Access for agents” documentation (June 2026) lets you write policies that target individual agent identities, whole blueprints, or agents tagged with custom security attributes, and Microsoft gives blocking high-risk agents as an example policy. “ID Protection for agents” (June 2026) adds a risky agents report with eight offline detections, among them sign-in spikes, unfamiliar resource access and suspicious credential usage.
There are also caveats in Microsoft’s documentation. In on-behalf-of flows, Conditional Access policies target the user rather than the agent, and risk is attributed to the user. Policies aimed at agent identities do not cover agents’ user accounts, and “All users” policies exclude agents’ user accounts too, so the fourth object type needs its own policies. Every agent identity and blueprint also needs at least one sponsor, a user or group accountable for the agent who can disable it, which is a useful accountability rule to copy whatever platform you use.
Keycloak’s governance is rule-based. Client policies (supported since Keycloak 14) let you enforce conditions on clients, such as requiring signed JWT authentication or blocking particular grant types for a class of clients. Short token lifespans limit how long any single token stays useful, disabling a client stops it from getting new tokens, and, once you turn event storage on, Keycloak’s login and admin events record every token request and configuration change (Skycloak exposes these as audit logs). For periodic reviews of what each agent client can reach, see our guide to resource access certifications for AI agents. What Keycloak does not do is learn what normal looks like for an agent and flag deviations, so if you need behavioral detection you stream events into a SIEM or detection tool.
In our experience the governance gap most teams hit first is not detection but ownership. Keycloak does not require a sponsor on a client, so agent clients created during a proof of concept tend to outlive the project. A client attribute such as owner and a quarterly review of clients with that attribute gets you most of what Entra’s sponsor rule enforces.
Which one fits MCP servers and agent-to-agent calls?
Microsoft’s “What is Microsoft Entra Agent ID?” overview says the platform supports “OAuth 2.0, Model Context Protocol (MCP), and agent-to-agent (A2A)” protocols. Its guide “Secure a Model Context Protocol (MCP) server with Microsoft Entra ID” (September 2026) has Entra act as the authorization server and match the RFC 8707 resource parameter against the MCP server’s Application ID URI, which is what the MCP authorization specification expects from clients.
Keycloak can also act as the authorization server for MCP servers, and the Keycloak project ships a guide, “Integrating with Model Context Protocol (MCP)”, in its documentation source. The honest status as of Keycloak 26.7.4 is mixed. The 26.7.4 guide lists dynamic client registration as supported, and Client ID Metadata Documents (CIMD, which lets MCP clients such as VS Code identify themselves by URL) as an experimental feature behind the cimd flag. RFC 8707 resource indicators are not supported in any released version: a resource-indicators flag appears as experimental in the 26.6 and 26.7 code, but the 26.7.4 guide still lists RFC 8707 as not supported and rates the newest MCP revisions as partially supported without it. The upstream tracking issue is milestoned for Keycloak 27.0. Until then, the reliable way to get the right aud claim for an MCP server is an audience mapper on a client scope, which we cover in fixing MCP 401 errors caused by the audience claim and securing MCP servers with Keycloak.
How does licensing compare?
The licensing note on Microsoft’s “What is Microsoft Entra Agent ID?” page says “Agent ID is available for all Microsoft Entra customers,” but “extending Microsoft Entra security features to agents requires Microsoft Agent 365.” Microsoft’s Conditional Access documentation lists Entra ID P1 or P2 plus an Agent 365 license for each user, and says enforcement of the Agent 365 licensing is coming soon. On the Microsoft Security Blog on 1 May 2026, in “Microsoft Agent 365, now generally available, expands capabilities and integrations”, Microsoft priced Agent 365 as part of Microsoft 365 E7 or standalone at USD 15 per user per month.
That per-user model makes sense for a Microsoft 365 tenant, where every employee already has a license. It is a poor fit for a SaaS product whose agents act for your customers, since those customers are not seats in your Microsoft tenant. Keycloak is open source, so the software itself carries no per-agent or per-user license, and what you pay for is running it, either on your own infrastructure or through a managed service.
When should you choose Entra Agent ID or Keycloak?
The decision usually follows where your agents and users already live.
Choose Entra Agent ID when:
- Your agents are built in Copilot Studio, Azure AI Foundry or Security Copilot, which create agent identities automatically.
- The users those agents act for are your employees, already in Entra ID with Microsoft 365 licenses.
- You want Microsoft-managed risk detection and Conditional Access templates without building your own.
Choose Keycloak when:
- Your agents run on several clouds, or on Kubernetes, and you want one standards-based authorization server for all of them.
- The agents act for your customers inside a multi-tenant product, where per-user Microsoft licensing does not map to your business.
- You want the option to self-host, or to export your realm configuration and move providers later.
A common pattern is to run both: Entra for internal agents working on employee data, and Keycloak as the authorization server for agents in the product itself. Keycloak can broker Entra as an identity provider, so an employee who signs in with Entra can still hand an agent a Keycloak-issued token for your product’s APIs.
What mistakes should you avoid with either platform?
Three mistakes show up regardless of vendor. The first is treating an agent as a human user in the directory, which gives it interactive sign-in, password policies that do not apply, and an audit trail that mixes its actions with a person’s. The second is standing client secrets: both Microsoft and the Keycloak project now support federated, secretless authentication, and a long-lived secret in an agent’s environment variables is the easiest credential to leak. The third is skipping the audience check, so a token minted for one tool works against another. Our overview of authentication for AI agents in Keycloak goes through each of these with configuration examples.
How does this fit the rest of the 2026 agent identity market?
Entra is one of several vendors building agent identity into an existing directory this year. Okta announced runtime enforcement through its Agent Gateway at Oktane in September 2026, which we compare in Okta Agent Gateway vs Keycloak, and AWS takes a different approach with Bedrock AgentCore Identity, covered in AgentCore Identity vs Keycloak. Each vendor’s model works best inside its own platform, and the portable part across all of them is OAuth: clients, scoped tokens, token exchange and audience checks.
Frequently Asked Questions
Is Microsoft Entra Agent ID generally available?
Yes. Microsoft’s Entra release notes list the Agent ID platform as generally available in April 2026. Some admin-center tools, such as the blueprint and agent identity creation wizards, are still labeled preview in Microsoft’s documentation, so check the status of the specific feature you plan to rely on.
Does Microsoft Entra Agent ID cost extra?
Creating agent identities is available to all Entra customers. Microsoft’s documentation says extending Entra security features to agents, including Conditional Access and ID Protection for agents, requires Microsoft Agent 365, with enforcement coming soon. Microsoft priced Agent 365 in May 2026 at USD 15 per user per month standalone or as part of Microsoft 365 E7.
What is an agent identity blueprint?
A blueprint is a template for a class of agents. It holds the credentials, such as a managed identity federated credential or a certificate, and uses them to get tokens for every agent identity created from it. Conditional Access applied to a blueprint also applies to all of its agents.
Can Keycloak replace Entra Agent ID?
For authentication and authorization, largely yes: Keycloak 26.x supports confidential clients, federated client authentication (supported since 26.6) and standard token exchange (supported since 26.2). It does not replace Entra’s agent risk detection or automatic provisioning from Copilot Studio, so Microsoft-centric teams usually keep Entra for those agents.
Does Keycloak support RFC 8707 resource indicators for MCP?
Not in a released version yet. An experimental resource-indicators flag appears in the Keycloak 26.6 and 26.7 code, but Keycloak’s 26.7.4 MCP guide lists RFC 8707 as not supported, and the tracking issue is milestoned for Keycloak 27.0. For production MCP servers today, use an audience mapper on a client scope so tokens carry the MCP server’s identifier in aud.
What to do next
Start by listing your agents and the users they act for. Agents working for employees inside Microsoft 365 belong in Entra Agent ID, and agents that serve customers or run across clouds are better modeled as Keycloak clients, one per agent class, with federated client authentication instead of secrets and token exchange for anything done on a user’s behalf. Whichever you choose, give every agent a named owner and check aud on every API it calls. Our JWT Token Analyzer is a quick way to see what a sample agent token actually carries.
Sources
- Microsoft Learn, “What’s new in Microsoft Entra” (April 2026: General Availability, Microsoft Entra Agent ID platform), retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/fundamentals/whats-new
- Microsoft Learn, “What is Microsoft Entra Agent ID?”, retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id
- Microsoft Learn, “Agent identities in Microsoft Entra Agent ID”, retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/agent-id/agent-identities
- Microsoft Learn, “Microsoft Entra Agent ID key concepts”, April 2026, retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/agent-id/key-concepts
- Microsoft Learn, “Authentication protocols in agents”, retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/agent-id/agent-oauth-protocols
- Microsoft Learn, “How are agent identities created?”, April 2026, retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/agent-id/agent-id-creation-channels
- Microsoft Learn, “Conditional Access for agents”, June 2026, retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id
- Microsoft Learn, “ID Protection for agents”, June 2026, retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/id-protection/concept-risky-agents
- Microsoft Learn, “Agent owners, sponsors and managers”, April 2026, retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/agent-id/agent-owners-sponsors-managers
- Microsoft Learn, “Secure a Model Context Protocol (MCP) server with Microsoft Entra ID”, September 2026, retrieved 2026-09-30, https://learn.microsoft.com/en-us/entra/agent-id/secure-mcp-server-with-entra-id
- Microsoft Security Blog, “Microsoft Agent 365, now generally available, expands capabilities and integrations”, 2026-05-01, retrieved 2026-09-30, https://www.microsoft.com/en-us/security/blog/2026/05/01/microsoft-agent-365-now-generally-available-expands-capabilities-and-integrations/
- Keycloak project, 26.6.0 release notes (federated client authentication and JWT Authorization Grant), retrieved 2026-09-30, https://github.com/keycloak/keycloak/blob/26.7.4/docs/documentation/release_notes/topics/26_6_0.adoc
- Keycloak project, “Integrating with Model Context Protocol (MCP)” guide source at 26.7.4, retrieved 2026-09-30, https://github.com/keycloak/keycloak/blob/26.7.4/docs/guides/securing-apps/mcp-authz-server.adoc
- Keycloak project, 26.2.0 release notes (supported standard token exchange), retrieved 2026-09-30, https://github.com/keycloak/keycloak/blob/26.7.4/docs/documentation/release_notes/topics/26_2_0.adoc
- Keycloak project, 26.7.0 release notes (token exchange delegation, experimental), retrieved 2026-09-30, https://github.com/keycloak/keycloak/blob/26.7.4/docs/documentation/release_notes/topics/26_7_0.adoc
- Keycloak project, token exchange guide source at 26.7.4, retrieved 2026-09-30, https://github.com/keycloak/keycloak/blob/26.7.4/docs/guides/securing-apps/token-exchange.adoc
- Keycloak project, “Resource Indicators for OAuth 2.0 (RFC 8707)”, issue #14355, retrieved 2026-09-30, https://github.com/keycloak/keycloak/issues/14355