Classified comparison

AI agent identity tools, classified by what they do

The question this page answers is narrow: given a deployment, which of these products behaves the way you need? Not which is best — there is no best here, because the products answer different questions and the constraints differ by deployment.

The basis is the Agent Access Control Taxonomy, an open, vendor-neutral vocabulary of nine dimensions. We publish it, and we apply it the same way to every entry below, including our own. Each entry describes what a product does on each dimension and cites the vendor’s own current documentation. Nothing is scored and nothing is ranked: entries are grouped by what the product primarily does, and alphabetised inside each group.

Comparison checked: 29 October 2026·Sources read: 12 October 2026 unless an entry says otherwise·11 products · 9 dimensions

Published by Agentic Fabriq. We make one of the eleven products classified below, so this page is first-party content, not an independent evaluation. We do not score any product, including our own, and there is no winner. What we do instead is apply the same nine questions to every entry, cite each vendor’s own documentation, and state each product’s limits — ours in the same words and the same place as everyone else’s. Our own entry is in the third group, filed under its behaviour rather than its marketing.

If you would rather check our claims than read them: how agent scopes and user grants intersect on every call, what the audit trail records on every call, denials included, how unregistered agents get discovered, Fabriq Developer, for agents acting on your own customers’ accounts, and the Developer Quickstart: register an agent and make a governed call in about ten lines.

How every entry on this page was decided

Four rules, stated plainly so you can check whether we followed them.

One fixed question set, applied identically. Every product is described against the same nine dimensions below, in the same order, using the taxonomy’s own terms. No dimension was added or dropped to suit a particular product, including ours.
The vendor’s own current documentation, or nothing. Each row comes from a page linked in that entry, with the date it was read. Nothing here is classified from a press summary, an analyst note or memory. Where a vendor’s documentation does not settle a dimension, the row reads not classified rather than carrying a guess.
No scores, no ranking, no winner. Entries are grouped by what the product primarily does and alphabetised inside each group. Which behaviour is correct depends on the deployment, so a single ordering would be a claim we cannot support.
Every entry states what the product does not do. Including ours, in the same field and the same voice. An entry with no limits section would mean we had not read far enough.

On the 29 October 2026 pass, the Agentic Fabriq and Arcade entries were re-read against their live sources and carry that date; the other nine still rest on the 12 October 2026 reading, and each says so under its own source list. This category ships quickly, so treat any entry as a dated reading rather than a standing fact.

The nine dimensions

Each dimension is a question with a closed set of answers. Term ids take the form aact:<dimension>/<term>, and the terms used below are the taxonomy’s, not ours to redefine per vendor.

Identity modelaact:identity-model: What is the agent, as far as the target system is concerned?
Delegation modelaact:delegation-model: Whose authority is the agent acting with?
Credential modelaact:credential-model: What secret does the agent present, and who holds it?
Authorization modelaact:authorization-model: How is each action the agent attempts decided?
Enforcement pointaact:enforcement-point: Where is the authorization decision enforced?
Failure behavioraact:failure-behavior: What happens when an authorization decision cannot be made?
Human oversightaact:human-oversight: When does a person get involved in an agent’s actions?
Audit granularityaact:audit-granularity: What is recorded about agent actions, and who are they attributed to?
Resource surfaceaact:resource-surface: What kinds of systems can the agent reach?

Where a vendor’s own documentation does not settle a dimension, the row below says so instead of guessing. Several dimensions — failure behavior in particular — are properties of a deployment rather than of a product, and are often genuinely not the vendor’s to state.

Directory and governance platforms that have extended to agents

These products start from the enterprise directory. An agent becomes a managed identity in the same tenant as the employees, governed with the same consoles, policies and reviews.

Microsoft Entra Agent ID

An agent identity in Entra is “a special service principal in Microsoft Entra ID”, created from a reusable template called an agent identity blueprint. Each deployed agent gets its own identity with its own permissions on downstream resources; the blueprint records the kind of agent, the roles it offers and the Microsoft Graph permissions its agents are granted. An identity can carry a sponsor — “the human user or group that’s accountable for an agent” — and, where a system insists on a user account, a paired agent’s user account.

Identity model

aact:identity-model/per-agent-identity

Each agent has its own registered service principal, revocable on its own; blueprint-level operations act on every agent of a kind at once.

Delegation model

aact:delegation-model/autonomous
aact:delegation-model/on-behalf-of-user

Autonomous agents acquire app tokens as the agent identity; interactive agents called with a user token acquire user tokens where “the subject of the token is a user, while the actor is the agent identity.”

Credential model

aact:credential-model/brokered-short-lived-token

Agent identities “don’t have credentials of their own” — the blueprint holds the federated identity credentials, certificates or client secrets and acquires tokens on the agent’s behalf.

Authorization model

aact:authorization-model/scope-at-grant
aact:authorization-model/role-based

