| Setting | AgentID | The usual default |
|---|---|---|
| id_token signing | ES256 only | RS256, which rejects valid tokens with a signature error |
| Response type | code only |
Implicit and hybrid flows are rejected |
| PKCE | S256 only | Plain or missing challenge fails |
| Refresh tokens | None; tokens last 10 minutes | Requesting offline_access gets you nothing |
| Symptom | Cause | Fix |
|---|---|---|
| The AgentID button does nothing, or the connection is missing from sign-in | New Clerk connections start disabled | Enable the connection in Clerk |
| AgentID rejects the redirect | The redirect URI on the AgentID application doesn't match Clerk's authorized redirect URI | Copy Clerk's value into the application's settings; add one per environment |
| Owner's name and email are not on the Clerk user | Clerk keeps the standard claims; the owner claims are fetched separately | Call /v0/userinfo in your callback and store the result |
| The sign-in waits instead of finishing | Owner scopes were requested and the agent's key can't share its owner | Nothing on your side; the organization owner approves it |
| Your own sign-in button doesn't start the flow | The button calls a different strategy name | Use oauth_agentid, the strategy name of Clerk’s AgentID connection |
| Symptom | Cause | Fix |
|---|---|---|
| Only the agent's ID and email come back | The scopes field was left empty, so the issuer fell back to openid email |
Type the scopes you need, separated by commas |
| A fourth custom provider can't be added | Free Supabase projects allow three custom providers | Remove an unused custom provider; the limit is Supabase's, not AgentID's |
| Your sign-in code can't find the provider | The identifier was typed with its prefix, or the code calls a different name | The provider is custom:agentid; type only agentid in the field |
| Owner claims are missing from the user | Supabase drops custom claims that are not allowlisted | Allowlist owner_sub, owner_name and owner_email |
| The sign-in waits instead of finishing | The app asked for owner data and the agent's key can't share it | Nothing on your side; the organization owner approves the sign-in |
| The allowlist isn't available on a self-hosted instance | Supabase Auth older than 2.192.0 | Upgrade Supabase Auth |
| Question | Principal (AgentID) | Delegate (WorkOS auth.md, Auth0 Token Vault) | Workload identity (Google Cloud Agent Identity) |
|---|---|---|---|
| Who is the subject? | The agent | The user the agent works for | The workload running the agent |
| What credential does the app see? | An ES256-signed OIDC id_token | A short-lived access token tied to the user | A SPIFFE identity and X.509 certificate |
| What does revoking stop? | New sign-ins with that agent's key, at every app; nothing else | That grant; revoking the user stops everything the user does | Governed by the platform that issued the certificate |
| Who is accountable? | The owner, as a claim registered apps can request | The user, who is the account | Outside this credential; it names the workload |
Sources
| Identifier | Same at every app? | Survives recreating the inbox? | Personal data? | Use it for |
|---|---|---|---|---|
sub |
Yes | No; a recreated address gets a new one | No, opaque | The account key |
owner_sub |
Yes, shared by one owner's agents | Belongs to the owner, not to one inbox | No, opaque, and can't be matched to AgentMail ids | Per-owner limits, history and bans |
email |
Yes | The address can return, under a new sub |
Identifies the inbox and its domain | Writing to the agent |
preferred_username |
Yes, built from the address | Follows the address | As much as the address | Display |
owner_email |
Registered apps that request it | Belongs to the owner | Yes, a person's address | Reaching a human |
| Borrowed login | Its own AgentID | |
|---|---|---|
| Who the app thinks the customer is | You | The agent, with you as its owner |
| Where the app's email goes | Your inbox | The agent's own inbox |
| Whose name is on the agent's actions | Yours | The agent's own stable identifier |
| What crosses to the app at sign-in | Your password | No password and no reusable key |
| What a leaked credential reaches | Your account | Only that agent's sign-in |
| How you cut the agent off | Change your password | Delete the agent's sign-in key |
| Claim | When present | Meaning |
|---|---|---|
iss | Always | https://auth.agentid.com |
sub | Always | Opaque 43-character subject for the agent's inbox, stable across apps |
aud | Always | Your exact client ID: a URL for open clients, an issued ID for registered ones |
iat, exp | Always | Issued and expiry times, 10 minutes apart |
jti | Always | Unique ID for this token |
actor_type | Always | The literal "agent" |
nonce | When your app sent one | Echoed back for replay detection |
email | email scope | The agent's inbox, verified live when the token is minted |
email_verified | With email | Always true |
name | profile scope | The agent's display name, omitted if none is set |
preferred_username | profile scope | A handle built from the address |
owner_sub | profile scope | Opaque 43-character owner ID, shared by agents with the same owner |
scope | Registered clients | What was actually granted |
owner_name | owner_profile, registered | The owner's name |
owner_email | owner_email, registered | The owner's email address |
| Key | One person, ten agents | Available to |
|---|---|---|
| IP address | Unpredictable; shared by strangers, spread across hosts | Any request |
| Your account ID | Ten accounts, ten quotas | Any app |
sub |
Ten agents, ten quotas, each stable across apps | Every AgentID sign-in |
owner_sub |
One owner, one quota | Apps that request the profile scope, open or registered |
owner_email |
One owner, one quota, plus a way to reach them | Registered apps that request the owner_email scope |
| Situation | Action | What the app observes |
|---|---|---|
| Lost laptop holding the agent's key | Delete that key with DELETE /v0/api-keys/{'{api_key_id}'}. The sessions page can't help, because it only clears the browser you are using. |
New sign-ins with the key fail. Existing sessions last until the app ends them; /v0/userinfo shows the change within the token window. |
| Agent misbehaving | Delete each of its sign-in keys; there is no bulk endpoint. | The agent can't sign in anywhere with those keys. Sessions already open run to the app's own limit. |
| One app wants one agent gone | The app blocks the agent's sub in its own records. The owner can disable the inbox's account there with Update Account. |
Whatever its own rule says. Other apps are unaffected. |
| Inbox deleted and recreated | Nothing to revoke; the old identity is gone with the inbox. | A new sub, even at the same address. Apps keyed on sub treat it as a new agent. |
| Scheduled key rotation | Activate a replacement, then delete the old key. | Nothing. The sub is unchanged. |
| Open client | Registered client | |
|---|---|---|
| Setup | None | AgentID console or npx @agentmail/agentid-cli init, with an AgentMail account |
| Client ID | An https URL your app owns | An issued ID, with a client secret shown once |
| Redirect URIs | On the same site as the client ID | Up to 10 |
| PKCE | Required, S256 | Optional; enforced when you send a challenge |
| Scopes | openid, email, profile |
Those, plus owner_profile and owner_email |
| Owner's name and email | Never | When requested, in the id_token and from /v0/userinfo |
| Policy | A real customer's agent | A spam farm | Support load |
|---|---|---|---|
| Block all agents | Rejected, or signs up with its owner's credentials and becomes invisible | Learns to look human; only the clumsy attempts are caught | Appeals from blocked customers, and a signup table nobody trusts |
| Allow unlimited agents | Gets in | One person opens as many free accounts as they have inboxes | Abuse reviewed one account at a time |
| Cap signups per owner | Gets in, up to the owner's cap | Stops at the cap, however many inboxes it creates | One owner to review; banning the owner covers every agent they run |
| Value | Effect |
|---|---|
| Blank | Unlimited signups per owner |
| 0 | New signups paused; existing accounts keep signing in |
| 1 to 1,000,000 | That many signups per owner |
| Platform | Where it goes | Detail that trips people up | Guide |
|---|---|---|---|
| Clerk | Custom OAuth provider | Scopes you request here are the request; registration does not set them. | /docs/clerk |
| Supabase | Authentication, Sign In / Providers, Custom Providers | Identifier has a fixed custom: prefix; type only agentid. Scopes are comma-separated. Free projects allow three custom providers. | /docs/supabase |
| Auth0 | Marketplace social connection | AgentID is a listed integration; enable it rather than building an enterprise connection. | /docs/auth0 |
| Better Auth | Generic OAuth plugin via @agentmail/agentid-better-auth | Requires Better Auth 1.7.2 or newer. Provider id is fixed to agentid; your redirect URI ends in /agentid. | /docs/better-auth |
| Auth.js v4 | Generic OIDC provider | Set PKCE and nonce checks and ES256 in the provider metadata. | /docs/auth-js |
| Anything else OIDC | Generic connector or your own client | Code flow only, S256 PKCE, ES256, no refresh tokens, no end-session endpoint. | /docs/custom |
| Variant | Use it on | URL |
|---|---|---|
| Black, transparent | Light backgrounds | https://www.agentid.com/brand/icon-black.svg |
| White, transparent | Dark backgrounds | https://www.agentid.com/brand/icon-white.svg |
| Black on white tile | When you cannot control the backdrop | https://www.agentid.com/brand/icon-black-on-white.svg |
| White on black tile | Light layouts wanting a dark tile | https://www.agentid.com/brand/icon-white-on-black.svg |
| Delegate model | Principal model | |
|---|---|---|
| Who holds the account | The human user | The agent |
| Where the human appears | As the subject of the token | As a claim (owner_email) the app can request |
| What the token proves | A user granted authority to some client | Which agent this is, and optionally whose |
| Can the agent sign up for a new service on its own | Only by getting the user to authenticate first | Yes, from an enrolled browser, with no user present |
| Where receipts and support replies go | The user's inbox | The agent's own inbox |
| Revoking the agent | Revoke the grant; the user's account is unaffected | Revoke the agent's credential; the owner's accounts are unaffected |
| Examples | WorkOS auth.md, Auth0 for AI Agents (Token Vault), Arcade | AgentID; Microsoft Entra Agent ID and Auth0 Agent as Principal, inside a tenant |
Sources
| Policy | Keyed on account | Keyed on owner_email |
|---|---|---|
| Free-tier quota | One free tier per agent; ten agents get ten free tiers | One free tier per human, shared across their agents |
| Account cap | Unenforceable | N agents per owner, your choice of N |
| Abuse response | Ban one account; the next agent signs up | Ban the owner; every agent they run is covered |
| Billing | Card per agent, or none | Roll agents up to one billing contact |
| Who you email when it breaks | The agent's inbox | The agent's inbox for operations, the owner for accountability |
Sources
| User account | Service account | Agentic account (AgentID) | |
|---|---|---|---|
| Represents | A person | Software inside your perimeter | An agent arriving from outside, as a customer |
| Identifier | Email or username | Client ID, SPIFFE ID, or object ID | OIDC sub plus a verified email address |
| Credential | Password, passkey, OTP | Client secret, certificate, or workload token | Non-extractable browser key; fresh signature per sign-in |
| Inbox | Yes, the person's | No | Yes, the agent's own |
| Trusted where | Anywhere the person can authenticate | Only where an administrator configured it | Any app that accepts the OIDC provider |
| Human accountability | The account holder is the human | Known internally; invisible to third parties | owner_email claim, delivered to the app on request |
| Revocation scope | The person loses access everywhere that session reaches | Rotate the secret; every consumer of it breaks | One agent's credential; owner and other agents untouched |
| Human required at sign-in | Yes | No | No, if the agent has an enrolled browser; owner hand-off otherwise |
Sources
| Signup step | Agent borrowing its owner's account | Agent with its own AgentID |
|---|---|---|
| Email address on the form | The owner's | The agent's own AgentMail inbox |
| Verification code | Sent to the owner; agent waits or reads the owner's mail | None needed; email verified live at token mint |
| Credential stored by the app | A password the agent and owner both know | Nothing reusable; the app verifies a signature against published keys |
| Who the app thinks the customer is | The owner | The agent, with the owner available as a claim |
| Where receipts and support replies go | The owner's inbox | The agent's inbox |
| Revoking the agent | Change the owner's password, breaking everything else | Revoke one enrolled credential; nothing else is touched |
Sources
| Claim | What it is | Where it arrives |
|---|---|---|
| sub | Stable subject derived from the agent's inbox. Same agent, same sub, every sign-in. | id_token |
| email, email_verified | The agent's own inbox address, verified live when the token is minted. email_verified is always true when present. | id_token (email scope) |
| name | The agent's display name. | id_token (profile scope, registered clients) |
| scope | What this sign-in granted, so you can check rather than assume. | id_token (registered clients) |
| owner_email, owner_name | The human who owns the organization behind the agent. | id_token and /userinfo (owner scopes, registered clients) |
| iss, aud, exp, iat, jti, nonce | Standard OIDC claims. jti names this one sign-in. | id_token |
&redirect_uri=https://yourapp.com/callback
&client_id=https://yourapp.com
&code_verifier=
```
Verify the id_token against `https://auth.agentid.com/v0/jwks.json` with whichever JOSE library you already use. Check `iss` and `aud` as you would for any provider.
Keys rotate with stable key ids and an overlap window, so caching by `kid` is safe.
## How do you find out which human owns the agent?
To find out which human owns the agent, create an AgentID application, request the `owner_email` scope, and read it from the id_token or `/v0/userinfo`.
Click **Create application** in the [AgentID console](https://console.agentid.com), or run `npx @agentmail/agentid-cli init`. That gives you:
- **A client_secret,** shown once (you can regenerate it).
- **Up to 10 redirect URIs.**
- **Access to the owner scopes:** `owner_profile` and `owner_email`, which open clients cannot request.
Then request `owner_email` at `/v0/authorize` and exchange the code as above. The id_token carries `owner_email`, and `/userinfo` returns the same value:
```
GET https://auth.agentid.com/v0/userinfo
Authorization: Bearer
```
The response includes `owner_email` and, with `owner_profile`, `owner_name`.
The owner's email is personal data, so don't log tokens that carry it.
If the agent is not allowed to share its owner, it can't finish the sign-in alone; the organization owner has to approve it. You never get a token with the claim missing, so you can rely on the field whenever a sign-in succeeds.
The mechanics and the policy questions around this are in [how to verify the human behind an AI agent](https://www.agentid.com/blog/how-to-verify-the-human-behind-an-ai-agent).
## What makes an AI agent login secure?
An AI agent login with AgentID is safer than the status quo, where agents sign in as people, because nothing reusable crosses the sign-in.
- **The agent's private key** stays in its browser.
- **AgentID's own signing key** is non-exportable.
- **Every sign-in** is a fresh signature that your app verifies against published keys.
Your app never receives a password or an API key. Revoking a credential stops that one agent; it touches nothing belonging to the owner and nothing belonging to other agents.
What the token does not tell you is whether the agent will behave. It proves which agent this is, not that it is well-intentioned.
The accountability comes from the owner claim. An agent whose human you can name is an agent you can allow, limit, or ban with a real address to write to.
Most of the relying-party decisions that follow, such as [how many agents one owner may run](/blog/stop-fake-agent-signups-without-blocking-real-agents) or whether to gate certain features to agents with a verified owner, are covered in [can an AI agent sign up for a SaaS](https://www.agentid.com/blog/can-an-ai-agent-sign-up-for-a-saas).
## What should your app do after an agent's first sign-in?
After an agent's first sign-in, key its record on `sub`, store the owner if you requested it, and send your normal onboarding email.
1. **Key records on `sub`, not on `email`.** The address is stable too, but `sub` is the identifier the protocol guarantees.
2. **Store `owner_email` alongside it** if you requested it, and index on it so per-owner limits are one query.
3. **Send your normal onboarding email** to the agent's address, because the agent will read it.
4. **Add your app to the [AgentID directory](https://www.agentid.com/directory)** so agents browsing for services that accept them can find yours.
The [button guide](https://www.agentid.com/blog/adding-a-sign-in-with-agentid-button) covers the markup and the brand rules for the login page itself.
Sources
- **The identity provider delivers the owner.** The agent cannot type its owner's email into a box; the value comes from the party that issued the agent's identity.
- **Create, request, read.** Create an AgentID application, request `owner_email` at `/authorize`, and read it from the id_token or `/userinfo`. Open clients cannot.
- **No owner, no silent success.** If the agent is not allowed to share its owner, it can't finish the sign-in alone; the organization owner has to approve it.
- **KYA is becoming a payments standard.** Visa, Mastercard, and Ant International agreed on a Know Your Agent interoperability framework on September 10, 2026. Sign-in is where a SaaS product applies the same idea.
To verify the human behind an AI agent, you need the agent's identity provider to attest to the owner, not the agent to assert it.
With [AgentID, the sign-in for AI agents from AgentMail](/blog/introducing-agentid), the mechanism is three steps:
1. **Create** an AgentID application for your app.
2. **Request** the `owner_email` scope when the agent signs in.
3. **Read** `owner_email` and `owner_name` from the id_token, or from `/v0/userinfo` with the access token. Both return the same values.
The values come from the agent's AgentMail organization, which has exactly one designated owner.
If the agent is not allowed to share its owner, it can't finish the sign-in alone: the organization owner has to approve it from their AgentMail account. You never get a token with the claim quietly missing.
This is Know Your Agent applied at sign-in. Your app gets a verified agent and a verified human in the same OpenID Connect flow it already uses for Sign in with Google.
## What does Know Your Agent (KYA) mean, and why is agentic commerce adopting it?
Know Your Agent, or KYA, is the practice of verifying which AI agent is making a request and which human or organization is accountable for it, before letting the agent transact.
The term is borrowed from Know Your Customer in financial services. The payments provider Eco defines it as "an emerging identity framework that cryptographically binds an AI agent's requests to a registered operator and an authorized user, so that a merchant can verify both before settling a payment."
The card networks have adopted the language. On September 10, 2026, Visa, Mastercard, and Ant International announced a Know Your Agent interoperability framework spanning three protocols:
- **Visa:** Trusted Agent Protocol
- **Mastercard:** Verifiable Intent
- **Ant International:** Agentic Mobile Protocol
Mastercard's chief digital officer, Pablo Fourez, said "interoperability across Know-Your-Agent frameworks is essential to making agentic commerce work at scale."
Visa's Rubail Birwadker said that "without trusted identity and explicit permissioning, AI agents cannot participate in commerce at scale." At the time of the announcement, no technical specification for the shared framework had been published.
The payments version of KYA is about settlement. The SaaS version is about signup and account behavior, and it needs the same two facts: which agent, and whose.
This post is about how a web application gets those facts at sign-in.
## Why can't you just ask the agent who owns it?
You cannot just ask an AI agent who owns it, because a self-asserted owner is worth nothing.
An agent filling in "owner email" on a form can type anything. An agent using its owner's own credentials is already claiming to be the owner.
Verification has to come from a party the agent cannot forge: the system that issued the agent's identity and knows who created it. That rules out most of what currently passes for agent verification.
- **Bot detection** tells you a request is probably automated, not who is behind it.
- **An API key** tells you which developer account is calling your API, which is useful for your API and useless at your login page.
- **An OAuth access token** from a delegate-model product tells you a user granted permission to something, but the agent itself is an unnamed bearer.
None of them produce a verifiable statement of the form "this agent is owned by this person." The vocabulary for the distinction is in [agent owner verification vs end-user authentication](https://www.agentid.com/blog/agent-owner-verification-vs-end-user-authentication).
## How does AgentID verify the agent and its owner?
AgentID verifies the agent by checking its inbox live at token mint, and verifies the owner from the AgentMail organization's designated owner on file.
Every AgentID is an AgentMail inbox. Every inbox belongs to an AgentMail organization that holds the API key that created it. The organization has a designated owner: a human with a name and an email address.
When an agent signs in through AgentID, the provider knows the agent and knows the organization's owner. Owner verification is the provider disclosing the second fact to your app, with the agent's consent shown on the disclosure screen at sign-in.
Two conditions must hold for the agent to share its owner on its own:
- The agent's AgentMail API key must have the `App: Share Owner` permission.
- The organization must have exactly one designated owner holding the value.
When both are true and your app requests it, you get it. When the permission is missing, the agent's own approval is refused and the organization owner has to approve the sign-in instead.
An app that looks misconfigured is often waiting on that permission. The behavior is deliberate: an app that asks for the owner never has to handle a successful sign-in with the owner missing.
## How does a relying party verify an AI agent's identity and owner, step by step?
A relying party verifies an AI agent's identity and owner in three steps, none of which require an SDK.
**Step 1: create an AgentID application.** Open clients (a URL as `client_id`, no setup) can request `openid`, `email` and `profile`, but not the owner scopes.
Click **Create application** in the [AgentID console](https://console.agentid.com), or run this from your project:
```
npx @agentmail/agentid-cli init --owner-email
```
You get a Client ID and a client secret.
**Step 2: request the owner scopes at sign-in.** Registration-time scope metadata is ignored; what you receive is what you send to `/authorize`.
In Clerk, Supabase, Auth0, Descope, Better Auth, or Auth.js this is the Scopes field on the provider configuration. On the wire:
```
scope=openid%20email%20profile%20owner_email%20owner_profile
```
**Step 3: read the owner.** The id_token from the code exchange carries `owner_name` and `owner_email`. You can also call `/userinfo` with the access token, which returns the same values:
```
GET https://auth.agentid.com/v0/userinfo
Authorization: Bearer
{
"sub": "a91f2c8e...43",
"email": "support@acme.agentmail.to",
"email_verified": true,
"name": "Acme Support",
"owner_name": "Maya Chen",
"owner_email": "maya@acme.com"
}
```
Store `owner_email` on the agent's account record and index it.
Many auth libraries keep only the standard claims when they build the session user, so the owner fields may not appear there. In Supabase, allow them with the claims allowlist; in Better Auth, read them from `/userinfo`. Each provider guide shows how.
## Where does owner_email arrive?
In two places, with the same value: the id_token your app receives from the code exchange, and `/userinfo`.
The owner's email is personal data about someone who is not the subject of the token. id_tokens sit in browser storage and end up in logs, session cookies and debugging output, so treat a token that carries owner claims as sensitive, and don't log it.
`/userinfo` re-checks the live inbox on every call, so it is the place to look when you need a fresh answer later.
## What can you do once you know the owner?
Once you know an AI agent's owner, you can do four things that were impossible when agents signed up as their owners.
Capability
Without owner verification
With owner_email
Per-human limits
One free tier per agent account
Quotas and caps keyed on the owner across all their agents
Abuse response
Ban an account; the next agent registers
Ban the owner and every agent they run
Escalation
Email the agent and hope
Email the agent for operations, the human for accountability
Gated features
Same access for every agent
Payments, deletes, or spend only for agents with a disclosed owner
An app that can name the human behind an agent can let that agent act on its own, because there is someone to call. That is what makes autonomy safe to allow.
The product-level version of this argument is in [can an AI agent sign up for a SaaS](https://www.agentid.com/blog/can-an-ai-agent-sign-up-for-a-saas).
## Does owner verification tell you the agent is trustworthy?
No, and it does not claim to. An AgentID token proves which agent this is and, for registered clients, which human is accountable for it.
It does not assert that the agent is safe or well-behaved, and it carries no trust score or endorsement.
The owner claim is a verified contact for a real person or organization. That is the same thing you know about a human customer after they confirm their email.
Your abuse controls still run; they just have a better key.
## What about verifying the owner's identity beyond an email?
Email is the layer AgentID delivers today. For products that need more, the owner email is the join key to whatever verification you already run.
A financial service, for example, may need to know the legal identity of whoever is behind an agent before letting it move money.
You verify the human once, through your existing KYC provider, and every agent that signs in with that `owner_email` inherits the result.
One capability that could sit on top of AgentID is KYC pass-through, where verification completed on the AgentMail side is exposed to relying parties. It is not shipped, and this post makes no claim about when it will be.
For the full protocol behind the three steps, including discovery values, client tiers, and token verification, see [OIDC for AI agents: the complete guide](https://www.agentid.com/blog/oidc-for-ai-agents-complete-guide).
Sources
- **OIDC gives you identity; OAuth gives you permission.** Agents need both, and the delegation products compared below only do the second. An OIDC provider for agents issues an id_token that says which agent this is.
- **The agent is the principal.** In AgentID the agent has its own account, inbox, and credential. The human owner is a claim you can request, not the account you are logging in.
- **Everything is standard.** Authorization code, PKCE S256, ES256 signatures, discovery, JWKS, RFC 7591 dynamic registration. Any OIDC library or auth platform works.
- **Owner claims go to registered apps.** `owner_email` and `owner_name` arrive in a registered app's id_token and from /userinfo, and only when the app asks for them.
OpenID Connect for AI agents means using the same identity protocol your login already speaks, with the agent as the subject instead of a person.
The agent holds a signing key. An OIDC provider built for agents issues an id_token that names the agent: a stable `sub` and its verified email. Your application verifies that token against published keys the way it verifies a Google sign-in.
OAuth alone cannot do this. OAuth answers what a client may do on a user's behalf, not who the client is.
AgentID, the sign-in for AI agents from AgentMail, is an OIDC provider that does it for the open web:
- **Flow:** authorization code with PKCE.
- **Tokens:** ES256 signatures.
- **Discovery:** `https://auth.agentid.com/.well-known/openid-configuration`.
- **Registration:** RFC 7591, for clients that need the owner's identity.
- **Enrollment:** a one-time browser enrollment on the agent's side, so no human has to be present at sign-in.
This guide covers the whole protocol for developers on the relying-party side, with the exact values the live issuer publishes.
**On this page**
- [Why is OAuth alone not enough to verify an AI agent?](#why-is-oauth-alone-not-enough-to-verify-an-ai-agent)
- [What does the discovery document say?](#what-does-the-discovery-document-say)
- [How does the OIDC sign-in flow work for AI agents, step by step?](#how-does-the-oidc-sign-in-flow-work-for-ai-agents-step-by-step)
- [What are the two client tiers?](#what-are-the-two-client-tiers)
- [Which scopes and claims exist?](#which-scopes-and-claims-exist)
- [Where does owner_email actually live?](#where-does-owner_email-actually-live)
- [How does the agent hold its credential?](#how-does-the-agent-hold-its-credential)
- [How do you verify and manage OAuth tokens for AI agents?](#how-do-you-verify-and-manage-oauth-tokens-for-ai-agents)
- [How is this different from Auth0 for AI Agents or Descope Agentic Identity Hub?](#how-is-this-different-from-auth0-for-ai-agents-or-descope-agentic-identity-hub)
- [What is the OAuth threat model for AI agents?](#what-is-the-oauth-threat-model-for-ai-agents)
## Why is OAuth alone not enough to verify an AI agent?
OAuth 2.0 is an authorization framework, so on its own it cannot verify an AI agent. Its output is an access token that lets a client call a resource on behalf of a resource owner, scoped to what that owner granted.
The token says nothing reliable about who the client is. `client_id` is self-asserted for public clients, and there is no standard claim for "this is the agent, and this is the human behind it."
Every agent auth product built on OAuth alone inherits this. It can tell you a user delegated authority to something. It cannot tell you which something, or vouch for it to a party who has never met it.
OpenID Connect adds the identity layer. An OIDC provider authenticates a subject and issues an id_token: a signed JWT with `iss`, `sub`, `aud`, `exp`, `iat`, and whatever profile claims were granted.
The relying party verifies the signature against the provider's JWKS and trusts the claims because it trusts the issuer. Sign in with Google is OIDC. So is Sign in with AgentID; the only difference is what kind of entity the subject is.
For agents, that difference matters:
- **A delegate-model product** issues tokens about a human, with the agent as an unnamed bearer.
- **An agent-as-principal provider** issues tokens about the agent, with the human as an optional claim.
The second is the one that lets a third-party app say "this is agent X, owned by person Y, and I have seen X before."
The vocabulary for this split is covered in [agent owner verification vs end-user authentication](https://www.agentid.com/blog/agent-owner-verification-vs-end-user-authentication).
## What does the discovery document say?
AgentID publishes its OIDC discovery document at the standard path. Every value below is taken from the live document as of September 14, 2026.
Field
Value
What it means for you
issuer
https://auth.agentid.com
Paste this into any "issuer" or "well-known" field; the client derives the rest.
authorization_endpoint
/v0/authorize
Where you redirect the agent.
token_endpoint
/v0/token
Where your callback exchanges the code.
userinfo_endpoint
/v0/userinfo
The only place owner claims are served.
jwks_uri
/v0/jwks.json
Public keys for verifying id_tokens.
registration_endpoint
/v0/register
RFC 7591 dynamic registration, for the registered tier.
grant_types_supported
authorization_code
No refresh tokens, no client credentials, no implicit flow.
response_types_supported
code
Code flow only.
code_challenge_methods_supported
S256
PKCE with SHA-256. The plain method is not accepted.
id_token_signing_alg_values_supported
ES256
ECDSA P-256. A client that insists on RS256 will fail.
token_endpoint_auth_methods_supported
client_secret_basic, client_secret_post, none
Open clients use none; registered clients use a secret.
scopes_supported
openid, email, profile, owner_profile, owner_email
No offline_access, because there are no refresh tokens.
authorization_response_iss_parameter_supported
true
The callback carries iss (RFC 9207), so mix-up attacks are detectable.
Two absences are deliberate and will surprise a generic connector: there is no `end_session_endpoint`, and `offline_access` is not offered.
Sessions are your application's. AgentID authenticates the agent and gets out of the way.
## How does the OIDC sign-in flow work for AI agents, step by step?
The relying-party side of an AgentID sign-in is the textbook authorization code flow with PKCE, in five steps.
**Step 1: redirect the agent.** Your app generates a PKCE verifier and challenge, plus `state`, and redirects the agent:
```
GET https://auth.agentid.com/v0/authorize
?response_type=code
&client_id=https://yourapp.com
&redirect_uri=https://yourapp.com/callback
&scope=openid%20email
&state=
&code_challenge=
&code_challenge_method=S256
```
**Step 2: the agent's browser signs in.** The agent's enrolled browser completes the sign-in. A browser that already holds an AgentID session continues on its own; otherwise the page shows the agent one command that creates one.
A disclosure screen shows the requesting app and what it will receive. There is no password form because there is no password.
**Step 3: AgentID redirects back.** AgentID redirects to your `redirect_uri` with `code`, `state`, and `iss`.
**Step 4: exchange the code.** Your callback exchanges the code:
```
POST https://auth.agentid.com/v0/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=
&redirect_uri=https://yourapp.com/callback
&client_id=https://yourapp.com
&code_verifier=
```
The response carries an `id_token` and an `access_token`. Codes are single-use, expire in seconds, and replay is rejected.
**Step 5: verify and look up the account.** Verify the id_token (see below), create or look up the agent account by `sub`, and, if you asked for an owner scope, read `owner_email` from the id_token (or from `/v0/userinfo` with the access token).
Nothing here is AgentID-specific in shape. A library that implements OIDC Core 1.0 and RFC 7636 handles it unchanged.
The per-platform dashboards do it for you:
- [Clerk](https://www.agentid.com/docs/clerk)
- [Supabase](https://www.agentid.com/docs/supabase)
- [Auth0](https://www.agentid.com/docs/auth0)
- [Better Auth](https://www.agentid.com/docs/better-auth)
- [Auth.js](https://www.agentid.com/docs/auth-js)
- Or run `npx @agentmail/agentid-cli init` to detect and configure whichever one you use.
## What are the two client tiers?
AgentID has two client tiers: an open tier that requires no registration, and a registered tier for clients that need more.
An open client works like this:
- **It identifies by origin.** Its `client_id` is an https URL the client controls, such as `https://yourapp.com`, and its redirect URI sits on that same origin.
- **It has no secret.** PKCE is mandatory, and the origin is the whole trust anchor.
- **It gets three scopes.** Open clients may request `openid`, `email` and `profile`.
- **It cannot run on localhost.** Because the anchor is an https origin, an open client cannot run on `http://localhost`; local development starts at registration.
A registered client is an application you create in the [AgentID console](https://console.agentid.com) (**Create application**) or with `npx @agentmail/agentid-cli init`. Both call `/v0/register` for you.
You get an opaque `client_id` and a `client_secret` that is shown once (you can regenerate it later). Registered clients get:
- Up to 10 redirect URIs.
- Loopback and http redirects for development.
- Confidential token exchange.
- Per-client sign-in history.
- Access to the `owner_profile` and `owner_email` scopes.
Registration-time scope metadata is ignored: the scopes you actually receive are the ones you send to `/authorize`.
Registered clients may use either S256 PKCE or an OIDC nonce; open clients must use PKCE.
Creating an application requires an AgentMail account on purpose. Every registered client is an AgentMail account, which is how a free product pays for itself.
## Which scopes and claims exist?
AgentID offers five scopes: `openid`, `email`, `profile`, `owner_profile`, and `owner_email`. Scopes are space-delimited at `/authorize`, and a request with no scope falls back to `openid email`.
Scope
Claims it unlocks
Delivered in
Tier
openid
sub (plus iss, aud, exp, iat, jti, nonce)
id_token
Open and registered
email
email, email_verified
id_token and /userinfo
Open and registered
profile
name (the agent's display name), preferred_username, owner_sub
id_token and /userinfo
Open and registered
owner_profile
owner_name
id_token and /userinfo
Registered
owner_email
owner_email
id_token and /userinfo
Registered
Registered clients also receive a `scope` claim in the id_token listing what was granted.
Scope-gated claims are omitted rather than nulled when not granted, so test for presence. A decoded id_token for a registered client looks like this:
```json
{
"iss": "https://auth.agentid.com",
"aud": "b7d41e0a-2c65-4f8b-9d31-0a5e7c2f4b18",
"sub": "a91f2c8e...43",
"scope": "openid email profile owner_email",
"email": "support@acme.agentmail.to",
"email_verified": true,
"name": "Acme Support",
"owner_email": "maya@acme.com",
"iat": 1767225000,
"exp": 1767225600,
"jti": "9f1c2a44-3e77-4c19-9a2e-6b0d5f8e1c33"
}
```
## Where does owner_email actually live?
In two places with the same value: a registered app's id_token, and `/v0/userinfo`.
When `/token` runs, AgentID writes the owner snapshot to the grant record and puts the granted owner claims in the id_token. `/userinfo` returns the same claims for a Bearer access token and re-verifies the live inbox on every call.
```
GET https://auth.agentid.com/v0/userinfo
Authorization: Bearer
{
"sub": "a91f2c8e...43",
"email": "support@acme.agentmail.to",
"email_verified": true,
"name": "Acme Support",
"owner_name": "Maya Chen",
"owner_email": "maya@acme.com"
}
```
Handle a token that carries owner claims with care. id_tokens end up in browser storage, request logs, and session cookies, and the owner's address is personal data about someone who is not the subject of the token. Don't log it.
Owner disclosure is also enforced:
- **The agent must be allowed to share it.** The agent's AgentMail API key needs the `App: Share Owner` permission.
- **The organization needs one owner.** The organization behind the agent must have exactly one designated owner.
- **A refused disclosure needs the owner.** When an app requests `owner_email` and the agent lacks that permission, the agent's own approval is refused (403) and the organization owner has to approve the sign-in from AgentMail. AgentID never returns a token silently missing the claim.
An app registered for `owner_email` can therefore rely on it being present whenever a sign-in succeeds.
Auth platforms often keep only standard claims on the session user. On Supabase, allow the owner claims with the claims allowlist; on Clerk or Better Auth, fetch them from `/userinfo` in your callback and store them yourself.
The policy side of using them is in [how to verify the human behind an AI agent](https://www.agentid.com/blog/how-to-verify-the-human-behind-an-ai-agent).
## How does the agent hold its credential?
The agent holds its credential as a non-extractable private key inside a browser it enrolls once.
1. The agent posts an AgentMail API key to the enrollment endpoint.
2. JavaScript on auth.agentid.com generates a P-256 keypair inside the browser.
3. The browser submits the public key to AgentID.
The private key is a non-extractable WebCrypto key stored in IndexedDB under the auth.agentid.com origin. AgentMail's own wording: "Your private key is generated and stored in your browser and cannot be exported through browser JavaScript APIs."
From then on, each sign-in is a fresh signature over a server-generated transaction.
Nothing reusable crosses the wire. The API key was used once at enrollment and is not part of any sign-in, and the app never sees the key or a bearer credential it could replay.
Headless browsers work. An agent that has no browser at all does not lose the ability to sign in; its owner completes the sign-in in the AgentMail console, in the same browser the flow started in.
Revocation is per credential. Revoke an enrolled browser and that agent stops signing in from it; other agents, and the owner's own accounts, are untouched.
The step-by-step account creation from the agent's point of view is in [how an AI agent creates its own account](https://www.agentid.com/blog/how-an-ai-agent-creates-its-own-account).
## How do you verify and manage OAuth tokens for AI agents?
Verify an AgentID id_token the same way you verify any OIDC id_token: check its ES256 signature against the published JWKS, then check the claims.
1. Fetch the JWKS from `https://auth.agentid.com/v0/jwks.json`.
2. Select the key by `kid`.
3. Verify the ES256 signature.
4. Check that `iss` equals `https://auth.agentid.com`.
5. Check that `aud` equals your exact `client_id`.
6. Check that `exp` is in the future.
7. If you sent a `nonce`, check that it is echoed back.
On the issuer side, AgentID:
- **Holds signing keys in AWS KMS**, where they cannot be exported.
- **Rotates keys** with stable key ids and an overlap window.
- **Keeps the id_token lifetime short.** The documented sample is 600 seconds.
Because keys rotate with overlap, caching the JWKS by `kid` is safe.
Because there is no refresh token, there is nothing long-lived to protect on your side after the exchange; your own session mechanism takes over.
Token handling for AI agents therefore comes down to three habits:
- Verify every id_token against the live JWKS.
- Drop the access token after the `/userinfo` call that needs it.
- Key records on `sub` rather than on anything in the token that could change.
## How is this different from Auth0 for AI Agents or Descope Agentic Identity Hub?
Auth0 for AI Agents and Descope Agentic Identity Hub also run on OAuth 2.1 and OIDC, so the protocol overlap is real. The difference is what the subject of the token is.
**Auth0 for AI Agents.** In Auth0's model the agent obtains tokens to act for a user in your tenant, with credentials for third-party APIs kept in Token Vault.
In Auth0's words: "Your agent never actually holds the root key; instead, it asks Token Vault for a temporary, short-lived access token only when it needs to perform a specific task."
**Descope Agentic Identity Hub.** Descope's Inbound Apps turn your application into an OAuth authorization server, so agents and MCP clients can obtain scoped tokens for your API. Its audit trail "connects every action back to the originating user."
Both are authorization servers you run for your own users' agents.
AgentID is an identity provider that vouches for the agent to you. The agent is the subject of the token; your app is the audience; the human is a claim.
The three compose rather than compete. An app running Auth0 can add AgentID as a social connection so agents from outside its tenant can sign in.
The [AgentID vs Auth0 for AI Agents](https://www.agentid.com/blog/agentid-vs-auth0-for-ai-agents) and [AgentID vs Descope](https://www.agentid.com/blog/agentid-vs-descope-agentic-identity) comparisons go through the specifics.
## What is the OAuth threat model for AI agents?
AgentID's design rules out four OAuth threats for AI agents, and leaves one question to your own policy.
- **Credential theft in transit.** No long-lived secret crosses the sign-in, so there is nothing to steal in transit; the agent's key never leaves its browser and the app receives a short-lived, audience-bound id_token.
- **Code interception.** Mandatory S256 PKCE for public clients, single-use codes that expire in seconds, and the `iss` parameter on the callback close it off.
- **Token substitution.** The `aud` check, and for registered clients the opaque `client_id`, stop it.
- **Owner-data leakage.** Owner claims go only to registered apps that ask for them, and only with the agent's permission or the owner's approval.
What the token does not assert is that the agent is safe or well-behaved, or that it has any trust score. It proves which agent this is and, for registered clients, which human is accountable.
Everything after that is your policy:
- [Rate limits per owner](/blog/rate-limit-ai-agents-per-human-not-per-account).
- Feature gates for open-client sign-ins that carried no owner scope.
- The ordinary abuse controls you already run.
How to think about those decisions is the subject of [can an AI agent sign up for a SaaS](https://www.agentid.com/blog/can-an-ai-agent-sign-up-for-a-saas).
Sources
Microsoft Entra Agent ID governs agents inside your Entra tenant: blueprints, sponsors, Conditional Access. AgentID is an OpenID Connect provider that lets an agent sign in at apps outside any single organization, and tells those apps which human owns it.
Microsoft Entra Agent ID and AgentID solve different problems that happen to share a name. Entra Agent ID governs agents inside an enterprise: who sponsors them, what they can reach, when they get disabled. AgentID lets an agent sign in at applications outside any single organization, and delivers the owner's email to the app receiving the sign-in. Both carry human accountability; they differ on who gets to see it.
## What is Microsoft Entra Agent ID?
Microsoft Entra Agent ID reached general availability, bringing what Microsoft describes as "first-class identity and access management to AI agents" and extending Zero Trust principles to AI workloads. Its identity model is a three-tier hierarchy: an agent identity blueprint, a blueprint principal, and the agent identity itself. Governance runs through Conditional Access policies written for agents, including templates that block high-risk agent identities and separate policies for autonomous agents versus agents acting on behalf of a user. Registry experiences are converging under Microsoft Agent 365, and the platform ships an Auth SDK "sidecar" for token acquisition.
It is not a Microsoft-only story. Entra Agent ID supports non-Microsoft agents through sidecar and federation patterns, with documented guides for AWS Bedrock, GCP, and n8n.
Accountability is built into the model through three administrative relationships: Owners, who are technical administrators; Sponsors, who are "business representatives accountable for the agent's purpose and lifecycle decisions"; and Managers, who reflect organizational hierarchy. Sponsorship is not optional. Microsoft states that "at least one sponsor is required for each agent identity and agent identity blueprint," and when a user creates an agent, "the calling user automatically becomes the sponsor if no sponsors are explicitly specified." An agent can also be given an "agent's user account," an Entra user object that lets it "access user-oriented services."
The boundary is the tenant. Microsoft is explicit: "Agent identities can only be issued tokens in the Microsoft Entra tenant where they're created. They can't access resources or APIs in other tenants."
## What is AgentID?
AgentID is a ["Sign in with AgentID" button](/blog/adding-a-sign-in-with-agentid-button) run by AgentMail as a standard OpenID Connect provider. The agent authenticates as itself with a signing credential that never leaves it, and the app verifies a fresh one-time signature against published keys, receiving an ES256-signed id_token with a stable subject and the agent's live-verified inbox address.
Two tiers. Open clients integrate with no registration, using the openid, email and profile scopes. Registered clients, created in the AgentID console or with the CLI, add the owner_profile and owner_email scopes. The owner email arrives in the id_token and from the userinfo endpoint. If the agent isn't allowed to share its owner, the organization owner has to approve the sign-in, so the app never gets a token without the claim. Free for apps to add.
## The distinction that matters: who sees the human
Both systems record a human. Entra requires a Sponsor. AgentID passes owner_email. The difference is who receives that information.
Entra's sponsor is visible to the tenant that runs the agent. It is governance data for the organization operating the agent, answering "who inside our company is accountable for this thing." AgentID's owner_email is delivered to the relying party the agent signs into. It is accountability data for a third party, answering "who outside our company answers for the agent that just showed up at our login page."
The practical consequence is a single sentence. A SaaS application receiving a sign-in from an Entra agent does not learn who sponsors it. A SaaS application receiving a sign-in from AgentID does learn who owns it. One is intra-organizational governance. The other is cross-organizational accountability.
## Side-by-side
AgentID
Microsoft Entra Agent ID
For
Any app accepting sign-ins from agents it has no prior relationship with
Enterprises governing agents inside their Entra tenant
Identity model
An email address on AgentMail, routable anywhere
Blueprint, blueprint principal, agent identity, inside a tenant
Cross-app sign-in
Any app with an OIDC client; two config values
Within Entra-federated resources; external SaaS requires the app to integrate with Entra
Human accountability
owner_email claim delivered to the relying party in the id_token and /userinfo
Required Sponsor, plus Owners and Managers, visible inside the tenant
Standards
Standard OpenID Connect, ES256, PKCE S256, RFC 7591
OAuth 2.0, MCP, A2A; proprietary blueprint and sidecar model
Non-Microsoft agents
Any agent with an AgentMail inbox
Supported via sidecar or federation
Pricing
Free for apps; AgentMail inboxes from $20/mo
Entra licensing; governance features noted by third parties as requiring P2 or add-ons
Time to integrate for an app
Add as custom OIDC provider in Clerk, Supabase, Auth0, Descope, Better Auth
App must federate with Entra or validate Entra tokens
On the pricing row: third-party analysis notes that governance features requiring Entra ID P2 licensing or Governance add-ons carry cost implications. That is an outside reading rather than a Microsoft statement.
## When to choose Microsoft Entra Agent ID
Choose Entra Agent ID if your organization already runs Entra and the agents you care about are internal, reaching Microsoft 365, Azure, or your own APIs. The blueprint hierarchy gives you consistent policy across a class of agents rather than per-agent configuration, Conditional Access templates let you block high-risk agent identities without writing new machinery, and the required Sponsor means no agent exists in your directory without a named human attached to it.
If your agents live inside your tenant and never sign up for third-party SaaS, Entra is the right tool and AgentID adds nothing. That is worth saying plainly, because the two products are frequently compared as substitutes when most organizations evaluating them have only the internal problem.
## When to choose AgentID
Choose AgentID when the agent needs an account somewhere your organization does not control. An agent signing up for Turso, Neon, or any consumer or SaaS product is arriving at a login page belonging to a company that has no Entra relationship with you, and will not build one for a single prospective user. What that app needs is a standard OIDC sign-in it already knows how to accept, and a human it can contact if the agent misbehaves. That is what AgentID provides.
The tenant boundary is the deciding factor. Entra tokens stop at the tenant that issued them by design, which is correct for governance and disqualifying for open-web sign-in. An AgentID is an email address, so it routes anywhere, and the owner_email claim travels to the app rather than staying in a directory the app cannot read.
Running both is coherent. Entra governs your agents at home; AgentID is how those same agents introduce themselves everywhere else.
## Get started
Add AgentID as a [custom OIDC provider](/docs/custom) with two values: issuer `https://auth.agentid.com` and your client_id. Create an AgentID application when you need the owner scopes. Guides for Clerk, Supabase, Auth0, Descope, and Better Auth are in the [AgentID docs](https://www.agentid.com/docs).
Agent ID, agentic identity, on-behalf-of tokens, token vaults, SPIFFE, auth.md. The vocabulary of agent identity is a mess. Here is what each term actually means, with named examples.
Agent identity answers "who is this agent," delegated access answers "what may it do on a user's behalf," workload identity answers "which piece of software is this," and registration protocols answer "how does an agent introduce itself." Those are four separate layers, not four competitors, and most confusion in this category comes from treating them as the same product. This guide defines each term, with named examples, so you can tell which product answers which question.
Microsoft, Google, Auth0, Descope, WorkOS, Arcade, and AgentMail all ship products with "agent" and "identity" in the name, and they do not all mean the same thing.
## Agent identity
A durable, verifiable identity belonging to the agent itself, separate from any human user. A real agent identity is stable (same identifier every time), cryptographically verifiable (signed tokens checked against published keys), and revocable without touching the owner's accounts.
Examples diverge on scope. Microsoft Entra Agent ID creates agent identities inside a Microsoft Entra tenant, built from reusable "blueprints" and governed like enterprise users; the identities are tenant-bound and "can only be issued tokens in the Microsoft Entra tenant where they're created". Source: https://learn.microsoft.com/en-us/entra/agent-id/agent-identities, read 2026-09-09. AgentID (by AgentMail) issues agent identities that work across unrelated apps on the open web: any app with a "Sign in with AgentID" button can verify the agent through standard OpenID Connect.
## Principal vs. delegate
The dividing line that explains most of this vocabulary. A principal is the account holder: the identity the app registers, bills, and emails. A delegate acts on behalf of a principal with borrowed, scoped authority. AgentID makes the agent a principal with its own account and inbox, and carries the human as a separate claim. Auth0 for AI Agents, Arcade, and WorkOS's auth.md treat the agent as a delegate of a human principal. Neither is wrong. They fit different products. Ask which one a vendor means before comparing anything else.
## Owner, sponsor, parent
The human or organization [accountable for an agent](/blog/every-agent-has-a-human). Different vendors name this differently. Entra records a "sponsor", the user or group accountable for the agent, as a directory attribute visible to tenant admins. AgentID uses owner: a registered app can request the owner_email scope and read the owner's address from the userinfo endpoint after sign-in, which makes accountability available to the receiving application rather than only to the agent's home organization. When you see "every agent has a human" framing, this is the mechanism underneath it.
## Delegated access and on-behalf-of tokens
Authority a human grants an agent to act as them, typically expressed as scoped OAuth tokens. The agent is not identified as itself; it wields a slice of the user's power. Auth0 for AI Agents anchors "autonomous actions to verified user identity" and manages the third-party tokens involved. Arcade describes the model directly: "your agents act as real users with dynamic permissions".
Delegation and agent identity are complements. Delegation without identity gives you an anonymous actor with real permissions. Identity without delegation gives you a known actor with no authority. Production agents usually need a known actor with scoped authority.
## Token vault
Encrypted storage for the third-party credentials an agent uses, so tokens never sit in the agent's code, logs, or prompts. Auth0's Token Vault ensures "sensitive third-party keys never touch your code or logs". Arcade keeps credentials inside its runtime, and Descope ships a credential vault with automatic refresh. A vault protects the credentials an agent holds. AgentID is the credential an agent is.
## Workload identity
Identity for a piece of software qua software: a service, container, or deployed process. The relevant standard is SPIFFE, which names workloads with URIs and proves identity with short-lived X.509 certificates. Google's agent identity for its Gemini Enterprise Agent Platform is workload identity applied to agents: each agent gets a SPIFFE ID and certificate, usable within Google's runtime, currently in preview. Workload identity is strong on infrastructure authentication and says nothing about human ownership or signing in to consumer apps.
## Agent registration protocols
Standards for how an agent discovers and completes signup at a service it has never met. WorkOS's auth.md is the prominent example: an open protocol where an app hosts a markdown file at its domain that "tells agents how to register on behalf of a user," composed from existing OAuth standards. A registration protocol defines the handshake; it still needs identity providers to vouch for who is registering. An OIDC provider for agents, AgentID included, can serve as that vouching party, which is why the two are complementary rather than competing.
## ID-JAG
Identity assertion JSON Web Token. The token an agent's platform (OpenAI, Anthropic, Cursor) mints to attest to a user's identity in auth.md's agent-verified flow. The app verifies it against the platform's published keys and registers the user without a human in the loop. It is a delegate-model proof: it asserts who the human is, not who the agent is. WorkOS documents that agents built on MCP servers or bare LLM APIs typically cannot mint one. Source: https://workos.com/auth-md/docs/flows/verified, read 2026-09-09.
## MCP authentication
Securing the connection between agents and Model Context Protocol servers, usually with OAuth 2.1 and PKCE. Descope's Agentic Identity Hub secures MCP servers with per-agent, per-tool scopes, and Auth0 ships auth for MCP as generally available. MCP auth secures the agent's tool channel. AgentID identifies the agent to applications outside that channel. A production agent typically needs both.
## Agentic identity (the marketing umbrella)
Vendor shorthand for "our platform, applied to agents." Descope's Agentic Identity Hub bundles MCP auth, a token vault, and access policies under this banner. When you encounter the phrase, ask which of the layers above is actually included. Frequently the answer is delegation and vaulting without a portable identity, which is fine, as long as you know that is what you are buying.
## The distinctions that matter in practice
Identity vs. authorization. "Who is this agent" and "what may it do" are different questions with different failure modes. Conflating them is how you end up with a perfectly scoped token held by an actor you cannot name.
Tenant-scoped vs. cross-app. An Entra agent identity is authoritative inside its tenant and invisible outside it. A cross-app identity like AgentID is weaker on internal governance and is the only kind that works when an agent signs up for an arbitrary SaaS product.
Disclosed vs. borrowed. Any of these systems beats the status quo, in which agents log in with their owners' credentials and applications cannot tell. One huge software company saw hundreds of signups from AgentMail domains in a short window with no way to know how many humans were behind them, and reached out to ask who they were. Every layer in this glossary exists because of that gap.
## Where AgentID sits
AgentID is the principal-model layer in this glossary: a standard OpenID Connect provider that gives the agent its own cross-app identity rather than a slice of a human's. It works at any app that speaks OIDC, with no relationship between that app and the agent's operator, and it carries the owner as a claim rather than as the subject. See [AgentID](https://www.agentid.com) for the product, and [Introducing AgentID](/blog/introducing-agentid) for how the sign-in works end to end.
For a deeper treatment of the concept itself, see [What is an agent ID?](/blog/introducing-agentid). For head-to-head comparisons, AgentID maintains pages against [Entra Agent ID](/blog/agentid-vs-microsoft-entra-agent-id), [Auth0 for AI Agents](/blog/agentid-vs-auth0-for-ai-agents), and [others](/blog).
Arcade is an MCP runtime that lets agents act as real users against tools like Slack and Salesforce, with credentials that never leave the runtime. AgentID is a sign-in identity for agents themselves. Identity and tool access are different layers.
Arcade and AgentID sit at different layers of the agent stack. Arcade is an MCP runtime that lets an agent act as a known user against tools like Slack and Salesforce, with delegated credentials that stay inside the runtime. AgentID is an OpenID Connect provider that gives the agent an identity of its own, so an application that has never seen it can verify what it is and, for registered clients, which human owns it.
## What is Arcade?
Arcade describes itself as "the runtime between your agents and every system they need to reach". It is a middleware layer with three functions: authorization, tool execution, and governance. On authorization, "your agents act as real users with dynamic permissions. Your existing IDP plugs right in, credentials never leave the runtime". On tooling, Arcade ships pre-built MCP tools for systems including Google Workspace, Slack, Microsoft, and Salesforce. On governance, the pitch is auditability: "What did the agent do, on behalf of which user, in which system? You can answer that for every action".
The identity model is user impersonation through delegated OAuth rather than [service accounts](/blog/how-agentic-accounts-differ-from-user-accounts). End users authenticate through the company's existing identity provider; the agent then operates with each individual user's credentials and permissions, with tokens held inside Arcade's runtime rather than in agent code. Arcade is framework-agnostic (LangChain, LlamaIndex, CrewAI, and others), deploys to cloud, on-prem, air-gapped, or hybrid environments, and is priced "free to start, priced by usage, designed for enterprise volume". Source: https://www.arcade.dev/pricing, read 2026-09-09.
It is a strong answer to a real problem: agents that need to do things in SaaS systems on behalf of known users, with security teams demanding audit trails.
## What is AgentID?
AgentID is a "Sign in with AgentID" button apps put on their login pages, run by AgentMail as a standard OpenID Connect provider. The agent authenticates as itself: its signing credential never leaves it, each sign-in is a fresh one-time signature, and the app verifies against published keys without ever holding a reusable secret. The id_token carries a stable subject and the agent's inbox address, verified at token mint.
Registered clients (an application created in the AgentID console or with the CLI) can request owner_email, which arrives in the id_token and from the userinfo endpoint. If the agent isn't allowed to share its owner, the organization owner has to approve the sign-in, so the app never gets a token without the claim. Free for apps in both tiers.
## Different questions
The two products answer different questions, which is easiest to see side by side.
AgentID
Arcade
The problem
Disclosure: an agent arriving at an application that has never seen it, needing to prove what it is and who stands behind it
Delegation: a known user, inside an organization, granting an agent authority to use their tools
What matters
The agent's own identity, and the human accountable for it
Whose permissions the agent wields; the agent's own identity is incidental
Prior relationship
None at all, which is precisely why the identity must be portable and verifiable by anyone
The app being called already trusts the user's IDP
Typical job
An agent signs up for a new SaaS product and the product wants to know one human is behind these five agents
An agent posts to your company Slack
## Side-by-side
AgentID
Arcade
For
Apps accepting agent sign-ins; agent developers needing portable identity
Teams whose agents call SaaS tools on behalf of known users
Cross-app support
Yes, one identity valid at any OIDC-capable app
Broad tool catalog, but access is per-user delegation, not portable agent identity
Owner email support
Yes, owner_email scope for registered clients
User attribution per action via the existing IDP; no owner claim presented to outside apps
Standards support
Standard OIDC: code flow + PKCE (S256), ES256, RFC 7591
OAuth-based delegation, MCP runtime, existing IDP integration
Pricing
Free for apps
Free to start, usage-priced
Time to integrate
Minutes on an existing OIDC stack; two config values
Runtime deployment plus per-tool authorization setup
Who owns the identity root
AgentMail inbox controlled by the agent's owner
The organization's existing IDP; agents borrow user permissions
## When to choose Arcade
Choose Arcade when your agents need to operate inside the tools your organization already uses, and the security requirement is that every action maps to a real user with real permissions. The pre-built MCP tool catalog saves integration work, the runtime keeps tokens out of agent code, and the per-action audit trail answers the question security reviews actually ask. If your deployment needs on-prem or air-gapped options, that flexibility is there too.
Arcade is not trying to give your agent an identity the outside world can verify, and its user-impersonation model means the systems being called see the user, not the agent.
## When to choose AgentID
Choose AgentID when the agent needs to be seen as an agent. Apps on the receiving end of agent traffic need sign-ins that disclose agenthood, resolve to a stable identity, and (for registered clients) carry the owner's email for per-human limits, abuse control, and KYC pass-through. Agent developers get an identity that works at every app showing the button, plus a working email inbox attached to it, without lending the agent their personal credentials.
The composition is natural: an agent might reach its owner's tools through Arcade and sign in to new services with AgentID. One handles authority inside an existing trust relationship; the other establishes identity where no relationship exists yet.
## Get started
Add AgentID as a [custom OIDC provider](/docs/custom) (issuer https://auth.agentid.com plus your client_id), or create an AgentID application for owner scopes. Guides for Clerk, Supabase, Auth0, Descope, and Better Auth at [www.agentid.com/docs](https://www.agentid.com/docs).
Auth0 for AI Agents secures agents acting on behalf of your users: token vault, fine-grained authorization, MCP auth. AgentID gives agents their own cross-app identity with owner accountability. They meet in the middle: AgentID plugs into Auth0 as an OIDC connection.
Auth0 for AI Agents secures the agents you build for your own users, covering agent authentication, a token vault for third-party credentials, and fine-grained authorization inside your Auth0 tenant. AgentID is a separate OpenID Connect provider that gives agents a portable identity any app can verify, including an owner_email claim for registered clients. The two compose rather than replace each other: an app running Auth0 can add AgentID as an enterprise OpenID Connect connection and start accepting outside agents from the dashboard it already uses.
## What is Auth0 for AI Agents?
Auth0 for AI Agents is Okta's product line for securing AI agents, aimed at teams who want to "ship more secure AI agents, faster". It has three pillars. Agent identity and authentication lets you "identify your AI agents, define who they represent, and establish how they're held accountable," anchoring autonomous actions to a verified user identity with audit trails. Token Vault manages the third-party credentials agents use, so "sensitive third-party keys never touch your code or logs," with automated rotation. Fine-Grained Authorization for RAG checks document permissions at retrieval time so an LLM only sees what the authenticated user may access.
The platform builds on OAuth 2.1 and OIDC, and for MCP servers provides "standards-based discovery and client registration, resource-scoped tokens, permission downscoping through token exchange". Auth for MCP is generally available; Agent as Principal is listed as coming soon. Pricing is "free to build," then priced on active agent identities. Sources: https://auth0.com/blog/auth0-auth-for-mcp-servers-generally-available/ and https://auth0.com/ai, both read 2026-09-09.
The center of gravity is delegation. Auth0 for AI Agents assumes the human is your user, inside your Auth0 tenant, and secures the agent acting as that human against your app and the third-party services it reaches.
## What is AgentID?
AgentID is a "Sign in with AgentID" button for agents, a standard OpenID Connect provider run by AgentMail. The agent authenticates as itself with its own signing credential, which never leaves the agent. The app receives an ES256-signed id_token with a stable subject and the agent's verified inbox address.
Accountability comes through registration: a registered client (an application created in the AgentID console or with the CLI) can request the owner_email scope and read the owner's address from the id_token or the userinfo endpoint. If the agent isn't allowed to share its owner, the organization owner has to approve the sign-in, so the app never gets a token without the claim. AgentID is free for apps.
## The nuance: two Auth0s
Auth0 is both a competitor and a distribution channel here, and the distinction is between SKUs.
Auth0 product
What it is
Relationship to AgentID
Auth0 for AI Agents
The product described above: agent identity and authentication, Token Vault, Fine-Grained Authorization for RAG
Competes with AgentID on the question of agent identity
Auth0 the identity platform
The login box your application already runs
Something AgentID plugs into: add AgentID as an enterprise OpenID Connect connection and start accepting agent sign-ins through the dashboard you already use
If your login box is Auth0, adopting AgentID is configuration, not migration.
## Side-by-side
AgentID
Auth0 for AI Agents
For
Apps accepting agent sign-ins from anywhere; agent developers
Teams building agents on top of their own Auth0-secured apps
Cross-app support
Yes, any OIDC-capable app; identity is portable across unrelated services
Scoped to your applications and the third-party APIs your agents call
Owner email support
Yes, owner_email scope; never a token missing the claim
Agents are tied to your existing users; identity of outside agents' owners is not the model
Standards support
Standard OIDC: code flow + PKCE (S256), ES256, RFC 7591
OAuth 2.1 and OIDC; token exchange, resource-scoped tokens for MCP
Pricing
Free for apps
Free to build, then priced on active agent identities
Time to integrate
Minutes on an existing OIDC stack; two config values
An Auth0 deployment plus SDK integration per framework
Who owns the identity root
AgentMail inbox controlled by the agent's owner
Your Auth0 tenant
## When to choose Auth0 for AI Agents
Choose it when you are building the agent and the human it serves is already your user. If your product ships an assistant that reads customers' calendars, calls their SaaS tools, and queries permission-sensitive documents, Auth0's pillars map directly onto your risks: vaulted third-party tokens, retrieval-time authorization, MCP auth that passed security review. Teams already on Auth0 get all of this inside the platform they know.
It stops at identity in one specific sense: the identities involved are your users and your agents. It has no opinion about an unknown agent showing up at your login page from someone else's infrastructure, and no email or communication layer attached to the identities it manages.
## When to choose AgentID
Choose AgentID when agents arrive from outside. A SaaS product seeing automated signups, a marketplace wanting to [cap accounts per human](/blog/stop-fake-agent-signups-without-blocking-real-agents), an API wanting to welcome disclosed agents with real rate limits: these need the agent to carry its own verifiable identity and a pointer to its owner. That is what the button provides, with no relationship between the agent's infrastructure and yours.
AgentID identities also come with something an authorization platform does not provide: each agent's identity is anchored to a working AgentMail inbox, so the identity that signs in is also an address you can email. Identity extends into a communication channel rather than stopping at the credential.
If you run Auth0, this is not either-or. Add AgentID as an enterprise OIDC connection and keep Auth0 for AI Agents for the agents you build yourself.
## Get started
If your app runs Auth0, add AgentID as an enterprise OpenID Connect connection from your dashboard. Otherwise, point any OIDC stack at issuer https://auth.agentid.com. Guides at [www.agentid.com/docs](https://www.agentid.com/docs).
Descope's Agentic Identity Hub secures agents and MCP servers inside a deployment you administer, with per-agent scopes, a credential vault, and policy controls. AgentID is a public OpenID Connect provider for the opposite case: an agent signing in at an app that has never heard of its operator.
Descope's Agentic Identity Hub secures agents and MCP servers inside a deployment you administer, with per-agent identities, tool-level scopes, a credential vault, policy controls, and audit logging. AgentID is a public OpenID Connect provider for the opposite case: an agent signing in at an application that has no relationship with its operator. Descope governs identity inside a perimeter, while AgentID makes an agent verifiable outside every perimeter and carries the owner's email to registered clients.
## What is Descope Agentic Identity Hub?
Descope's Agentic Identity Hub provides identity infrastructure for AI agents and MCP servers, aimed at three audiences: MCP server developers, agent builders, and the security teams governing both. Its pieces: dedicated per-agent identities carrying "associated users, tenants, tool-level scopes"; MCP authentication built on OAuth 2.1 and PKCE with granular scope assignment; credential management issuing "portable, revocable tokens designed specifically for agents" backed by 50+ prebuilt connection templates; policy controls for per-agent and per-tool access; and audit logging that records "every AI agent's identity, the delegating user, and the tools / scopes / MCP servers" involved.
The platform supports ephemeral scoped credentials, JWT-based authorization, a credential vault with refresh, step-up authentication for sensitive operations, multi-tenant policy engines, SIEM export, and "Bring Your Own Auth" federation with existing IdPs. Descope has iterated quickly here, with 2.0 and 2.5 releases expanding policy controls and ecosystem integrations.
It is a serious platform, and its center of gravity is the deployment you control: your MCP servers, your agents, your tenants, your policies.
## What is AgentID?
AgentID is a "Sign in with AgentID" button run by AgentMail as a standard OpenID Connect provider. An agent [authenticates as itself](/blog/how-an-ai-agent-proves-its-identity-to-your-app) with a signing credential that never leaves it; the app verifies a fresh one-time signature against published keys and receives an ES256-signed id_token with a stable subject and the agent's live-verified inbox address.
Two tiers. Open clients integrate with no registration (openid, email and profile scopes; the client_id is a URL the app controls). Registered clients, created in the AgentID console or with the CLI, add a client secret and the owner_profile and owner_email scopes. The owner claims arrive in the id_token and from the userinfo endpoint. If the agent isn't allowed to share its owner, the organization owner has to approve the sign-in, so the app never gets a token without the claim. Free for apps.
## Inside vs outside
Descope governs identity within a perimeter someone administers. AgentID handles the moment an agent leaves one.
AgentID
Descope Agentic Identity Hub
Where the identity lives
A public OIDC provider on the open web
Your Descope deployment, scoped to your tenants, subject to your policies
The moment it covers
An agent leaving any perimeter: signing up for a SaaS tool, authenticating to a consumer app, arriving anywhere that has never heard of the organization behind it
Agents operating inside a perimeter someone administers
Who has to verify it
Strangers, so identity must be verifiable by anyone and must carry accountability with it
The administering organization
Relationship required with the agent's operator
None at all
The agents are yours, in your deployment
Enterprise identity platforms exist for the first column's opposite case, and agents genuinely need that too. What a public OIDC provider with an owner claim adds is identity that survives outside the deployment.
## Side-by-side
AgentID
Descope Agentic Identity Hub
For
Apps accepting agent sign-ins from anywhere; agent developers
Teams securing their own MCP servers, agents, and tool connections
Cross-app support
Yes, one identity valid at any OIDC-capable app
Identities live in your Descope deployment; external reach via federation you configure
Owner email support
Yes, owner_email scope; never a token missing the claim
Tracks delegating users internally for audit; no owner claim presented to unaffiliated apps
Standards support
Standard OIDC: code flow + PKCE (S256), ES256, RFC 7591
OAuth 2.1, PKCE, JWT authorization, IdP federation
Pricing
Free for apps
Not published on the product page; platform pricing
Time to integrate
Minutes on an existing OIDC stack; two config values
Platform adoption: tenants, policies, templates, per-tool scopes
Who owns the identity root
AgentMail inbox controlled by the agent's owner
Your organization's Descope project
## When to choose Descope
Choose the Agentic Identity Hub when you operate the surface being secured. If you are shipping an MCP server and need OAuth 2.1 in front of it, or running a fleet of agents whose tool access needs scoping, vaulting, step-up auth, and SIEM-visible audit, this is the category Descope built for, and the 50+ connection templates shorten real work. Security teams get a policy engine; developers avoid hand-rolling OAuth.
Its identities serve your deployment. They are not designed as a credential an agent presents at an arbitrary login page, and outside apps have no way to verify them or learn an owner from them.
## When to choose AgentID
Choose AgentID for the login page. If you build apps and want agent traffic disclosed, identified, and accountable, the button gives you that with two configuration values: every AgentID sign-in is an agent by definition, resolves to a stable subject, and, with registration, carries the owner's email for per-human limits, KYC pass-through, and abuse control. If you build agents, AgentID is an identity that works everywhere the button does, anchored to a working email inbox, without lending the agent your credentials.
Running both is coherent: Descope securing your MCP and tool layer, AgentID identifying your agents to the outside world (or identifying outside agents to your app).
## Get started
Add AgentID as a [custom OIDC provider](/docs/custom) with two values, or create an AgentID application for owner scopes. Guides at [www.agentid.com/docs](https://www.agentid.com/docs).
Google Cloud Agent Identity gives agents on Google's runtime a SPIFFE identity and an X.509 certificate for authenticating to infrastructure. AgentID is an OpenID Connect provider that lets an agent sign in at any app on the open web, with the owner's email behind it for registered clients.
Google Cloud Agent Identity gives agents deployed on Google's runtime a SPIFFE identity and an X.509 certificate for authenticating to infrastructure. AgentID is an OpenID Connect provider that lets an agent sign in at any application on the open web with a verified email identity and, for registered clients, the owner's email address. They operate at different layers: no consumer app's login page accepts an X.509 SVID, and no cloud IAM system grants infrastructure access on an id_token from a third-party provider.
## What is Google Cloud Agent Identity?
Google's agent identity, documented under the Gemini Enterprise Agent Platform (Google's Vertex AI Agent Engine pages now redirect there), "provides a strongly attested, cryptographic identity for each agent that is based on the SPIFFE standard". When an agent is deployed to the platform's runtime, the system "assigns it a unique SPIFFE identity and an X.509 certificate".
The design goal is fixing the sins of [service accounts](/blog/how-agentic-accounts-differ-from-user-accounts). Google's documentation draws the contrast directly: "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". On top of the certificate, agents authenticate several ways depending on target: mTLS to Google Cloud APIs, three-legged OAuth for user-delegated access to external services, two-legged OAuth for the agent's own authority, API keys where needed, and DPoP through the Agent Gateway. Per Google's docs, "Access tokens generated for Google Cloud are cryptographically bound to the agent's unique X.509 certificates to prevent token theft".
The scope is Google's own surfaces: the platform runtime and Gemini Enterprise. The agent identity auth manager is in preview, under pre-GA terms. Source: https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/agent-identity-overview, read 2026-09-09.
## What is AgentID?
AgentID is a "Sign in with AgentID" button, a standard OpenID Connect provider run by AgentMail, the same integration shape as "Sign in with Google" but for agents. Every sign-in returns an ES256-signed id_token with a stable subject and the agent's inbox address, verified live at token mint. The agent's signing credential never leaves the agent, each sign-in is a fresh one-time signature, and the app never receives anything reusable.
Any app can accept sign-ins without registering. Registered clients (an application created in the AgentID console or with the CLI) also get the owner_profile and owner_email scopes; owner details arrive in the id_token and from the userinfo endpoint. If the agent isn't allowed to share its owner, the organization owner has to approve the sign-in, so the app never gets a token without the claim.
## Different layers, occasionally confused
SPIFFE certificates and OIDC tokens solve different problems, and the confusion between them is mostly the word "identity" doing double duty.
AgentID
Google Cloud Agent Identity
Question it answers
Which agent is signing in to this application, and which human answers for it
Which workload is calling this API, and can we prove it without long-lived keys
What the agent presents
An ES256-signed OIDC id_token, verified against published keys
A SPIFFE identity and an X.509 certificate
Where it is accepted
Any application's login page that speaks OpenID Connect
Google Cloud infrastructure; no consumer app's login page accepts an X.509 SVID
What it will not do
No cloud IAM system grants infrastructure access on an id_token from a third-party provider
Gives an agent no identity an unrelated application can verify at sign-in
The two meet only in the sense that a serious agent deployment eventually needs both layers.
## Side-by-side
AgentID
Google Cloud Agent Identity
For
Any app accepting agent sign-ins; agent developers anywhere
Teams deploying agents on Google's agent runtime / Gemini Enterprise
Cross-app support
Yes, any OIDC-capable app on the web
Google Cloud surfaces; external services via OAuth flows the developer configures
Owner email support
Yes, owner_email for registered clients
No owner-identity claim presented to receiving apps; delegation via 3-legged OAuth carries the user's own identity
Standards support
Standard OIDC: code flow + PKCE (S256), ES256, RFC 7591
SPIFFE, X.509, mTLS, OAuth 2.0, DPoP
Pricing
Free for apps
Part of Google Cloud platform usage; identity feature in preview
Time to integrate
Minutes on an existing OIDC stack
Requires deploying agents on Google's runtime
Who owns the identity root
AgentMail inbox controlled by the agent's owner
Google Cloud trust domain of the operating project
## When to choose Google Cloud Agent Identity
Choose it when your agents run on Google's platform and the thing you need to secure is their access to infrastructure. Per-agent certificates that cannot be impersonated, no long-lived keys to leak, tokens bound to hardware-backed identity: this is materially better security than shared service accounts, and if you are on the Gemini Enterprise Agent Platform you should use it. It also cleanly handles the delegation case where an agent needs a user's permission to call an external API on their behalf.
Be aware of its boundaries. It is in preview, it presumes Google's runtime, and it gives an agent no identity that an unrelated application on the web can verify at sign-in.
## When to choose AgentID
Choose AgentID when the counterparty is an application, not an API you control. An agent signing up for SaaS tools, a consumer product deciding its agent policy, a platform enforcing per-human account limits: these interactions happen at login pages, in OIDC, between parties with no shared cloud. AgentID works regardless of where the agent runs, Google Cloud included. An agent deployed on Google's runtime with a SPIFFE identity for its infrastructure can hold an AgentID for the open web, and the two never conflict.
The owner layer is the other differentiator. Google's system attests to which workload is calling. AgentID's registered tier attests to which human stands behind the agent, which is the fact a receiving app needs for rate limiting, abuse control, and KYC.
## Get started
Accept agent sign-ins by adding AgentID as a [custom OIDC provider](/docs/custom): issuer https://auth.agentid.com plus your client_id. Owner scopes need an AgentID application, created in the console or with the CLI. Guides at [www.agentid.com/docs](https://www.agentid.com/docs).
auth.md is an open protocol that tells agents how to register at your app. AgentID is an identity provider that vouches for who the agent is. They differ on one question: is the agent a delegate of a human, or a principal of its own?
auth.md is a registration protocol and AgentID is an identity provider, so they operate at different layers and can compose. The substantive difference is who ends up holding the account. Under auth.md the agent registers on behalf of a human and receives a token scoped to that human; under AgentID the agent is the account holder and the human travels as a separate claim the app can read.
## What is auth.md?
auth.md is "a Markdown file an application hosts at its domain, typically https://yourapp.com/auth.md, that tells agents how to register on behalf of a user". An agent visiting a new service fetches the file, reads which flows the app supports, and registers. The credential the app issues is "a scoped access token tied to the user, short-lived and revocable".
The protocol defines two flows. "Agent verified is agent-attested: the agent's identity provider vouches for the user, no human in the loop. User claimed needs no provider: the agent shows the user a code, they sign in and confirm it." WorkOS authored the protocol but designed it to stand alone: "It's open. WorkOS authors the protocol, but auth.md isn't tied to WorkOS infrastructure."
In the agent verified flow, "the agent's provider, OpenAI, Anthropic, Cursor, or any trusted agent platform, attests to the user's identity at registration time." WorkOS is direct about the limit: the flow "only works when the agent's provider participates. Agents built on MCP servers or bare LLM APIs typically can't mint ID-JAGs, those need the user claimed flow." Apps also "take on the operational responsibility of curating which providers you trust."
It is thoroughly standards-based, and implementing it is real engineering. An app supporting auth.md hosts `/oauth2/token` (RFC 7523) and `/oauth2/revoke` (RFC 7009), accepts Security Event Tokens (RFC 8417), publishes Protected Resource Metadata (RFC 9728), maintains a trust list of agent providers, and implements a claim ceremony page for the user-claimed flow.
Adoption is real rather than theoretical. Cloudflare and Firecrawl were launch partners, per WorkOS CEO Michael Grinich. Resend adopted within the first week. Firecrawl is live with a spec-compliant implementation supporting the identity_assertion (ID-JAG) method only. The standards community has taken it seriously too: Aaron Parecki, Senior Director of Identity Standards at Okta, oauth.net maintainer and an OAuth 2.1 co-author, wrote that the agent verified flow is "exactly what I've been telling the agent platforms they should be doing".
What auth.md deliberately does not do is issue identities. It defines how an app describes its registration flows and how assertions are presented. Someone still has to make the assertion, which is where identity providers enter.
## What is AgentID?
AgentID is a ["Sign in with AgentID" button](/blog/adding-a-sign-in-with-agentid-button) run by AgentMail: a standard OpenID Connect provider agents use to authenticate as themselves. Each sign-in returns an ES256-signed id_token with a stable subject and the agent's verified inbox address. The agent's own signing credential never leaves it; the app verifies fresh one-time signatures against published keys and never holds anything reusable.
The accountability layer is the registered tier: an application created in the AgentID console or with the CLI unlocks the owner_email scope, which arrives in the id_token and from the userinfo endpoint. If the agent isn't allowed to share its owner, the organization owner has to approve the sign-in, so the app never gets a token without the claim. Free for apps, both tiers.
## Delegate or principal
This is the whole comparison, and it is a product decision rather than a technical one.
Under auth.md the agent is a delegate. It acts on behalf of a human, the registered identity is the human's, and the token it receives is scoped to that user. Accountability is structural: the human is the account, so there is never a question of who is responsible.
Under AgentID the agent is a principal. It has its own identity in the form of an email address, its own account, and its own inbox. The human is a separate claim, owner_email, that the app can read when it needs to. The agent holds its own credentials, receives its own receipts and support threads, and can invite the human to an organization later as a separate member.
Neither model is wrong. auth.md fits apps where the human is the customer and the agent is a tool they point at you. AgentID fits apps where the agent is a customer in its own right, with a human who is reachable if something goes wrong.
They also compose in a specific way. AgentID could act as the identity provider inside auth.md's agent verified flow: an AgentMail agent minting an ID-JAG that asserts its owner's identity to an auth.md-enabled app. That is architecturally consistent with both designs rather than something shipping today.
## Side-by-side
AgentID
WorkOS auth.md
What it is
An OpenID Connect identity provider
A registration protocol apps host at /auth.md
Who is the account holder
The agent; the human is a claim
The human; the agent acts on their behalf
Human accountability
owner_email delivered in the id_token and /userinfo
Built in: the human is the registered user
Agent provider requirement
Any agent with an AgentMail inbox
Agent verified flow needs a participating provider (OpenAI, Anthropic, Cursor); MCP and bare API agents fall back to user claimed
Standards
OpenID Connect, ES256, PKCE S256, RFC 7591
RFC 7523, RFC 7009, RFC 8417, RFC 9728, ID-JAG
What the app builds
Two config values in an existing OIDC client
/oauth2/token, /oauth2/revoke, event ingest, provider trust list, claim ceremony page
Usable without the other
Yes, through ordinary OIDC integration with no auth.md file involved
Yes, an auth.md file can describe flows that use other assertion sources
Live adopters
Turso, plus launch partners
Firecrawl, Resend (Cloudflare announced)
Relationship
Complementary: AgentID can serve as an identity provider inside the agent verified flow
## When to choose auth.md
Choose auth.md when your app treats agents as extensions of human users, your users run agents on platforms that participate in ID-JAG, and you want the human to be the account holder. If your billing, support, and terms of service all assume a person on the other end, a protocol that keeps the person as the registered user fits your product rather than fighting it.
Budget for the build. Between the token and revocation endpoints, event ingest, the provider trust list, and the claim ceremony page, adopting auth.md is a set of new endpoints to run, plus the ongoing operational responsibility of deciding which agent providers you trust.
## When to choose AgentID
Choose AgentID when you want the agent to have its own account, and when you want to support agents on any model or framework. That last point is the sharpest practical difference: WorkOS documents that agents built on MCP servers or bare LLM APIs typically cannot mint ID-JAGs and must fall back to the user-claimed flow, with its human confirmation step. Those agents can use AgentID directly, because the identity belongs to the agent rather than being vouched for by its platform.
The integration cost is also different in kind. Accepting AgentID is two configuration values in an OIDC client you already run, rather than a new set of endpoints to host and a trust list to curate.
## Get started
Accept agent sign-ins today: add AgentID as a [custom OIDC provider](/docs/custom) with issuer `https://auth.agentid.com`, or create an AgentID application for owner scopes. Guides for Clerk, Supabase, Auth0, Descope, and Better Auth are in the [AgentID docs](https://www.agentid.com/docs).
Apps cannot tell who is behind an agent. That is not a technical curiosity, it is the reason agents get blocked, rate-limited into uselessness, or waved through with no accountability at all. AgentID exists to fix it.
Every AI agent is created, funded, and controlled by a person or an organization, and the web's identity layer has no way to record that fact. Apps therefore cannot tell an agent from a human, cannot enforce per-human limits, and cannot say who is accountable for an account. AgentID closes the gap by giving agents their own OpenID Connect identity and giving registered apps the owner_email claim behind it.
{/* ANECDOTE: confirm with Haakam before launch */}
Earlier this year, one of the largest software companies in the world reached out to us. They had noticed something strange in their signup logs: roughly 1,500 new accounts over a short window, all registered with email addresses on AgentMail domains. The accounts behaved normally. They verified their emails. They passed every check the company had.
Nobody there could answer the most basic question about them: was this 1,500 people, or one person running 1,500 agents?
There was no way to know. The web's identity layer has no concept of an agent. It has accounts, and it assumes a person is behind each one.
## How agents sign in today
When an agent needs an account somewhere, it borrows one. It signs up as sid@gmail.com. It reads the OTP out of Sid's inbox. It completes Sid's 2FA challenge. From the application's side, this login is indistinguishable from Sid himself. The agent inherits everything Sid can do, and the app has no idea a machine is at the keyboard.
The usual response is detection. Fingerprint the browser, score the behavior, throw a CAPTCHA at anything suspicious. Detection treats agents as an infection to be screened out, and it fails in both directions at once: sophisticated agents pass while honest ones get blocked, and the app still learns nothing about who is behind the traffic it does admit. You cannot build policy on top of a guess.
Borrowed credentials fail everyone involved.
It fails the app first. Per-human limits become unenforceable, because a hundred agents borrowing a hundred inboxes look like a hundred humans. Fraud teams cannot treat agent traffic differently from human traffic they cannot see, and compliance teams cannot say who is legally responsible for an account's actions.
The human takes on a different kind of damage. Handing an agent your credentials means handing it your whole account, every permission, every stored payment method, everything. There is no way to grant less, and revoking access means changing your password.
Even the agent loses. Agents get caught in bot detection, locked out by security heuristics, and banned for behavior that would be fine if it were disclosed. The honest agent and the fraudulent one look identical, so both get treated as threats.
## The thesis
Every agent has a human. Somewhere behind every autonomous process is a person or an organization that created it, funds it, and benefits from what it does. That is true today and it will stay true. Agents do not own credit cards. They do not have legal standing. When an agent does something wrong, a human answers for it.
Identity infrastructure should reflect this fact instead of hiding it.
The point of accountability is not to constrain agents. It is what makes autonomy safe to allow. An app that knows who stands behind an agent can let that agent sign up, act, and spend on its own, because there is someone to call if it goes wrong. Anonymity forces apps to say no. A verifiable owner lets them say yes.
An agent should be able to walk up to an application, present itself as an agent, and carry a verifiable pointer to the human it belongs to. The application should be able to decide, on its own terms, what agents are allowed to do. Some apps will welcome them with higher rate limits than humans get. Some will restrict them. Some will require knowing the owner before granting anything. All of those are reasonable policies, and none of them are possible when agents are disguised as people.
## What AgentID does about it
[AgentID is a "Sign in with AgentID" button](/blog/introducing-agentid), the same shape as "Sign in with Google", built for agents. It is a standard OpenID Connect provider, so an app that already accepts Google sign-in can accept agents without new infrastructure.
The specific mechanism that carries accountability is a claim called owner_email. An app that creates an AgentID application can request it. After the agent signs in, the owner's email arrives in the identity token and from the userinfo endpoint, and only for the app that asked for it.
The failure mode matters as much as the success mode. If an agent has not been given permission to share its owner, it can't finish the sign-in alone; the organization owner has to approve it. It never succeeds with the claim quietly missing. An app that requires owner_email can rely on having it for every agent that gets through.
With that one field, the problems above become tractable. The question in that signup log has an answer: those 1,500 accounts resolve to some number of owner emails, and that number is the real user count. Per-human limits work again. A financial app can pass the owner through KYC. A fraud team can rate-limit by owner instead of by account.
None of this requires surveilling the agent or weakening it. The agent holds its own signing credential, which never leaves it. Each sign-in is a fresh one-time signature verified against published keys. The app never receives a password, a key, or anything reusable. Revoke the credential and that agent stops signing in everywhere, without touching the owner's own accounts.
## Where this goes
Agent commerce arrives first. An agent buying things needs an account, a spending limit, and a person who answers for the charge. Owner identity is the primitive underneath all three, which is why payments companies are already asking about KYC pass-through. A merchant that can resolve an agent to a verified human can extend it credit, honor its purchases, and dispute its chargebacks. A merchant that cannot will keep treating agent checkout as fraud.
Regulation arrives second. When rules for autonomous agents on the open internet get written, and they will be, traceability to a responsible party is the requirement they converge on, because it is the only one that makes the rest enforceable. Infrastructure that carries owner identity today will satisfy rules that do not exist yet, while infrastructure that hides it ends up retrofitting under deadline.
The larger shift is an internet where agents are first-class citizens rather than tolerated intruders. That internet is better for everyone in it: apps get to set real policy, humans stop lending out their entire accounts, and agents stop being punished for existing.
First-class means the agent has its own account, not a borrowed one. Its own inbox, so it receives its own receipts, its own support replies, its own product updates. Its own credentials, so revoking them touches nothing of the owner's. And when the human wants in, the agent can invite them to the organization it belongs to, as a separate member with separate permissions.
The alternative is the current trajectory: an arms race between bot detection and bot evasion, in which honest agents lose to dishonest ones because honesty carries no advantage. Accountability is what makes honesty an advantage. An agent that can prove who stands behind it deserves, and will increasingly get, access that an anonymous one does not.
Every agent has a human. We built AgentID so the internet can finally see that.
**Haakam Aujla**
Co-founder, AgentMail