Which Identity Providers Support AI Agent Management?

TL;DR

Microsoft Entra, Google Cloud IAM, Okta and Ping Identity each ship a distinct agent identity object you can manage today. Auth0 and Keycloak do not, and hand you delegation primitives to build one.

That's the ranked answer. The qualification matters more than the ranking.

Nearly all of what shipped governs the agent as a machine principal: a directory object, a credential, some review machinery bolted on. Much less of it governs an agent acting for a named person, which is the situation most enterprise agents are actually in.

So "supports AI agents" does not mean what people read it as. No IdP decides whether this agent, carrying this adjuster's authority, may close this claim. It issues a token. Your application still owns that decision.

Which makes the practical move small. Register the agent in the IdP you already run, take the short-lived credential, and put the user-scope intersection check somewhere you control.

Overview

Take a claims-triage agent at a mid-size insurer. It runs in Azure, reads adjuster mailboxes through Microsoft Graph, and writes decisions into a policy administration system behind an API gateway. Three hundred adjusters use it, and each one can see a different subset of claims. Two weeks after launch, security asks the platform team a reasonable question: is this thing in our identity provider?

The honest answer in September 2026 is "partly, and it depends which of four things you mean." Every major IdP has shipped something agent-shaped in the last eighteen months, the announcements all use the same vocabulary, and the capabilities behind that vocabulary differ enormously. Some of it is a genuine new object type in the directory. Some of it is a service principal with a label on it.

What follows is an inventory: for each vendor, what their own current documentation says exists, and the line where it stops. Every claim below was checked against the vendor's docs or announcement on 2026-09-25, with URLs at the bottom. Where we couldn't verify something, it isn't here.

The concepts live elsewhere: identity for AI agents as a primer, SPIFFE for the cryptographic half, cross-app access for the federation standards. This is the vendor-by-vendor reference we wanted and couldn't find.

What "Support" Actually Means

Four separate capabilities travel under one phrase, and vendors rarely separate them:

1. A principal. A directory object for the agent, distinct from a user and from an app registration, that you can list, own and disable.
2. A credential. Authentication without a static secret pasted into a config file.
3. Lifecycle and governance. Creation, a named human accountable, reviews, expiry, disable.
4. Delegated authority. The agent acts as a specific person, and the token records both parties.

Most of the market now ships the first three. The fourth is thin everywhere, and it's the one the claims-triage agent depends on.

Table 1 — Agent-management capability by identity provider, from each vendor's current documentation as checked on 2026-09-25. "No agent object" means no first-class directory type, not an absence of useful primitives.

Figure 1 — The four capabilities that get called "agent support". The first three are widely shipped; the fourth is where every vendor's coverage gets patchy, and the intersection check at the end belongs to your application either way.

Microsoft Entra

Entra is the most complete of the set, and the most licensed.

Microsoft Entra Agent ID introduces four new object types: an agent identity blueprint, an agent identity blueprint principal, an agent identity, and an agent user. The blueprint is a template, and an agent created from it can get one or more agent identities plus optionally an agent user for each. Microsoft is explicit about why these aren't just service principals. Application identities "carry the expectation of long-term stability, known ownership, and managed lifecycle", whereas an agent "might exist for minutes during a specific task, or might be created and destroyed thousands of times per day".

The agent user is the interesting hack. Some systems refuse to talk to anything that isn't a user account, so Entra pairs an agent identity with a "special Microsoft Entra user account" one-to-one. Which also means an agent can appear in your directory wearing a user's clothes. Worth knowing before you audit your own user list.

Both delegation models are documented: autonomous access using rights granted to the agent identity directly (Graph permissions, Azure RBAC, directory roles, app roles), and delegated access where "agents can act on behalf of human users, using access rights given to the user". Governance is real too. Sponsors are human users accountable for an agent's lifecycle, sponsorship transfers automatically to the sponsor's manager when they leave, agents can be assigned access packages through entitlement management, and Conditional Access applies at the blueprint level so every agent minted from a blueprint inherits it.