Permissions come from consented Graph scopes and the roles declared on the blueprint; Conditional Access can be applied to every agent of a kind, which gates token issuance rather than each later call.

Enforcement point

aact:enforcement-point/target-system

Entra issues the token; Microsoft Graph and the other Entra-protected resources enforce what it allows.

Failure behavior

not classified

Not a property of the platform: token issuance fails closed, but what an agent does when a call is refused is left to the agent.

Human oversight

aact:human-oversight/post-hoc-review

A sponsor is recorded as accountable, and an administrator can disable all agents of a kind or revoke a permission grant for them; no per-action approval step is part of the identity itself.

Audit granularity

aact:audit-granularity/session-level

Entra records token issuance against the agent identity; because user tokens carry the user as subject and the agent as actor, a resource that logs calls can attribute them to both.

Resource surface

aact:resource-surface/saas-api

Microsoft Graph and other Entra-protected APIs, and only inside one tenant: “agent identities can only be issued tokens in the Microsoft Entra tenant where they’re created.”

Right choice when: A Microsoft-centred estate where the agents you care about run against Microsoft Graph and Entra-protected APIs, and you want them administered next to employees — one console, Conditional Access, blueprint-wide disable and grant revocation.

What it does not do: Agent identities are single-tenant and the permission model is the Entra permission model, so third-party SaaS that issues its own tokens sits outside it. Per-action decisions and per-call records are whatever the target resource provides.

Read on 12 October 2026: Overview of agent identities in Microsoft Entra (Microsoft Learn)

Okta (Okta for AI Agents, Agent SSO, Cross App Access)

Okta sells agent identity as a lifecycle: discovery of unvetted agents across “browsers, managed endpoints, and cloud environments”, registration with “verified identities with clear human owners”, scoped credentialing, runtime governance, access reviews, and decommissioning through “a programmatic kill switch”. Agent SSO registers an agent that supports Cross App Access as a first-class identity in Universal Directory and issues “short-lived, identity-governed tokens in place of stored credentials”; Okta says it went generally available on 24 August 2026 and is included in core SSO plans, with Okta for AI Agents a separate subscription generally available since May 2026. Cross App Access is described as “an open, vendor-neutral protocol” that “extends OAuth” and has been “formally incorporated as the official Enterprise-Managed Authorization extension for the Model Context Protocol”. An Agent Gateway puts “identity, policy, and audit controls in the path of every tool call”.

Identity model

aact:identity-model/per-agent-identity

The agent is registered in Universal Directory with a named human owner and managed with the same policies as workforce identities.

Delegation model

aact:delegation-model/on-behalf-of-user
aact:delegation-model/agent-to-agent

Cross App Access carries identity between applications as the agent moves across them, as an OAuth extension rather than a credential copied forward.

Credential model

aact:credential-model/brokered-short-lived-token

Short-lived cryptographic credentials in place of static API keys, with the gateway able to “broker credentials at runtime”.

Authorization model

aact:authorization-model/per-action-policy

Least-privilege policy is evaluated in the path of each tool call through the Agent Gateway, alongside relationship-based authorization policies.

Enforcement point

aact:enforcement-point/gateway

The Agent Gateway sits in front of the tools and, Okta says, works “without making code changes”.

Failure behavior

not classified

Not stated on the pages read.

Human oversight

aact:human-oversight/post-hoc-review

Access reviews and decommissioning are part of the advertised lifecycle; the material read describes review and shutdown rather than a per-action approval queue.

Audit granularity

aact:audit-granularity/per-action

The gateway is described as logging “each tool call”, with SIEM-integrated audit logging for regulated environments.

Resource surface

aact:resource-surface/saas-api
aact:resource-surface/mcp-server

Applications reached through Cross App Access and tools reached through MCP, which XAA now extends.

Right choice when: You already run Okta for your workforce, your problem statement includes “we do not know how many agents are running”, and you want discovery, ownership, reviews and shutdown in the same place as employee access. Also the right choice if the applications your agents touch are adopting Cross App Access, since the protocol is the part that travels.

What it does not do: The agent-specific pieces are newer than the directory underneath them, and Okta’s own page carries the caveat that some described features “are not currently generally available” and “may not be delivered on time or at all” — worth confirming per feature against your contract rather than against a comparison page.

Read on 12 October 2026: Okta for AI Agents (product page); Okta brings first-class identity to AI agents with Agent SSO (press release)

Ping Identity (Identity for AI)

Ping announced Identity for AI generally available in March 2026, in three parts. Agent IAM Core lets organisations “onboard, manage, authenticate, and authorize AI agents in real time as a new identity type”. Agent Gateway, built on PingGateway, “standardizes how agents interact with services, invokes fine-grained authorization, and centralizes monitoring and audit of agent activity” and is positioned to “protect the MCP servers, APIs, and resources that agents call at runtime”. Agent Detection, via PingOne Protect, identifies agent activity from “bot authentication protocols and behavioral signals” and feeds the result into authorization decisions. The documentation is explicit that agents “act on behalf of users through delegation, not impersonation”, using “delegated access, scoped tokens, and least-privilege controls”.

