Agent Owner Verification vs End-User Authentication

Agent owner verification and end-user authentication answer two different questions that look like one.

• End-user authentication establishes that a person is present and is who they claim to be, usually so software can act with that person's permissions.
• Agent owner verification establishes which human is accountable for an agent that is acting on its own, without that human being present.

In delegate-model systems such as WorkOS auth.md, Auth0 for AI Agents, and Arcade, the human is the account and the agent borrows scoped authority from it. End-user authentication is the whole story.

In AgentID, the sign-in for AI agents from AgentMail, the agent is the principal with its own account. The owner is a claim the app can request from /userinfo.

Neither model is wrong. They fit different products, and the mistake is using one when your problem needs the other.

What is end-user authentication, and how does delegated access for AI agents work?

End-user authentication is the process of confirming that the person at the other end of a session is a specific known user.

Passwords, passkeys, OTP codes, and Sign in with Google are all end-user authentication. The output is a session or a token that says "this is user U," and every permission the software exercises afterward is U's.

When an agent is involved, end-user authentication is how delegation starts. The user authenticates, then grants the agent some subset of their authority:

• An OAuth access token scoped to read:calendar.
• A session the agent drives.
• A vaulted credential a runtime holds on the user's behalf.

The agent is never the subject of that authentication. It is a bearer of authority that belongs to someone else.

This is a perfectly good design for agents that act for a specific user inside systems that user already has access to.

Its limit is that it cannot describe an agent acting on its own:

• No session to delegate from. If the agent signs up for a new service, there is no user session.
• The wrong container. If it needs an account of its own, with its own receipts and its own support thread, the user's account does not fit.
• No slot for the owner. If the receiving app wants to know who is accountable for the agent, end-user authentication has no place for the answer, because from its point of view the agent is the user.

What is agent owner verification, and how does it differ from AI agent identity verification?

Agent owner verification is a statement from a trusted identity provider that a specific agent is owned by a specific human or organization.

It sits one layer above agent identity verification. Identity verification establishes that this is the same agent as last time and that its email is real; owner verification adds whose it is.

It is a property of the sign-in grant rather than something the agent asserts. The receiving app can rely on it because it comes from the party that issued the agent's identity.

In AgentID, owner verification works like this:

1. Every agent is an AgentMail inbox, and every inbox belongs to an organization with a designated owner.
2. A registered client requests the owner_email and owner_profile scopes.
3. After the code exchange, the app calls /v0/userinfo with the access token and reads owner_email and owner_name.

The owner claims are held on the grant and served only there, never inside the id_token, so they do not end up in logs. When the agent's credential does not permit owner disclosure, the sign-in fails with a 403.

The step-by-step is in how to verify the human behind an AI agent.

The owner shows up in the data without being in the room. The agent signed in on its own from an enrolled browser; no person clicked anything; and the app still knows who to hold responsible.

Is the agent a principal or a delegate?

A principal is the account holder the app registers, bills, and emails. A delegate acts on behalf of a principal with borrowed, scoped authority.

This is the fork that decides which of the two questions your system can answer.

The two rows on revocation look symmetric and are not.

• Delegate model: revoking one agent's grant is clean, but revoking the user cuts off every agent they run and everything else the user does.
• Principal model: each agent has its own credential. Revoking it touches nothing of the owner's, and banning the owner (by owner_email) still covers all their agents.

You get per-agent and per-human control at the same time.

Microsoft Entra Agent ID is also a principal model, scoped to the tenant that created the agent and with a required Sponsor as the accountable human.

How do auth.md, Auth0 for AI Agents, and Arcade authorize an agent, and where is the human?

WorkOS auth.md, Auth0 for AI Agents, and Arcade all authorize an agent with the user's authority, so the human is the account. All three are delegate-model products and say so in their own words.

WorkOS auth.md. WorkOS describes auth.md as "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."

Its two flows both end in "a scoped access token tied to the user, short-lived and revocable."

• Agent verified flow: the agent's provider (OpenAI, Anthropic, Cursor, and others) mints an ID-JAG asserting that the agent acts for a specific user, with no human in the loop.
• User claimed flow: the agent shows the user a code and the user confirms it.

Either way the account is the user's; the agent is registered "on behalf of" them.

This is end-user authentication extended to cover an agent that arrives first. It is a clean design for products whose account model is human accounts.

Auth0 for AI Agents. Auth0 keeps the agent a bearer of the user's authority: "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."

Its Agent as Principal feature adds first-class agent identities inside your tenant. A July 30, 2026 Auth0 post describes it as early access, while the product page still says coming soon.

That moves toward the principal model for agents you build, but it is scoped to your own Auth0 tenant rather than portable to other apps.

Arcade. Arcade states the model in one sentence: "Authentication runs against your IdP. Authorization is delegated, so the agent acts as its user." The downstream system sees the user's credentials.

None of these is a criticism. Each is the right tool when a known user is delegating to an agent inside systems that user can already reach.

What they do not produce is a verifiable statement, delivered to a third-party app, that "this agent is owned by this person." The agent's owner is either the authenticated user (so the app learns nothing new) or invisible to the receiving app entirely.

How do you tell whether an agent is acting for itself or for a user?

Look at who the subject of the token is. If the sub is a user and the agent is the client, the agent is a delegate. If the sub is the agent, it is acting as itself.

AgentID tokens always have the agent as sub, with a stable identifier derived from its inbox and the inbox address as email.

Owner information, when present, is a separate claim at /userinfo and is never confused with the subject.

This matters for what you record:

• A delegate token: attribute actions to the user and log the client.
• A principal token: create an account for the agent, attribute actions to the agent, and store the owner as the accountable contact.

Mixing the two, by treating an agent-as-principal sign-in as if the owner were the user, makes a human the customer of record for an account they never touched. That is the problem you started with.

Which one does your product need?

If your users bring their own agents and the agent should do what the user could do, you need delegation. If agents arrive as customers in their own right, you need the principal model and owner verification.

Delegation. Publish an auth.md, or configure your identity platform's agent features, and let the user's session be the anchor. End-user authentication is doing its job.

Principal model. Agents that arrive from organizations you have no relationship with need an account, an inbox for your emails, and a credential you can revoke individually. You need a human to hold accountable.

AgentID provides that through standard OpenID Connect that plugs into Clerk, Supabase, Auth0, Better Auth, or Auth.js with two configuration values. The setup is in how to let an AI agent sign in to your website.

Many products end up needing both, because both kinds of agent show up. A user's agent reading their dashboard is a delegate. A standalone agent signing up to provision resources is a principal.

The comparison with WorkOS auth.md goes into how an identity provider and a registration protocol can compose. That includes the unshipped possibility of an AgentMail agent minting an ID-JAG that asserts its owner inside auth.md's agent verified flow.

The terminology behind all of this, including workload identity and ID-JAG, is collected in the agent identity field guide.