Where it stops is licensing. Agent ID itself "is available for all Microsoft Entra customers", but "extending Microsoft Entra security features to agents requires Microsoft Agent 365", included with Microsoft 365 E7 and sold as an add-on to E5, A5 or Business Premium. Governance needs E7, or Agent 365 with at least Entra P1 or Microsoft 365 E3. The directory object is free; the controls you'd want around it are a purchase.

Okta and Auth0

Okta went at this from the connection rather than the directory.

Agent SSO became generally available on 24 August 2026, and it's "included in core Okta SSO at no additional cost". When a Cross App Access agent connects to an enterprise application, "Okta registers it as a first-class identity in Universal Directory alongside human employees, then issues short-lived, identity-governed tokens." Registration is a side effect of the agent connecting through the protocol, not something an admin does up front.

The rest of the line arrived at Oktane 2026. Agent SSO, Agent-to-Agent Connections and Resource Access Certifications are listed as generally available. Agent Gateway and Shadow AI Agent Discovery for Endpoints appear in the same announcement with availability dated after it, so treat those as announced rather than running.

Cross App Access matters beyond Okta because it got standardized. The mechanism is the Identity Assertion JWT Authorization Grant, an active OAuth working group draft, and MCP adopted it as the io.modelcontextprotocol/enterprise-managed-authorization extension, now marked stable. The extension is blunt about the problem: in default MCP "each user independently authorizes an MCP client to access each MCP server", so "offboarding requires revoking access across every service individually".

Auth0, which Okta owns, gives a different answer. Auth0 for AI Agents names six capabilities: user authentication, fine-grained authorization, asynchronous authorization, call your APIs on users' behalf, call others' APIs on users' behalf, and authorization for RAG. No agent principal in there. What there is instead is Token Vault, which "simplifies how your applications access external APIs on a user's behalf" by holding access and refresh tokens for connected providers, across social providers like Google, Slack and GitHub and enterprise ones including Google Workspace and Entra ID. Okta gives the agent an identity. Auth0 gives your application the user's credentials for somewhere else. Not substitutes.

Agent --ID token--> IdP (evaluates rules) --ID-JAG--> Agent Agent --ID-JAG--> Resource Auth Server --access token--> Agent --> Claims API No per-server consent screen. Revocation happens once, at the IdP. -->

Figure 2 — The ID-JAG flow behind Okta's Cross App Access and MCP's enterprise-managed authorization extension. The user never sees a per-server consent screen, and access is withdrawn at the IdP rather than service by service.

Google

Google's two halves are nothing like each other, and people conflate them constantly.

Google Cloud IAM shipped Agent Identity, which "provides a strongly attested, cryptographic identity for each agent that is based on the SPIFFE standard". The identity is a SPIFFE ID shaped like spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH, bound to the resource hosting the agent, and it appears in IAM allow policies under a matching principal:// identifier. The design constraints are the good part: "unlike service accounts, agent identities are not shared by multiple workloads by default, can't be impersonated, and don't allow developers to generate long-lived service account keys." Four authentication models are documented, including user-delegated three-legged OAuth for acting on behalf of a specific person. The Agent Identity API entered Preview on 18 June 2026 and went generally available, with the credentials API and the auth manager, on 22 August 2026.

Google Workspace has none of this. If your agent needs to read an adjuster's Gmail or Calendar on their behalf without sitting in front of them, the mechanism is still a service account with domain-wide delegation, authorized by a super admin in the Admin console against a client ID and a scope list. Google's own best-practice page is unusually direct: "Avoid using domain-wide delegation if you can accomplish your task directly using a service account or by using OAuth consent," and use it "only when you have a critical business case that requires an app to bypass user consent." Scope restrictions don't stop a delegated service account impersonating any user in the domain within those scopes.

So Google has a better-than-average agent identity in Cloud and, for the Workspace data most agents actually want, an impersonation mechanism its own documentation tells you to avoid.

Ping and Keycloak

