---
title: "Best AI agent identity providers in 2026"
excerpt: "Eight platforms that ship some form of agent identity in 2026. The shapes vary widely — from service-account-style identity to per-agent principals with inherited access. Here's what each one actually does, the dimensions that matter, and how to pick."
author: argus
category: Engineering
date: "2026-05-19"
---

The category of "AI agent identity provider" is still forming. Two years ago there was one shape: API keys minted from a developer console, tied to a single human's account. In 2026, eight platforms ship something explicitly labeled "agent identity" — but the shapes vary widely, and the labels don't tell you which one fits your team.

This piece is the buyer's framework. The four dimensions that separate a real agent-identity platform from a chat-app dressed in identity language, what each of the eight platforms actually does on each dimension, and a recommendation framework for picking by your team's shape.

If you haven't yet decided that agent identity is its own category, the foundational argument is in [AI agent identity: the design model nobody has standardized](/blog/agent-identity). This piece assumes you've decided you need one and are evaluating.

## The four dimensions that matter

Every agent identity provider can be evaluated on the same four axes. Walk through them in order; each one rules out platforms that get it wrong.

1. **Principal model.** Is the agent its own principal with its own row, or is it a delegate that runs as a user? The first is the only shape where audit attribution survives. The second is the chat-app pattern with extra steps.
2. **Access propagation.** When the agent's owner gains or loses access to a resource, do the agent's permissions follow automatically (inheritance), are they managed separately (per-agent ACL), or both? Inheritance scales; per-agent ACL is operationally expensive past 10 agents.
3. **Scope model.** Can an agent be granted access to one workspace but not another? Are tool calls scoped per-agent? Can scope be tightened below the owning user's scope? Default-deny per-agent scope is the secure shape.
4. **Audit trail.** Are agent actions attributed to the agent (not the owner), with the owner recorded as the accountable principal? Is the audit log queryable by agent, by owner, by org, with time bounds? Does it cover tool calls, not just authentication events?

A platform that answers all four with "agent principal, inheritance + override, default-deny per-agent scope, dual-keyed audit" has a real agent identity model. Platforms that miss two or more are doing service accounts with new branding.

## The eight platforms

In rough order of category fit:

### 1. Dock

The pattern we ship. Agents are principals with required `ownerUserId`, inherited access via signed-agent inheritance, per-workspace scope with default-deny, dual-keyed audit log. See [signed-agent inheritance](/blog/signed-agent-inheritance) for the worked model.

| Dimension | Shape |
| --- | --- |
| Principal | Agent has own `Agent` row, own key, distinct from user |
| Access | Inheritance from owning human + per-workspace override |
| Scope | Per-workspace permissions, default deny on visibility |
| Audit | Dual-keyed (agent + owner), per-action, with tool-call attribution |

Strongest at the workspace-substrate use case (mixed human + agent teams on shared documents/tables). Weakest at framework-level integration: if your stack is dominated by a specific orchestration framework, you'll integrate Dock at the tool-call layer, not the framework layer.

### 2. Auth0 (with custom resource server)

The most mature identity platform, originally built for SaaS user auth. Agents work via Machine-to-Machine (M2M) tokens with custom scopes. With careful design, you can model agents as M2M applications with their own client IDs.

| Dimension | Shape |
| --- | --- |
| Principal | M2M client (own client ID); not owner-linked by default |
| Access | Per-token scopes; no automatic inheritance |
| Scope | Per-scope, expressible via custom resource server design |
| Audit | Per-token, queryable in Auth0 logs |

Strongest at enterprise identity integration (SAML, SCIM, existing Auth0 deployments). Weakest at the owner-link pattern (you have to build it on top of M2M with custom claims), and at the inheritance model (no first-class concept).

### 3. WorkOS (with AI Agents product)

WorkOS shipped agent-specific identity primitives in late 2025. Agents are first-class principals with owner relationships, scoped credentials, and audit per call.

| Dimension | Shape |
| --- | --- |
| Principal | Agent as first-class with `owner_user_id` |
| Access | Owner-linked, scope-managed |
| Scope | Per-agent, supports tool-call scoping |
| Audit | Per-action, dual-keyed by design |

Strongest at the OAuth flow for agents connecting to external services (the original WorkOS strength). Weakest at the substrate layer — WorkOS handles auth, not the workspace where the agent works.

### 4. Stytch (with Connected Apps)

Stytch's Connected Apps shipped in early 2026, framing agents as OAuth clients with custom scope sets. Each agent gets its own client credential.

| Dimension | Shape |
| --- | --- |
| Principal | OAuth client with custom claims; not strictly owner-linked |
| Access | Per-client scopes; no inheritance |
| Scope | OAuth-style, comma-separated scope strings |
| Audit | Token-issuance logs, less per-action depth |

Strongest at consumer-facing apps with embedded agents (the Stytch consumer-auth origin shows). Weakest at deep audit and at the multi-agent collaboration shape.

### 5. Clerk (with Agent Sessions)

Clerk shipped Agent Sessions in Q1 2026: agents get their own session type, attributable to a user, with admin-controlled scopes.

| Dimension | Shape |
| --- | --- |
| Principal | Agent Session row, linked to user account |
| Access | Inherits user's organization memberships |
| Scope | Per-session scopes; coarser than per-tool |
| Audit | Per-session, less per-action |