Identity model

aact:identity-model/per-agent-identity

Agents are registered and treated as managed digital identities of their own type, with their own lifecycle.

Delegation model

aact:delegation-model/on-behalf-of-user

Delegation is the stated model and impersonation is the stated anti-pattern: the agent carries delegated entitlements rather than becoming the user.

Credential model

aact:credential-model/brokered-short-lived-token

Agents get unique credentials and scoped tokens rather than shared service-account secrets.

Authorization model

aact:authorization-model/per-action-policy

The gateway invokes fine-grained authorization as requests pass, with risk signals from Agent Detection available as input.

Enforcement point

aact:enforcement-point/gateway

PingGateway validates requests and enforces policy in front of the MCP servers and APIs the agent calls.

Failure behavior

not classified

Not stated on the pages read.

Human oversight

aact:human-oversight/post-hoc-review

Detection is framed as spotting “behavior that might require closer review”; the pages read describe review and risk routing, not an approval gate on individual actions.

Audit granularity

aact:audit-granularity/per-action

The gateway creates “centralized audit trails of all agent activity”, with filtering for agent traffic specifically.

Resource surface

aact:resource-surface/mcp-server
aact:resource-surface/saas-api
aact:resource-surface/internal-network

MCP servers, APIs and other resources behind the gateway, including in Ping’s self-managed deployment option.

Right choice when: You are a Ping customer, or you need the agent layer to run self-managed rather than as SaaS — Ping ships these capabilities in Advanced Identity Software as well as PingOne. The detection piece is the distinctive one if your concern is unmanaged third-party agents arriving at your own front door.

What it does not do: The credential and authorization detail that matters for an implementation lives in product documentation rather than the solution pages, so treat the summary above as the shape of the offering and not as an integration guide.

Read on 12 October 2026: Identity for AI Solutions (Ping Identity documentation); Ping Identity Defines the Runtime Identity Standard for Autonomous AI (press release)

Developer identity platforms that make an application agent-ready

These products are bought by the team building the application. They answer two questions: how does an agent authenticate to my API, and how does my application get a token for somebody else’s API on a user’s behalf.

Auth0 (Auth for GenAI)

Auth0 adds four things to its existing identity platform. Universal Login authenticates the user for interactive and headless agents. Token Vault “manages obtaining, storing, and refreshing API tokens, allowing your agents to interact with third-party APIs without handling sensitive credentials or API keys directly.” Asynchronous authorization uses Client-Initiated Backchannel Authentication so that “agents can request approval for sensitive operations via push notifications, SMS, or email, even when the user is not actively using the application.” Auth0 FGA applies document-level authorization inside retrieval pipelines so a model “only uses data that the current user is authorized to view”.

Identity model

aact:identity-model/per-agent-identity

The agent is modelled as its own OAuth client in the tenant, distinct from the user it serves.

Delegation model

aact:delegation-model/on-behalf-of-user
aact:delegation-model/on-behalf-of-end-customer

The agent acts for an authenticated user of your application, which in a B2B product is your customer’s user against their own third-party accounts.

Credential model

aact:credential-model/brokered-short-lived-token

Third-party refresh tokens stay in Auth0’s vault and your backend exchanges for an access token when it needs one, so the long-lived secret is not in the agent.

Authorization model

aact:authorization-model/scope-at-grant
aact:authorization-model/per-action-policy

Third-party access is bounded by the scopes the user consented to; FGA evaluates relationship-based policy per document at retrieval time.

Enforcement point

aact:enforcement-point/in-agent-code
aact:enforcement-point/target-system

Your application calls the SDK before it calls a tool; there is no proxy in front of the traffic, and the third-party API enforces the token it was given.

Failure behavior

not classified

Determined by your code: the SDK raises when a token or approval is missing, and what the agent does next is up to it.

Human oversight

aact:human-oversight/approval-for-high-risk

CIBA is a genuine out-of-band approval step: the agent blocks on a named user approving a specific operation on their own device.

Audit granularity

aact:audit-granularity/session-level

Auth0 records its own authentication and authorization events; logging each tool call remains your application’s job.

Resource surface

aact:resource-surface/saas-api
aact:resource-surface/database
aact:resource-surface/file-store

Third-party and first-party APIs through Token Vault, and the document stores behind a RAG pipeline through FGA.

Right choice when: You are building the agentic product and already use Auth0 for its users. It is the clearest option on this page if your requirement is a human approving a specific action out of band — CIBA is the feature, and few others in this set document an equivalent.

What it does not do: This is a library-and-API layer, not a control plane over agents your colleagues run. Nothing sits in the call path by default, so coverage is exactly as good as your code’s discipline in going through it.

