AI agents are software that does things for people online, including shopping. If you build them, your agents can be turned away at online stores. That happens not because they’re agents, but because the store’s defenses, the services that screen its traffic for bots and fraud, can’t see who the agent is or whom it acts for.
This post is about KYAPay, a protocol: a shared set of rules that lets different companies’ software work together. Its key idea is a token that your agent carries: a small, digitally signed record that says who the agent is and whom it acts for, and that can also carry payment details. No one can change the record without the change showing. We at Skyfire have submitted KYAPay to the IETF, the body that develops internet standards, as six Internet-Drafts, the documents through which new internet standards are proposed and worked out. Each draft is a specification, or spec: a set of formal rules software follows.
The post sets out why stores turn agents away, why the usual workarounds don’t fix it, what the token lets your agent show and who checks it, and what it takes on your side to get your agents recognized and let in.
My first post argued that legitimate AI agents get blocked because websites can’t see the person behind them. My second post set out what a protocol needs to get right to let AI agents browse, shop and pay for people. My third post looked at the same problem from the store’s side. Every idea this post takes from them is explained here too; read those to go further.
In this post #
- **Why agents get blocked:**[why your agents get turned away](#blocked) ·[the workarounds that don’t work](#workarounds)
- **What KYAPay gives your agent:**[a signed token](#gives) ·[who checks it](#checks) ·[your platform, named](#platform) ·[your agents’ reach](#reach)
- **Paying, and going further:**[paying within limits](#paying) ·[one identity, wherever it goes](#identity)
- **Stolen tokens and openness:**[a stolen token](#stolen) ·[no single gatekeeper](#open)
- **Getting started:**[what it takes on your side](#takes) ·[get your agents let in](#ready)
Why your agents get turned away #
To a store’s defenses, your agent looks like every other automated visitor.
A store’s site sees many automated visitors besides people: programs that run fixed scripts, AI agents that work out what to do as they go, and bots built to avoid detection. To the store’s defenses, they all look the same, and none of them shows who it is or whom it works for.
Thales, a security company, says in its Bad Bot Report that bots, good and bad together, made up more than 53% of all web traffic in 2025.
The defenses aren’t wrong to be wary. A visitor that won’t say who it is or whom it works for could be a scammer, a hacker or a shopper’s agent, and the defenses can’t tell which.
So even on sites that haven’t chosen to keep agents out, legitimate agents still get blocked: not for being agents, but because nobody can see the person or organization behind them.
The workarounds that don’t work #
Without a way to show who it is, every workaround costs your agent trust or reach, or costs the person effort.
Without a way to show who it is and whom it works for, an agent can avoid being blocked only by pretending to be a person, moving at a person’s pace. That is what bot defenses exist to stop, and it builds no trust with the store.
Another fix would be to arrange access ahead of time for each agent at each store. That doesn’t work either. An agent could then reach only the stores arranged for it, and lose what makes it worth having: finding stores, products and alternatives the person never named.
A third puts the work on the person. Asking people to create an account at every store, or to log in and share their login details with the agent, adds friction and puts off people who care about security.
What’s needed instead is a way for the agent to show who it is and whom it acts for, in a form the store’s defenses can check, signed by a service the store trusts.
What KYAPay gives your agent #
A signed token that says who your agent is and whom it acts for, in the request the store already handles.
KYAPay isn’t a new payment rail (a network that moves money) or a new API (an interface for programs to call). The token is a signed record in JWT, an existing standard format for signed records, and it travels over the existing web, using the same sites and payment rails, so a store needs no agent-only version of its site set up in advance. Pages behind a login go through token exchange (spec in progress), where the store’s account system checks the agent’s token and, in exchange, logs the agent in; more on that further down.
There are three kinds of token. A KYA token, KYA being short for “know your agent”, says who is behind the agent and gets it through the door. A PAY token carries the payment credential the agent pays with (never a card number, as the section on paying explains). The two can travel separately, or combined in one KYA-PAY token. In this post, “KYAPay token” means a token of any of the three kinds.
A KYA token names the person or organization the agent acts for and the agent itself, and it can also name your platform, meaning the company that operates the service your agents run on. The issuer, the service that creates the token, signs it as a whole, so none of those names can be swapped out: changing any of them would break the signature.
The token rides in the ordinary web request, the message an agent sends each time it asks for a page or takes an action. One of the drafts describes how the tokens are used; I’ll call it the “using” draft. It puts the token in a header field named KYAPay-Token, one of the labeled fields every such message carries.
The token is signed by its issuer, and each store’s defenses choose which issuers they trust, as a later section explains.
Who checks the token, and how #
The security layer already in front of the store can check it, against issuers the store chooses.
A store’s defenses can sit in front of its site in layers. At the edge sits a bot manager, the service that decides which automated visitors get in, or a content delivery network (CDN), the network of servers that delivers a site’s pages. Further in sit a fraud manager, which screens orders and payments for fraud, and account-takeover protection, which watches for someone breaking into a customer’s account. Each of them can check a KYAPay token itself, with no call to the issuer on each request.
Each first checks that the issuer is one the store trusts, then the signature.
Then the store’s own rules apply. The using draft’s approach is for these layers to let in a legitimate agent with a valid token by default, while each site sets its own rules: turn it away, slow it down, ask for stronger proof, or let it in. The token adds to the signals a fraud manager already uses.
KYAPay is designed so acceptance of the token spreads through the security services in front of stores, rather than one store at a time. The aim, in the words of the draft that defines the token, is “a standardized network of acceptance across the web security ecosystem”.
Your platform, named in every token #
The token can name your platform, so a store can trust your platform as a whole and still act on one agent alone.
Because the token can name your platform as well as the agent and the person, a store can trust or limit your platform as a whole. If one of your agents misbehaves, the store can block that one agent instead of all of yours. And it can block one person who misuses an agent without banning your platform.
When Skyfire, which issues KYA and PAY tokens, sets up your organization, your organization is named in every token issued for your users (usually your customers). More on that in the section on what it takes on your side.
Your agents keep their reach #
With a KYA token alone, your agent can find, browse and build a cart before anyone pays.
A KYA token with no PAY token still shows that a person is behind the agent, so store defenses that check KYAPay tokens can let the agent browse, and the using draft says a missing PAY token must not be treated as a sign of a bot. Your agent can find stores, products and alternatives the person never named, browse them, and build a cart before anyone pays.
Naming the person also changes how a large number of purchases looks. To a store’s defenses, one bot buying 1,000 pairs of shoes looks like a scalper, someone who buys up stock to resell it. An agent making 1,000 purchases for 1,000 named people is serving 1,000 customers, and the KYA tokens show which is which.
Paying within limits #
KYAPay calls for the person’s approval first, and a PAY token fixes what your agent may spend, in what currency, and where.
KYAPay calls for every token to be issued only with the person’s approval, before the agent acts. A store can also ask for stronger proof at a sensitive moment, such as a payment, so that a fresh token can be issued after extra checks.
A PAY token fixes the amount, the currency and the store, so a fraud manager can treat them as hard limits. It never carries a card number or the card’s security code.
Your model, the AI program that decides what your agent does, need never hold the payment credential. Your agent can get the token through a tool, a separate piece of software your model asks to do a job, whose output the model can’t read, and the using draft calls it desirable that the model driving an agent never sees raw credentials.
One identity, everywhere your agent goes #
The same kind of token works on websites and APIs, and is designed to carry the same identity to logged-in pages and other services.
KYAPay is designed so your agent keeps the same identity wherever it goes. The using draft defines how KYAPay tokens travel in web requests, to websites or to APIs, with each token made for one store or service. Spec in progress: companion specifications, further specs written to go with KYAPay’s drafts, are designed to carry the same identity to other ways agents connect, such as to tools, to other agents and through new commerce protocols.
Logged-in pages are where stores gain the most, and where your agent can use the person’s loyalty status, saved preferences and offers. Spec in progress: token exchange, already an Internet-Draft, turns a KYAPay token into an OAuth access token, a pass the store’s account system gives the agent (OAuth is an existing standard for granting access). The store’s account system can then log the agent in to the person’s account by checking the agent’s KYAPay token, rather than the agent holding the person’s password. Token exchange (spec in progress) is also designed to carry the agent’s identity into MCP services, the services an AI agent reaches through MCP, an open-source standard for connecting AI applications to outside systems.
KYAPay works for agent commerce today, on the web as it is. As agent protocols (new sets of rules for how agents connect to tools, services and each other) and the internet of APIs (services that agents reach directly through APIs) emerge, KYAPay is designed to extend to them, where needed through token exchange and the companion specifications above, both specs in progress.
A stolen token is worth little #
A token can expire in minutes, works at one store only, and carries no card number.
KYAPay calls for each issuer to set the shortest lifetime the task allows, and for stores to require short lifetimes, a few minutes for sensitive actions such as a payment, so a captured token expires quickly. Each token names the one store it’s for, so it can’t be used at another, and no card number is ever in it.
Spec in progress: proof of possession. A token can also carry the agent’s public key, the half of a key pair that checks signatures. Each request is then signed with the matching private key, the half that makes signatures. The agent or its platform holds that private key. Whoever presents the token must prove they hold it, so holding a stolen token isn’t enough.
Open, with no single gatekeeper #
Anyone can run an issuer, and each store chooses which ones it trusts.
KYAPay is published as six Internet-Drafts at the IETF, most of them co-written with security and identity companies. They’re built on the existing standards JWT, OAuth and HTTP (the protocol web pages travel over), so that software from different vendors can read the token the same way. The draft that defines the token, the using draft and the token exchange draft are put forward for the standards track, the path by which internet standards are made.
Each store keeps its own list of the issuers it trusts, the way it chooses certificate authorities, the organizations that vouch for websites’ identities. Skyfire is one issuer; the design assumes others.
What it takes on your side #
An enterprise account, two checks, and credentials to make the API calls you need.
Skyfire is the first issuer, and it is live today: it issues KYA and PAY tokens to agents now.
Set up an enterprise account with us: email [email protected]. We do a KYB (know your business: a check that your company is what it says it is), and we vet your user verification process with you. Then we give you credentials to make the API calls you need.
Your organization is named in every token issued for your users. You choose who verifies your customers: Skyfire, or your own process, with you named as the verifier. And you create and manage your users from one account. The details are in our organization guide.
Get your agents let in #
To get your agents recognized and let in, email me at [email protected]. The drafts: kyapay.org/standardization