What does an agentic protocol, one that lets AI agents browse, shop and pay for people, need to get right? Here’s my list: thirteen success metrics in four groups, and how KYAPay allows for each.
In my last post I argued that the human is the missing signal. A KYAPay token carries it: a signed JWT that can name the human, the agent platform and the agent, and carry a payment credential. There are three kinds: a KYA token carries the identities, a PAY token carries the payment credential, and a KYA-PAY token carries both.
Each metric is something KYAPay allows for, in six Internet-Drafts we’ve submitted to the IETF. Where the spec is still being written, I say so.
The thirteen metrics at a glance
- Work on the web we have, and the one that’s coming: work on the web we have · grow into the internet of APIs · minimal work for merchants · open to any issuer
- Let agents be agents: go where the human can · make room for discovery · move at machine speed
- Signals a merchant can act on: the signals the web already uses · a named, accountable human · share only what’s needed
- Authorization you can rely on: limits the agent can’t exceed · approval on both sides · a stolen token is worth little
Work on the web we have, and the one that’s coming
Work on the web we have
Success looks like: an agent uses an ordinary site through the requests the site already handles, with no agent-only version to build.
The using draft puts the token in the HTTP request itself, in a KYAPay-Token header field. The goal is for agents to use the existing web, “not a parallel, agent-only surface that must be set up in advance”. KYAPay isn’t a new rail; it uses the sites, payment rails and brands already there.
Grow into the internet of APIs
Success looks like: the same token, carrying the same identity, wherever the agent goes next, whether a website, an API, a tool, another agent or a new commerce protocol.
The using draft names the interfaces: agent-to-tool, such as the Model Context Protocol (MCP); agent-to-agent, such as Agent2Agent (A2A); agent-to-API; and emerging protocols such as the Universal Commerce Protocol (UCP) and Verifiable Intent. The token can travel over HTTP, WebSockets, message queues or a stdio MCP channel. New claims, the token’s fields, need no new format.
Spec in progress: the using draft defines the HTTP binding, and we’re working on companion specifications for other protocols. One is token exchange, already an Internet-Draft, which turns a KYAPay token into an OAuth access token, so the agent’s identity carries into MCP services. Another is binding Verifiable Intent and KYA tokens so the two travel together, with Verifiable Intent bringing authorization and the audit trail and KYA bringing identity.
Minimal work for merchants
Success looks like: a merchant doesn’t rebuild its site or add an API, and acceptance spreads through the security layer in front of merchants.
Because credentials are carried in the request, KYAPay “requires no change to how a merchant’s site is built“. Reading the token means verifying a JWT against the issuer’s public key, at the edge or deeper in the merchant’s stack. The token draft‘s aim is “a standardized network of acceptance across the web security ecosystem“.
In that network, the merchant’s security vendor verifies the token, so there’s little to no engineering work for the merchant, and login-gated checkout runs through token exchange with the merchant’s customer identity (CIAM) system or identity provider, covered below.
Open to any issuer
Success looks like: no single gatekeeper. Anyone can run an issuer, and each merchant decides which issuers it accepts.
“The system is federated: many issuers are possible,” says the using draft, and each recipient keeps its own explicit set of trusted issuers, much as it chooses certificate authorities.
Let agents be agents
Go where the human can
Success looks like: an agent reaches what its human can, with nothing set up site by site, including logged-in pages, through token exchange.
One of the token draft’s design goals is “ubiquity of access across the Internet just like their human principals“. If a person has to set up their agent’s access site by site, we’ve rebuilt the workflow automation we already have. The using draft’s answer is for security layers to admit a legitimate agent with a valid token by default, while each site still sets its own policy.
Logged-in experiences are where merchants gain the most. With token exchange, the merchant’s authorization server (its CIAM system or identity provider) swaps a verified KYA token for a standard OAuth access token, and its account system can give the agent a logged-in session with loyalty, saved preferences and offers, while telling it apart from a session where the human is present.
Make room for discovery
Success looks like: an agent finds merchants, products and alternatives its human never named, and browses before anyone pays.
If access has to be set up in advance, site by site, the human loses the open-ended discovery the using draft calls “one of the main reasons to use an agent at all”. A KYA token with no PAY token still shows a human is behind the agent, so a security layer that verifies KYAPay can let it browse, and a missing PAY token must not be treated as a sign of a bot.
Move at machine speed
Success looks like: an agent says who it is and works at machine speed, so it has no reason to slow down and pass as a person.
Without identity, a merchant’s defenses can’t tell programmatic clients, agents and bots apart, so an agent can avoid being blocked only by imitating a person and moving at a person’s pace. The using draft aims for sites to tell human-authorized agent traffic from unattributed automation and set policy on verified identity. The bot manager verifies the JWT locally, with no call to the issuer on each request.
Signals a merchant can act on
The signals the web already uses
Success looks like: the bot manager, fraud manager, account-takeover protection and identity system all see the same verified identity, for the models they already run.
The question changes from “is this a human?” to “did a verified human authorize this agent?” The fraud manager may keep its behavioral and device models; the token supplements them. Without a shared token, each layer decides alone and their verdicts can contradict, but one token gives every layer the same verified identity. Three of the drafts add vocabulary for how the identity was verified, how the human authenticated and what anti-money-laundering screening was run.
A vendor can then act on the one bad actor: the human or agent instance at fault, not a whole platform, unless the platform is at fault.
A named, accountable human
Success looks like: every request an agent makes for a human traces to a person or organization the merchant can hold responsible, bound to the agent and, where named, its platform.
The using draft starts from the hypothesis that commerce is conducted “between humans and human organizations, not between machines“, so liability must ultimately be assignable to a human party, such as the principal or the platform operator. The token names the human, a person or an organization, and the agent, and can name the platform too. The issuer signs the token as a whole, so changing any of those names would break the signature.
Merchants need that attribution: many must know who is behind a request for KYC and anti-money-laundering rules and accounting standards. They also want to keep their own relationship with their customers rather than have an intermediary run it. A token can be verified locally, without the issuer in the transaction path, and with token exchange the merchant’s own account system can give the agent its session, so loyalty and offers run through the merchant.
Spec in progress: with proof of possession, the recipient can be sure a request came from the agent or agent platform named in the token, because each request is signed, and the signature checks against the key the token carries. Section 4.3 of the using draft calls this “an unbroken chain from request to key to identity”. The protocol allows for it, and we’re working on the spec.
Share only what’s needed
Success looks like: a merchant gets what its decision needs and no more, and everyone who handles a token treats it as personal data.
“The principle of minimal disclosure should be employed,” says the token draft, and issuers and senders should prefer the least revealing claims that settle a decision, such as an assurance level rather than identity documents. Intermediaries must treat token values as sensitive personal data.
Authorization you can rely on
Limits the agent can’t exceed
Success looks like: what the agent may spend, and where, is fixed in a signed token it can’t change, and the model never holds a reusable payment credential.
A PAY token fixes the amount, currency and merchant, so a fraud manager may treat them as hard limits enforced by the token. Token creation can sit inside deterministic tools the model can call but whose output it can’t read, so the model need never see raw credentials. And a PAY or KYA-PAY token must never carry a card number or its static security code (CVV).
Approval on both sides
Success looks like: the human approves before the agent acts, and the merchant can ask for more at a sensitive moment.
Tokens should be minted only with the human’s authorization. In two card networks’ agentic programs, the human also approves a payment with a passkey. A merchant should be able to require a higher assurance level for a sensitive action and signal it, so a fresh token can be issued after extra verification.
Because the token tells the merchant who the human is, for example through an email address, the protocol also allows the merchant to contact the human directly.
A stolen token is worth little
Success looks like: a token can be set to expire in minutes, works at one merchant and carries no card number, and where the use case requires it, proof of possession means holding a stolen one isn’t enough.
An issuer should set the shortest lifetime the interaction allows, and sites should require short lifetimes, so a captured token expires quickly. Each token names the one merchant or site it’s for, so it can’t be used at another. The payment credential a PAY token carries can be network-issued, single-use and scoped to one merchant, one amount and a few minutes, so a captured one has little residual value. A token can also carry the agent’s public key, for proof of possession, and then whoever presents the token must prove they hold that key on every request.
For revocation, the using draft builds on what already exists: sites should keep accepted lifetimes short and, for high-value actions, check an issuer’s live-status or revocation endpoint where one is offered, and an issuer may stop issuing to whoever is at fault.
Spec in progress: the agent signs each HTTP request with HTTP Message Signatures, and the site checks the signature against the key in the token. That’s the using draft’s planned evolution; the protocol allows for it, and we’re working on the spec.
Where this leaves the list
Each of these metrics is in the drafts, as a specification or as a design goal. For a few, the spec is being written now, including proof of possession and companion specifications such as token exchange and the binding with Verifiable Intent.
What else does an agentic protocol need to get right, in your opinion or experience? I’d like to hear it. To see how we’ve written the metrics down, read the drafts.