Read on 12 October 2026: Auth for GenAI (Auth0 documentation); Auth0 for AI agents (product page)

Descope (Agentic Identity Hub)

Descope splits the problem in two. Inbound Apps turn your application into its own OAuth identity provider so agents can “authenticate, access authorized user data, and take scoped actions on behalf of users with their explicit consent”. Outbound Apps are a token vault for the other direction — “Descope securely stores and manages all tokens and API keys, making them available for backend or agent use”, across 50-plus SaaS integrations, with incremental scopes requested “only when needed” and stored tokens carrying both an associated user and a tenant id. An Agentic Identity Control Plane adds policy-based governance, auditing and lifecycle management for agents and MCP clients and servers.

Identity model

aact:identity-model/per-agent-identity

Inbound Apps register each agent or MCP client as its own OAuth client of your application.

Delegation model

aact:delegation-model/on-behalf-of-user
aact:delegation-model/on-behalf-of-end-customer

Consent is per user and tokens are held per user and per tenant, which is the B2B2C shape.

Credential model

aact:credential-model/brokered-short-lived-token

Tokens live in Descope and your backend fetches and refreshes them through the API; the agent’s own runtime can be kept out of the path, but the backend does receive the token.

Authorization model

aact:authorization-model/scope-at-grant

Access is bounded by the consented scopes, widened incrementally when a task needs more.

Enforcement point

aact:enforcement-point/in-agent-code
aact:enforcement-point/target-system

Your backend decides when to pull a token; the third-party provider enforces what the token permits.

Failure behavior

not classified

Determined by your code, not by the platform.

Human oversight

aact:human-oversight/post-hoc-review

Explicit user consent at connect time, plus governance and auditing in the control plane; no per-action approval step in the documentation read.

Audit granularity

aact:audit-granularity/session-level

The control plane is described as auditing agents and MCP clients and servers; per-call records are not described in the Outbound Apps documentation.

Resource surface

aact:resource-surface/saas-api
aact:resource-surface/mcp-server

The 50-plus outbound SaaS integrations, plus whatever your own Inbound App exposes, including remote MCP servers.

Right choice when: You are shipping a product that needs both directions at once — agents calling your API with user consent, and your agents calling Gmail, Slack or Snowflake for each of your users. Outbound Apps is the piece to compare if you are otherwise about to build a token vault yourself.

What it does not do: Descope is bought by the application team. It is not a way to govern the agents your employees install, and the per-call record an auditor asks for is not part of what the documentation read describes.

Read on 12 October 2026: Outbound Apps (Descope documentation); Descope announces Agentic Identity Hub (press release)

Stytch (Connected Apps)

Stytch makes your application an OAuth authorization server so an agent or MCP client can get a user-consented token for it. Dynamic client registration is optional — “the MCP Client can send a Dynamic Client Registration (DCR) request to your Stytch Project’s DCR Endpoint and be granted a unique client_id on the fly” — or clients can be configured in advance. The flow is OAuth 2.1 with a PKCE code challenge, consent is rendered by Stytch’s own identity-provider component, and the scopes on offer are published in your protected resource metadata. Your MCP server stays the resource server: it “should validate that the request contains a valid Stytch-issued access token JWT”.

Identity model

aact:identity-model/per-agent-identity

Each agent or MCP client is a distinct OAuth client of your application, registered up front or on the fly.

Delegation model

aact:delegation-model/on-behalf-of-user

The token is issued after a named member consents, and the agent acts within that consent.

Credential model

aact:credential-model/brokered-short-lived-token

The agent holds the Stytch-issued access token and sends it in the Authorization header; Stytch does not hold credentials for anyone else’s API on the agent’s behalf.

Authorization model

aact:authorization-model/scope-at-grant

The consented scopes decide what the token can do; individual calls are checked against the token, not re-evaluated against policy.

Enforcement point

aact:enforcement-point/target-system

Your MCP server or API validates the JWT and enforces the scopes itself.

Failure behavior

not classified

Determined by your resource server’s handling of an invalid or missing token.

Human oversight

aact:human-oversight/post-hoc-review

Consent at authorization time; no approval step on individual actions in the documentation read.

Audit granularity

not classified

Not described in the Connected Apps documentation read.

Resource surface

aact:resource-surface/mcp-server
aact:resource-surface/saas-api

Your own application and the remote MCP server you put in front of it.

Right choice when: You own an API or a remote MCP server and need third-party agents to reach it under user consent, with standards-correct OAuth 2.1 and dynamic client registration you did not have to implement.

What it does not do: This is the inbound half only. It does not broker credentials for the third-party services your own agents need to call, and it is not where you would govern a fleet of internal agents.

Read on 12 October 2026: MCP authorization overview (Stytch documentation); Integrate with AI agents (Stytch documentation)

WorkOS (AuthKit Agent Registration)