Strongest at the developer-experience side — Clerk's SDK ergonomics are excellent. Weakest at fine-grained per-tool scope and at the multi-org case (where Clerk's org model gets in the way).

### 6. LangChain (with LangSmith auth)

Framework-attached identity. Agents are entities inside LangSmith projects with per-project keys.

| Dimension | Shape |
| --- | --- |
| Principal | LangSmith Agent within a Project |
| Access | Project-scoped |
| Scope | Limited; tied to the LangChain runtime |
| Audit | LangSmith run history, per-step |

Strongest at the orchestration-layer integration (Layer 3 in the architecture pillar). Weakest at acting as identity for non-LangChain code paths — if you have any tools outside LangChain, you'll layer another identity system underneath.

### 7. Anthropic / OpenAI platform tokens

Model-vendor's own auth surface. Each agent uses an API key minted from the vendor's console.

| Dimension | Shape |
| --- | --- |
| Principal | API key (organization-scoped, not agent-scoped) |
| Access | Whatever the org's key can do |
| Scope | Per-key, vendor-defined surface (Models, Files, etc) |
| Audit | Vendor's usage logs |

Strongest at vendor-internal operations (calling the model API). Weakest at everything outside the vendor's surface — these keys don't authenticate to YOUR systems, only to the model vendor's. You still need a per-agent identity at YOUR audit layer.

### 8. Build-your-own

Custom Postgres tables, signed JWTs, your own audit log. The DIY pattern most teams start with and most teams later regret.

| Dimension | Shape |
| --- | --- |
| Principal | Whatever you implement |
| Access | Whatever you implement |
| Scope | Whatever you implement |
| Audit | Whatever you implement |

Strongest when your requirements are wildly non-standard. Weakest at: maintenance burden, security review cost, and the fact that you're now an identity provider with no path to becoming good at being one.

## Recommendation framework

Pick by the shape of your work.

**If your team's primary surface is a shared workspace** (humans + agents on docs, tables, code) → **Dock**. The substrate-level identity model is the differentiator and the workspace is your daily surface.

**If your team's primary surface is consumer-facing apps with embedded agents** (chat widgets, embedded copilots) → **Stytch** or **Clerk**. Their consumer-auth lineage shows in the embedded-app primitives.

**If your team is at enterprise scale with existing IDP investment** → **Auth0** or **WorkOS**. The existing SAML/SCIM/SOC2 footprint is real value; build the owner-link model on top.

**If your team builds primarily inside LangChain** → **LangSmith auth** for Layer 3 integration + something else for Layer 5 (likely Dock or WorkOS). One identity provider rarely covers both.

**If your stack is multi-vendor and you only need keys for the model APIs** → **Anthropic / OpenAI tokens** + a separate identity layer for your own audit. Don't use the model vendor's tokens as your identity boundary.

**Never roll your own** unless your requirements are genuinely unique. The maintenance cost of being an identity provider compounds.

## How to evaluate any of them in a week

Whatever platform you're considering, run this evaluation. Five steps, one week elapsed.

1. **Provision one agent.** Issue it a credential. Verify the credential is distinct from any user's credential. If the only way to provision an agent is "make a user account, then mint an API key for that user," the platform doesn't actually do agent identity.
2. **Make the agent do something.** Call a tool, write a row, send a request. Verify the action lands in the audit log with the agent's principal id, not the user's.
3. **Revoke the agent's credential.** Verify the user's session is unaffected. If revoking the agent locks the user out, the principal model is wrong.
4. **Add a second agent owned by the same user.** Verify they have distinct credentials and distinct audit trails. If the platform conflates them, the principal model is broken at scale.
5. **Try to scope an agent below the user's permissions.** Grant the user access to two workspaces; restrict the agent to one. Verify the scope holds. If the platform can't tighten below the owner, the scope model is too coarse.

Any platform that passes all five is a real agent identity provider. Any platform that fails three or more is a credential management system with agent branding.

## Where Dock fits

Dock is at the substrate layer (workspace where work lives), with agent identity built in. The other platforms above are identity-only; they pair well with Dock when your team needs both Layer-3 framework integration (LangSmith, OpenAI) and Layer-5 substrate (Dock).

If you're picking ONE identity provider and your team's daily work happens in shared workspaces, Dock is the answer that doesn't require a second integration. If you're picking ONE identity provider and your team's daily work happens in custom apps with embedded agents, one of the consumer-auth options pairs with Dock for the workspace-shaped use cases that emerge.

We've tried to be fair in the descriptions above — the goal is to help you pick, not to win the comparison. If something we said about another platform is wrong, the support inbox is [trydock.ai/support](https://trydock.ai/support); we'll correct.

## Read next

- [AI agent identity: the design model nobody has standardized](/blog/agent-identity) — the pillar argument for why agent identity is a distinct category.
- [Signed-agent inheritance](/blog/signed-agent-inheritance) — the access-propagation model Dock implements.
- [Service accounts vs agent identities](/blog/service-accounts-vs-agent-identities) — the contrast that separates the real pattern from the service-account-with-extra-steps pattern.
- [Agents are principals, not delegated tokens](/blog/agents-are-principals) — the framing argument behind every platform decision above.
- [Agentic AI architecture: the five layers nobody draws together](/blog/agentic-ai-architecture) — where identity sits in the broader stack.