Ping Identity announced general availability of Identity for AI in March 2026, globally by 31 March. It's three parts. Agent IAM Core "enables enterprises to onboard, manage, authenticate, and authorize AI agents in real time as a new identity type". Agent Gateway "provides a runtime enforcement layer that standardizes how agents interact with services, invokes fine-grained authorization, and centralizes monitoring". Agent Detection, riding on PingOne Protect, does runtime detection and risk assessment. The stated architectural position is "delegated, scoped tokens instead of human impersonation or shared credentials", standardized "across emerging AI integration frameworks, including the Model Context Protocol".

Keycloak has no agent object and no agent product, and if you self-host it that's the situation to plan around. What it does have is token exchange, described more sharply than most vendor pages manage. Standard token exchange V2 implements RFC 8693, is fully supported, and is on by default. But it covers exactly one case: exchanging a token issued to one client for a token issued to another client in the same realm. The requesting client must be confidential, and subject_token_type must be an access token because "Keycloak does not support other types for the standard token exchange". Impersonation and external exchange live only in the legacy V1 feature, which is both a preview feature and deprecated.

Delegation, the thing an agent acting for a person needs, is a separate experimental feature. Enabling token-exchange-delegation alongside parameterized-scopes lets a subject pre-authorize an actor, shows the user a consent screen, and issues a token carrying the may_act claim. The docs warn: "Do not use this feature in production environments." We'd take that at face value.

The Standards Doing the Actual Work

Strip the product names away and the same small stack is underneath all of it.

OAuth 2.1 is still a draft. Revision 16 landed on 3 September 2026 and it is not an RFC. It consolidates existing guidance rather than inventing much, so building to it is reasonable, but nobody should call it finished.

RFC 8693 token exchange is the mature piece, and it's how a token ends up naming two parties: the user as sub and the agent as a nested act actor claim, with may_act controlling who may act for whom. Keycloak's experimental delegation feature issues exactly that claim.

Identity chaining carries the result across trust boundaries. Draft 17 of "OAuth Identity and Authorization Chaining Across Domains" is dated 19 July 2026, and its "Identity Assertion JWT Authorization Grant" profile reached draft 04 in May 2026. Both are active OAuth working group documents, and that pair, not any vendor's product, is what makes Cross App Access and MCP's enterprise-managed authorization interoperable. SPIFFE sits underneath as the workload identity layer, and Google's Agent Identity is a direct application of it.

SCIM handles lifecycle, with a limit: RFC 7643 defines User, Group and an Enterprise User extension as its core schemas. No agent resource type. Model agents as users, which is the only option, and your HR-driven joiner-mover-leaver process is now inventorying things that never had an employment contract.

The agent-specific proposals are worth watching and not worth building on. "OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents", which proposed requested_actor and actor_token parameters, is an individual submission whose revision 02 dates to August 2025 and has expired. draft-klrc-aiagent-auth and the Delegated Agent Authorization Protocol draft are individual submissions too. None is a working group document.

Where Fabriq Fits

Agentic Fabriq sits downstream of whichever IdP you picked above, and consumes it rather than replacing it. Sign in is Okta or OIDC SSO against the directory you already run, with immediate session revocation.

The part that matters for the claims-triage agent is the resolution step. Every request carries two identities, the agent's and the acting user's, and the effective tool list is the intersection of the two scope sets rather than the agent's own grant. Access is default-deny across org, team and member with per-user overrides, and action-level permissions are enforced in the backend rather than advertised in a tool description. Credentials are per-user and held in a vault with call-time injection, so a token for an adjuster's mailbox is a token for that adjuster only. That's the layer-four work from Figure 1, and it's deliberately not an identity provider. The longer version is in permissioning, audit and revocation.

Frequently Asked Questions

Which identity providers support AI agent management? As of September 2026, Microsoft Entra (Agent ID), Google Cloud IAM (Agent Identity), Okta (Agent SSO and Okta for AI Agents) and Ping Identity (Identity for AI) all provide a distinct agent identity type you can register, own and disable. Auth0 and Keycloak provide delegation and credential primitives without a first-class agent object. Google Workspace has no agent identity and still relies on service accounts with domain-wide delegation.