Agent Registration “enables AI agents and LLM-based clients to obtain identity credentials from your AuthKit-powered service”, with two paths. Service auth is for when “the agent knows the user’s email and needs trusted access” and requires a claim ceremony — a device-flow-like exchange where the user signs in, reads a short code and relays it to the agent. Anonymous registration is for when “the agent has no user identity and wants to trial the service”, with claiming deferred. Permissions come in two tiers, untrusted before a claim and trusted after. Agent blueprints mint credentials server-side: “minting is a server-side call authenticated with your WorkOS API key — your backend requests the token and hands the resulting agent token to your agent”, and “the credential type (access token or API key) and its lifetime are configured per environment”. Issued tokens carry an `act` claim “identifying the user who authorized the agent”, following RFC 8693.

Identity model

aact:identity-model/per-agent-identity

Every agent registration is its own identity against your service, created from a blueprint and separately claimable.

Delegation model

aact:delegation-model/on-behalf-of-user
aact:delegation-model/autonomous

A claimed registration carries the authorising user in the token’s `act` claim; an unclaimed one has no user behind it and gets untrusted permissions.

Credential model

aact:credential-model/brokered-short-lived-token
aact:credential-model/static-secret-in-agent

Which one you get is a configuration choice: short-lived access tokens, or durable API keys that the agent then holds for as long as they live. Either way the agent holds the credential and never your WorkOS API key.

Authorization model

aact:authorization-model/scope-at-grant

The trusted or untrusted tier is fixed when the credential is minted; your own API decides what each call may do.

Enforcement point

aact:enforcement-point/target-system

Your service validates the JWT locally — “verifying the signature and checking expiration” — and enforces from there.

Failure behavior

not classified

Determined by your service.

Human oversight

aact:human-oversight/post-hoc-review

The claim ceremony puts a human in the loop once, when the agent is adopted; actions afterwards are not individually approved.

Audit granularity

not classified

Not described in the Agent Registration documentation read.

Resource surface

aact:resource-surface/saas-api
aact:resource-surface/mcp-server

Your own API and MCP endpoints — this is about agents coming in, not about the SaaS your agents go out to.

Right choice when: You are an API or SaaS vendor and want agents to sign themselves up without a human in the browser, then be adopted by a real user later. The untrusted-then-claimed progression is the distinctive design: it gives an unattended agent a safe, limited way to start.

What it does not do: Inbound only, and the durable-API-key option is a long-lived secret in the agent’s hands if you configure it that way. No credential brokering for third-party APIs.

Read on 12 October 2026: Agent Registration (WorkOS documentation); Agent Blueprints (WorkOS documentation)

Runtime brokers and gateways in the path of the call

These products sit between the agent and the tools. The decision happens when a call is attempted, and the credential is attached by something other than the agent.

Agentic Fabriq

Our own product, classified on the same dimensions as everything else. Each user connects a provider once; the credential is held in a vault and attached to the outbound call server-side at call time, so it is never in the agent’s context, prompt or logs. Each call records two identities — the agent and the user it acted for — in one audit record. The tool list an agent gets back is the intersection of that user’s grant and the agent’s own scopes, so neither side can widen the other. Anything the layer cannot decide is denied: the default is fail-closed.

Identity model: aact:identity-model/per-agent-identity
Each agent is registered with its own scopes, separate from the users it acts for.
Delegation model: aact:delegation-model/on-behalf-of-user
aact:delegation-model/on-behalf-of-end-customer
Every call is attributed to one named user, including the case where that user is a customer’s employee using their own account.
Credential model: aact:credential-model/credential-never-exposed
The per-user credential stays in the vault and is attached server-side at call time; the agent receives a result, not a token.
Authorization model: aact:authorization-model/intersection-of-agent-and-user
The effective tool list is the intersection of the agent’s scopes and the user’s grant. This is scope arithmetic, not a policy engine: there are no conditions, attributes or rules to write.
Enforcement point: aact:enforcement-point/gateway
The decision is made and the credential attached in the layer, not in the agent and not in the prompt.
Failure behavior: aact:failure-behavior/fail-closed
A missing grant, an unscoped tool or an undecidable call is denied, and the denial is recorded.
Human oversight: aact:human-oversight/post-hoc-review
There is no approval workflow. A person consents when connecting a provider and reviews the audit record afterwards; no action waits for an approver.
Audit granularity: aact:audit-granularity/per-action-with-principal-chain
Each call records the agent, the user it acted for, the tool and the outcome in one record.
Resource surface: aact:resource-surface/saas-api
aact:resource-surface/mcp-server
aact:resource-surface/code-and-shell
Third-party SaaS APIs, tools exposed over MCP, and coding agents reached through the same intersection.

Right choice when: Agents act for named individuals against third-party SaaS, you want the credential never to reach the agent, and you need a per-call record naming both the agent and the person. The intersection rule is the reason to pick it over a plain token vault: a low-privilege user cannot borrow a broadly scoped agent, and a narrow agent cannot be widened by a privileged user.

