How to Verify the Human Behind an AI Agent
Know Your Agent (KYA) at the sign-in layer: how to verify the human behind an AI agent with AgentID. Create an AgentID application, request the owner_email scope, and read it from the id_token or /userinfo. What happens when the agent lacks permission to share its owner.
- AgentID
- know-your-agent
- owner-verification
- kya
TL;DR
- 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_emailat/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, the mechanism is three steps:
- Create an AgentID application for your app.
- Request the
owner_emailscope when the agent signs in. - Read
owner_emailandowner_namefrom the id_token, or from/v0/userinfowith 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.
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 Ownerpermission. - 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, or run this from your project:
Code
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, Better Auth, or Auth.js this is the Scopes field on the provider configuration. On the wire:
Code
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:
Code
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.
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.
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.