Does Microsoft Entra support AI agents? Yes. Entra Agent ID adds agent identities, blueprints and optional paired agent user accounts, and is available to all Entra customers. Extending Entra's security and governance features to those agents requires a Microsoft Agent 365 license, included with Microsoft 365 E7 and sold as an add-on to E5, A5 or Business Premium.

Does Okta support AI agents? Yes. Agent SSO went generally available on 24 August 2026 and is included in core Okta SSO at no extra cost. It registers agents connecting through Cross App Access as identities in Universal Directory and issues short-lived tokens in place of static keys.

Can Google Workspace manage AI agent access? Not with a dedicated agent identity. Access to Workspace data on a user's behalf still goes through OAuth consent or a service account with domain-wide delegation, and Google's own guidance says to avoid domain-wide delegation unless you have a critical business case that requires bypassing user consent.

Does Auth0 have agent identity? Not as a directory object. Auth0 for AI Agents covers user authentication, fine-grained authorization, asynchronous authorization, calling your own and third-party APIs on a user's behalf, and authorization for RAG. Token Vault holds external provider tokens so your app can act for a user.

Does Keycloak support AI agents? Not directly. There is no agent identity type. Standard token exchange (RFC 8693) is supported and on by default but limited to client-to-client exchange inside one realm, and the delegation feature that would let a user pre-authorize an agent is experimental with a documented warning against production use.

Can SCIM provision AI agents? Only by modeling them as users. SCIM's core schemas are User, Group and the Enterprise User extension, with no agent resource type.

What is the difference between a service account and an agent identity? A service account assumes a stable, long-lived workload. Agent identities are built for things created and destroyed in bulk, and the newer implementations add constraints service accounts lack. Google's agent identities are not shared between workloads by default, cannot be impersonated, and cannot have long-lived keys generated for them.

Do I need a new identity provider for AI agents? Almost certainly not. Every vendor above bolted agent support onto the product you already run. What remains is deciding what an agent may do to a specific record while carrying a specific person's authority, and no IdP does that for you.

Conclusion

The market moved fast and unevenly. Eighteen months ago the answer here was "none of them, use a service account and hope." Now four major providers have a real agent principal, the credential story has improved a lot, and lifecycle governance exists where you're willing to pay for it.

The layer that hasn't arrived is the one the claims-triage agent needs. Entra documents delegated access, Google supports three-legged OAuth from an agent identity, Okta and Ping both talk about delegated scoped tokens, and in every case the token lands in your application, which decides whether this agent, acting for this adjuster, may close this claim. That decision isn't in the IdP and we don't expect it to move there. It depends on your data model.

Pick the IdP you already own. Register every agent in it so somebody human is accountable and the kill switch exists. Then write down where the intersection check lives, because if you can't name that place, it isn't happening.

Sources

All URLs checked 2026-09-25.

• What are agent identities? Microsoft Entra Agent ID
• Governing Agent Identities, Microsoft Entra ID Governance
• Okta brings first-class identity to AI agents with Agent SSO (24 August 2026)
• New Okta for AI Agents innovations, Oktane 2026
• Auth0 for AI Agents
• Auth0 Token Vault documentation
• Agent Identity overview, Google Cloud IAM
• Google Cloud IAM release notes
• Domain-wide delegation best practices, Google Workspace Admin
• Ping Identity Defines the Runtime Identity Standard for Autonomous AI (24 March 2026)
• Configuring and using token exchange, Keycloak
• Enterprise-Managed Authorization, Model Context Protocol
• The OAuth 2.1 Authorization Framework, draft-ietf-oauth-v2-1-16
• OAuth 2.0 Token Exchange, RFC 8693
• OAuth Identity and Authorization Chaining Across Domains, draft-17
• Identity Assertion JWT Authorization Grant, draft-04
• OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents (expired individual draft)
• SCIM Core Schema, RFC 7643 </content>

</invoke>