What it does not do: No approval workflow: nothing holds an action until a human signs off, so if your control has to be a gate rather than a record, this is the wrong layer. No policy engine: if you need conditional or attribute-based rules, the intersection of two scope sets will not express them. No provider-side revocation — clearing a vault copy stops us using the credential, but it does not revoke the grant at Google, Slack or Salesforce. That has to be done in the provider’s own console, and an export taken before the clear is still an export. No payload inspection: we decide on scope, not on the content of a call, so a product that has to redact sensitive data inside a tool call needs something else. And on the developer product our shared provider apps are a paid-plan feature — on the free plan your users authorize through an OAuth app you register, and Gmail and full Google Drive use your own Google app on every plan because Google treats those scopes as restricted.

Read on 29 October 2026: What is Agentic Fabriq; Agent Permissions — how agent and user scopes intersect; Audit Trail — what is recorded on every call; Fabriq Developer — plans, limits and the external-user model; Developer Quickstart — the ten-line integration; Agentic Fabriq pricing — the plan boundary on shared provider apps

Arcade

Arcade describes itself as an actions runtime for agents: it “handles OAuth and manages user tokens, API keys, and secrets for tools like Gmail and Google Drive”, and enforces per-action authorization at runtime. Authorization is scoped to the user the call is made for — “when an agent calls a tool, if the user has not granted the required permissions, Arcade Engine will automatically prompt the user to authorize the tool and coordinate the OAuth 2.0 flow with the service provider.” Each tool declares the scopes it needs. Group-based tool access and contextual access policies control who can invoke which tools, and the platform emits OpenTelemetry audit logs. Its homepage, re-read 29 October 2026, states the same two-sided rule this page classifies us on: agents “act on behalf of the authenticated user, never through broad service accounts” and “every action runs at the intersection of what the user can do and what the agent is scoped to do”, with pre- and post-tool-call hooks that “Inspect every request before it runs and every response before it returns”. Its own production guidance adds a cost worth reading before launch: Arcade’s default OAuth apps “can only be used with the Arcade user verifier, which requires each end user to sign in to an Arcade account that is a member of your project”, so a multi-user product needs its own OAuth app paired with a custom user verifier it writes and hosts.

Identity model

not classified

The unit of identity in a call is the user the tool is executed for; the documentation read does not describe a per-agent registered identity distinct from the calling application.

Delegation model

aact:delegation-model/on-behalf-of-user
aact:delegation-model/on-behalf-of-end-customer

Every tool call is bound to a user id, which in a multi-tenant product is each of your customers’ own users.

Credential model

aact:credential-model/credential-never-exposed

Tokens stay in Arcade’s infrastructure and are not handed to the agent or the model.

Authorization model

aact:authorization-model/per-action-policy

Per-action authorization at runtime, with group and contextual access deciding which users may invoke which tools and scopes.

Enforcement point

aact:enforcement-point/gateway

The Arcade Engine sits between the agent and the tool and executes the call.

Failure behavior

not classified

A missing grant triggers an authorization prompt rather than a silent pass, but the pages read do not state a fail-open or fail-closed posture for an undecidable call.

Human oversight

aact:human-oversight/post-hoc-review

The user is interrupted to consent when a scope is missing; the documentation read does not describe approval of individual actions.

Audit granularity

aact:audit-granularity/per-action

Tool execution is tracked and exported as OpenTelemetry audit logs.

Resource surface

aact:resource-surface/saas-api
aact:resource-surface/mcp-server

A catalogue of SaaS tools, served to agents as hosted MCP servers.

Right choice when: You want a large catalogue of pre-built, authenticated actions rather than wiring providers yourself, and you are happy for the catalogue and the auth to come from the same vendor. The just-in-time consent prompt is well suited to consumer-facing or self-serve products where the user is present.

What it does not do: The tool catalogue is also the coupling: your agents reach providers the way Arcade models them. If you need an identity for the agent itself, distinct from the user, that is not what the documentation read describes. And on a default OAuth app, end-user authorization is tied to project membership, which its docs call “intended for development and single-tenant use” — a multi-user product carries both its own provider apps and a custom verifier route.

Read on 29 October 2026: Arcade documentation (home); How Arcade helps with authorization (Arcade documentation); Arcade homepage — the user-and-agent intersection and tool-call hooks; Secure auth in production (Arcade) — the user verifier and project membership

Gravitee

