How to Verify the Human Behind an AI Agent

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, the mechanism is three steps:

1. Register your app as a client.
2. Request the owner_email scope when the agent signs in.
3. Read owner_email and owner_name by calling /v0/userinfo with the access token after the code exchange.

The values come from the agent's AgentMail organization, which has exactly one designated owner. They are served only from /userinfo, never inside the id_token.

If the agent's credential does not permit owner disclosure, the sign-in fails with a 403 rather than returning 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.

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.

The agent's signing credential is the gate. Two conditions must hold:

• The credential must carry permission to disclose the owner.
• The organization must have exactly one designated owner holding the value.

When both are true and your client requests it, you get it. When either is false, the agent's sign-in fails with a 403.

A client that appears misconfigured is often waiting on a permission the agent's credential lacks. That failure mode is deliberate. A relying party that registered for owner verification never has to write code for the case where the owner is missing on a successful sign-in.

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: register a client. Open clients (a URL as client_id, no registration) can request only openid and email. Owner scopes require the registered tier.

Registration is one RFC 7591 call, authenticated with your own AgentMail API key. The equivalent step is also in the AgentID console, or through npx @agentmail/agentid-cli init --owner-email:

POST https://auth.agentid.com/v0/register
Authorization: Bearer <your AgentMail API key>
Content-Type: application/json

{
  "client_name": "My Tool",
  "redirect_uris": ["https://yourapp.com/callback"],
  "token_endpoint_auth_method": "client_secret_basic"
}

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, 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: call /userinfo. After your callback exchanges the code, call /userinfo with the access token:

GET https://auth.agentid.com/v0/userinfo
Authorization: Bearer <access_token>

{
  "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.

Supabase and Better Auth build the session user from the id_token, so do not expect the owner fields on the session user. The /userinfo call in your callback is where you pick them up.

Why is owner_email not in the id_token?

AgentID keeps owner_email out of the id_token because id_tokens leak, and the owner's email is personal data about a person who is not the subject of the token.

id_tokens sit in browser storage, get written to request logs, and end up in session cookies and debugging output.

AgentID holds the owner snapshot on the grant record when /token runs and serves it only from /userinfo, re-verifying the live inbox on every call. The id_token signing code takes no owner input at all, so no id_token can carry the claim.

If you decode an AgentID id_token and find owner_email in the scope claim but not in the body, that is the expected result.

Any tutorial or sample that shows owner_email inside an id_token is describing something the issuer does not do.

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.

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.

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.