Gravitee puts one gateway in front of LLM traffic, MCP tool calls and agent-to-agent communication, with an identity layer underneath it. Identity is issued differently per deployment shape: Client ID Metadata Documents “bind desktop productivity agents directly to human workers via your enterprise SSO”; workload agents get “short-lived, auto-rotating SPIFFE/SPIRE cryptographic identities (SVIDs)” that “strictly bound the blast radius to a single hour”; hosted agents use “standard OAuth flows enhanced with CIBA and step-up MFA”. For upstream access it uses token exchange to “securely swap a user’s enterprise session for an upstream-scoped token”, so “the upstream system sees a legitimate token from its own issuer, without the user ever seeing the upstream credential”. It brokers token exchange and consent for third-party MCP servers, and keeps “a crystal-clear, per-user audit trail for every task delegated to an agent”.

Identity model

aact:identity-model/workload-identity
aact:identity-model/per-instance-identity
aact:identity-model/per-agent-identity

Three issuance paths by agent shape: SSO-bound desktop agents, hour-lived SPIFFE SVIDs for workloads, OAuth clients for hosted agents.

Delegation model

aact:delegation-model/on-behalf-of-user
aact:delegation-model/agent-to-agent

Token exchange carries the user’s authority upstream, and the gateway covers agent-to-agent traffic as a first-class protocol alongside LLM and MCP calls.

Credential model

aact:credential-model/brokered-short-lived-token

The upstream credential is never shown to the user or carried by the agent; the gateway swaps a session for a scoped token per upstream.

Authorization model

aact:authorization-model/per-action-policy

Authorization Management enforces “fine-grained, per-entity policies based on exactly who the agent is”, fed by the identity layer.

Enforcement point

aact:enforcement-point/gateway

One gateway for LLM, MCP and agent-to-agent traffic, self-hostable like the rest of the Gravitee platform.

Failure behavior

not classified

Not stated on the pages read.

Human oversight

aact:human-oversight/approval-for-high-risk

CIBA and step-up MFA put a person in the loop at authorization time, and the platform “intercepts upstream consent requirements” and surfaces them in the agent’s UI — consent and step-up rather than a reviewer’s approval queue.

Audit granularity

aact:audit-granularity/per-action-with-principal-chain

A per-user audit trail per delegated task, with identity feeding the gateway “for accurate lineage” so “every automated action traces back to a real person”.

Resource surface

aact:resource-surface/mcp-server
aact:resource-surface/saas-api
aact:resource-surface/internal-network

MCP servers and tool calls, LLM endpoints, agent-to-agent traffic, and internal APIs already behind a Gravitee gateway.

Right choice when: You already run an API management estate, or you want one self-hostable control point that covers model traffic, tool calls and agent-to-agent calls together — including cost and token visibility, which is an API-gateway concern the identity-first products do not address.

What it does not do: It is a platform, with the operational weight that implies. If you have no gateway today and only need per-user tokens for a handful of SaaS providers, this is more machinery than the problem needs.

Read on 12 October 2026: Identity & Access Management (Gravitee); AI Gateway for LLM, MCP & A2A governance (Gravitee)

Keycard

Keycard is runtime authorization for agents, organised around zones: “a logical grouping of users, applications, and resources that share a common set of security controls and policies”. Actors are users and applications; resources are “web APIs, MCP servers, and databases”; providers federate external identity and access systems such as Okta, Entra, AWS, GitHub and Slack. The access loop is challenge, request, evaluate, issue — the resource demands a credential, the application asks Keycard’s STS, policy is evaluated, and a scoped token is issued. “As each challenge and response is completed, policy is evaluated against the current authorization context”, which includes identity and group membership for the person and identity and delegated authority for the agent. Applications can “register a public key with the zone, avoiding use of shared secrets”, or authenticate with a workload identity, “eliminating the need for service accounts with long-lived secrets”. OAuth 2.0 token exchange supports cross-domain access and preserves delegation chains.

Identity model

aact:identity-model/per-agent-identity
aact:identity-model/workload-identity

An application is a first-class actor in the zone, identified by a registered public key, a client credential, or the workload identity of the runtime it sits in.

Delegation model

aact:delegation-model/on-behalf-of-user
aact:delegation-model/agent-to-agent

The authorization context carries both the person and the agent’s delegated authority, and token exchange preserves the chain across domains.

Credential model

aact:credential-model/brokered-short-lived-token

Credentials are “issued or brokered only after that check” — the agent gets a scoped token for the resource, including brokered credentials for external services.

Authorization model

aact:authorization-model/per-action-policy

Policy is a decision point evaluated on each challenge, against the identity and context current at that moment.

Enforcement point

aact:enforcement-point/target-system
aact:enforcement-point/gateway

The decision is made by Keycard’s STS at issuance; the resource that issued the challenge validates the credential it gets back.

Failure behavior

not classified

A credential is only issued when the check passes, but the pages read do not state the posture for an undecidable policy.

Human oversight

aact:human-oversight/post-hoc-review

Audit log and session views, plus revocation; no per-action approval step in the concepts documentation.

Audit granularity

aact:audit-granularity/session-level

The documentation describes an audit log and sessions, with each token exchange in the delegation chain recorded; it does not promise a record of every downstream call the token is then used for.

Resource surface

aact:resource-surface/saas-api
aact:resource-surface/mcp-server
aact:resource-surface/database
aact:resource-surface/code-and-shell

Web APIs, MCP servers and databases, with setup guides for coding agents such as Claude Code and Cursor.

Right choice when: Multi-agent systems where authority is passed from one agent to the next and you need the chain to narrow at each hop rather than be re-presented whole. The zone model and public-key registration also fit teams that want no shared secrets anywhere.

What it does not do: It is infrastructure, and it expects you to model zones, actors, resources and policy before anything works. If your need is a per-user token for Gmail by Friday, that modelling is overhead.

Read on 12 October 2026: Concepts overview (Keycard documentation); Keycard (product site)

When you do not need an agent layer at all

The honest answer for a good share of deployments is that the identity platform you already run is sufficient, and adding a layer would add a dependency without changing any of the nine dimensions in a way you care about. That is the case when:

Your agents act under their own authority rather than for individuals (aact:delegation-model/autonomous), so there is no second principal to intersect or record.
Everything they touch is issued tokens by your own identity provider, so a workload identity plus conditional access covers the credential and authorization dimensions already.
The target systems already log calls against the presented identity at the granularity your auditor asks for, and enforce their own permissions (aact:enforcement-point/target-system).
You have one or two agents, run by the team that built them, and the real control is a code review rather than a runtime decision.

The dimensions where a human-identity platform genuinely stops short are narrower than the category’s marketing suggests: third-party SaaS that issues its own tokens and so sits outside your directory’s permission model; deployments where the agent’s permissions and a user’s permissions have to bound each other; and per-call records that must name both principals. If none of those three describes your deployment, the shortest path is the platform you already own.

Basis for inclusion

A product is listed if it is generally available or publicly documented as of its entry’s read date — 12 October 2026 for most entries, 29 October 2026 for the two re-read on the latest pass — if its own documentation addresses AI agents or MCP clients as a distinct case rather than as ordinary API clients, and if enough of that documentation is public to classify it on at least five of the nine dimensions without guessing. Every entry was classified from the vendor’s own current documentation or product pages, linked in the entry. Nothing here is classified from a press summary alone, and nothing from memory.

Three kinds of product are deliberately out of scope. Non-human-identity discovery and secrets-governance tools are adjacent but answer a different question — what credentials exist — rather than how a call is decided. General-purpose policy engines and authorization services are a component of several entries above rather than alternatives to them. And model gateways that route and meter LLM traffic without an identity or delegation model do not classify on these dimensions at all.

Rows marked not classified are gaps in public documentation as we read it, not judgements. Vendors ship quickly in this category; if an entry is out of date or wrong, the taxonomy is open and so is the correction — tell us and we will re-read the source and change the page.

Frequently asked questions

How do I choose between AI agent identity tools?

Decide which of the nine access-control dimensions your deployment actually constrains, then read the products against those. If the binding requirement is that a credential never reaches the agent, the credential model decides it. If it is that an action waits for a named human, the human-oversight dimension decides it, and only a few products document an out-of-band approval step. If it is that an auditor can see which person each call was made for, the audit-granularity dimension decides it. Products that look similar in marketing diverge sharply once classified, and no single product leads on all nine.

Is an enterprise identity platform enough on its own?

Often, yes. If your agents run as workloads inside one tenant, hold permissions granted directly to them rather than derived from a user, and only touch systems that your identity provider already issues tokens for, then platform-issued identities, conditional access and the target systems’ own logs cover the ground. An agent layer earns its place when agents act for individual people against third-party SaaS that issues its own tokens, when one deployment needs the agent’s permissions and the user’s permissions to constrain each other, or when the record you owe an auditor has to name both the agent and the person on every call.

What does it mean for an agent to act on behalf of a user?

In taxonomy terms it is the delegation model: whether the agent acts under its own authority, for a specific human whose permissions bound it, for an end customer’s user in a B2B2C product, or as one hop in a chain of agents. The mechanism is usually OAuth token exchange with an actor claim, so the target sees the user as the subject and the agent as the actor. It is distinct from impersonation, where the agent authenticates as the human and the target cannot tell them apart — which also means the action cannot be attributed to the agent, and revoking the agent means revoking the human.

What should an AI agent audit record contain?

The taxonomy’s strongest level is per action with principal chain: each action records the agent, the human or upstream agent it acted for, the policy decision, and the inputs that led to it. Weaker levels are per action without the chain, session level, and not distinguishable at all — where agent activity cannot be told apart from human or service traffic in the logs. Where the record is produced matters as much as its contents: a layer in the call path can record every attempt including the denied ones, while an identity provider typically records token issuance and leaves the calls to the target system.

Developer Quickstart: a governed call in ten lines Fabriq Developer: agents acting for your customers What is Agentic Fabriq?Read the taxonomy