AI agents are software that does things for people online, including shopping. In recent weeks, people who use them have reported that shopping, travel and other sites blocked their agents; more on those reports below.
If you run an online store, you may be spending money and time on GEO (generative engine optimization): getting your pages and products into the answers of AI assistants, the chat programs that answer people’s questions. The visitor who follows an AI answer to your store can be an AI agent shopping for a person. Your site’s bot defenses can turn that agent away before it buys, because they can’t tell whom the agent acts for. When that happens, as I see it, the work that put your store in that answer is wasted, and you have limited hope of earning back what you spent on GEO.
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 an AI 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 standards are proposed. KYAPay works: in the demo in my first post, an AI agent shopped on a real merchant’s site and the live bot defenses guarding that site accepted the agent’s real token.
The post follows a shopper’s AI agent from finding your store to paying for an order, and says what your store needs at each step. Where your security vendor, the company that protects your site from bots and fraud, checks the token for you, there’s little to no engineering work on your website. If your checkout asks shoppers to log in, KYAPay is designed to handle that step with token exchange (spec in progress): your account system checks the agent’s token and, in exchange, logs the agent in to the shopper’s account.
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. To go further into either topic, read them.
In this post: how AI sends shoppers to your store · letting a shopper’s agent in · paying within fixed limits · what KYAPay gives your store · staying in control · what KYAPay needs from you · getting your store ready
Found: how AI sends shoppers to your store
What your store needs here: your products in the answers that AI assistants give, and a site that lets in search engines’ crawlers, the programs that read your pages.
In Adobe’s data, visits to US retail sites from shoppers clicking links in AI assistants and similar AI tools were up 693% over the 2025 holiday season, compared with the year before, from a base of users Adobe calls modest. In a March 2026 Adobe survey of more than 5,000 people in the US, 39% said they had used AI assistants for online shopping.
An AI assistant typically writes one answer from many web pages. The research paper that named GEO found that three additions did the most to get a page used in AI answers: references to sources, quotations, and statistics. In the paper’s tests, run on AI tools from 2023 and 2024, the most helpful of these changes made AI answers draw on a page about 40% more than before.
The company behind one AI assistant says its shopping answers draw on product data, such as price and description, from stores and other sources, and that when several stores sell the same item, it ranks them on factors like availability and price. In a test marketplace built for a research paper posted online without formal review, AI shopping agents often picked the same few products and were swayed by where an item appeared in a list. Their picks could also change when the AI program that powers them was updated.
Two companies that run AI assistants tell stores how to get into their answers. The first, the one in the paragraph above, asks for product feeds: files listing your products, prices and stock, sent regularly. The other, which also runs a search engine, asks you to keep your store’s information current and to let its crawler through your hosting and your CDN, the network of servers that delivers your pages to visitors.
Some AI assistants also let a shopper pay right in the chat, but only at stores they have approved: for one assistant, approved partners; for another, eligible US retailers.
Getting into AI answers and taking payment in the chat both ask your team to build something: a product feed, sent first for validation and then refreshed every day, and a checkout integration with the assistant. That takes engineering time, and engineering time costs money. KYAPay is for agents that shop on your own site, through your own checkout, and it needs no feed or integration of its own: when your security vendor checks KYAPay tokens for you, your website needs little to no engineering work. If your checkout needs a login, your account system has to support token exchange (spec in progress) to log the agent in.
Being found isn’t the same as being let in
Your CDN is also part of the defenses in front of your site. The same defenses that must let a search engine’s crawler in also decide whether a shopper’s AI agent gets in. Besides crawlers, automated visitors to your site include programs that run fixed scripts, AI agents that work out what to do as they go, and programs built to avoid detection. None of these shows who it is or whom it works for, so your defenses can’t tell them apart. 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.
Here are the reports of blocked agents mentioned at the top. People using new personal AI agents have reported that shopping, travel and other sites turned their agents away, and some say that sites which used to work for their agents no longer do. Some sites mean to keep agents out, and that is their call. But not every block is deliberate. The head of a company that tests AI for safety told a reporter that anti-bot systems set up against scammers and hackers catch agents too. And two of the sites named in those news reports said their checks had blocked, or could block, agents they didn’t mean to block.
Whether a block is deliberate or not, your defenses aren’t wrong to make it. A visitor that won’t say who it is or whom it works for can be a scammer, a hacker or a shopper’s agent, and your defenses can’t tell which. What to look for is a visitor that shows who it acts for, in a form your defenses can check, signed by a service you trust. A shopper whose agent can show that is worth letting in: the agent can find your store and products even when the shopper never named you. KYAPay is how a shopper’s agent shows that, as the next section explains.
Let in: what your store needs to recognize a shopper using an agent
What your store needs here: a way for your existing defenses to tell a shopper using an agent from a bot.
The usual question about an automated visitor is whether it’s a good bot or a bad bot. With KYAPay, the question about every visitor is which of three kinds it is: a person, a person using an agent, or a bot. When you let in a person using an agent, you’re letting in a shopper, not a bot, and KYAPay is how your defenses tell the two apart. KYAPay has three kinds of token. A KYA token, short for know your agent, says who is behind the agent. The agent shows it to get into your site. A PAY token carries the payment details. A third kind, the combined KYA-PAY token, carries both. In this post, “KYAPay token” means a token of any of the three kinds, not only the combined one. The tokens use an existing standard format for signed records. KYAPay doesn’t add a new payment network: its tokens travel over the web in the usual way, and payments use the payment systems that already exist.
Each token travels inside the agent’s ordinary requests to your site: the messages it sends to load a page or take an action. The token sits in a labeled field named KYAPay-Token. A KYA token names the person or organization the agent works for and the agent itself. It can also name the company that runs the agent, which can be a separate business that runs agents for many people. The issuer, the service that creates the token, signs it as a whole, so none of those names can be swapped.
KYAPay tokens are built to be read by the defenses already in front of your site. The outer ones are your bot defenses or CDN, which see each visit first. Further in are your fraud screening and your protection against account takeover. Any of these defenses that checks KYAPay tokens confirms two things: that a token comes from an issuer you have chosen to trust, and that the token’s signature is genuine. The defense doesn’t need to contact the issuer on every visit.
One of the Internet-Drafts covers how KYAPay tokens are used; I’ll call it the “using” draft. Its default is that your defenses let in a legitimate agent with a valid token. The rules stay yours, though: you can let the agent in, limit how fast it can make requests, ask for extra verification, or turn it away. The token adds to what your fraud tools already look at, such as how a visitor behaves and what device the visitor uses; the token doesn’t replace those checks.
Defenses that check KYAPay tokens can let an agent with only a KYA token browse and fill a cart, as they would a shopper who hasn’t reached the checkout yet. Through token exchange, your account system can check a KYA token and log the agent in to the shopper’s account. Spec in progress: token exchange has its own Internet-Draft at the IETF, and we’re developing it now.
The identity at the door carries into the purchase
The payment details can travel in a PAY token sent along with the KYA token, or in one combined KYA-PAY token. Either way, KYAPay lets the identity the agent showed at the door carry through to the payment.
Paid: checkout within fixed limits
What your store needs here: agents whose tokens are designed to be issued only after the shopper approves, spending limits the agent can’t go past, and the checkout you already have. The agent can check out as a guest, or log in through token exchange (spec in progress).
KYAPay calls for every KYAPay token to be issued only with the shopper’s approval, and the token’s issuer collects that approval for you before the agent reaches your checkout. For a card payment, the card network shares that work: the shopper can approve through a card network’s own program for AI agents. Card networks are the companies that run the systems card payments travel on, and two of them have such programs. In those programs, the shopper gives consent with a passkey: a sign-in that uses a fingerprint, face or device PIN instead of a password. KYAPay is also designed so that your store can signal when a sensitive action, such as a payment, needs stronger proof of who the shopper is. Once the shopper has given that proof, the issuer of the agent’s KYAPay token can give the agent a new KYAPay token.
A PAY token sets what the agent can spend and where: the amount, the currency and the store. The token is signed, so the agent can’t change these, and your fraud tools can treat them as hard limits. A PAY token must never carry a card number or the security code printed on the card. Instead, it can carry a network token: a stand-in for the card number, issued through the card network. A network token can be limited to one use, one store, one amount and a few minutes. PAY tokens also cut your fraud risk: before the network token is issued, the PAY token’s issuer (Skyfire, for example) and the card network verify who the shopper is and collect the shopper’s approval. The PCI Security Standards Council, which sets the card industry’s security rules, says a network token isn’t card data outside the systems that create it. So an agent can carry a network token and present it at your checkout without handling card data. The card industry’s security rules still apply to your own checkout: most stores leave meeting them to their payment provider, and some large merchants meet them themselves.
On a website, the agent can pay the way a shopper would, by filling in your checkout page with the network token that the PAY token carries, in place of a card number. A network token is formatted to fit the ordinary card fields, so the order can go through your own checkout. The agent can check out as a guest, or, if your checkout needs a login, log in first through token exchange (spec in progress). In the demo in my first post, the agent checked out with a network token through a card network’s program for AI agents.
A stolen KYAPay token is worth little. It can be set to expire in minutes, and each KYAPay token works at one store only. Spec in progress: for extra protection, KYAPay is designed for proof of possession, which makes a stolen KYAPay token useless on its own. The agent signs each request with a secret key, a digital code only it has. The KYAPay token lists a matching public key, which can check those signatures but can’t make them. So your site, or more typically the security vendors already protecting it, can check each signature, but a thief with only the token can’t make one.
What KYAPay gives your store
Five things KYAPay is designed to give your store, and why each matters, as I see it.
You know who you’re selling to. An agent you can’t identify is a risk you’d rather block. Many businesses also have to know who is behind a purchase, under know-your-customer rules, anti-money-laundering rules or accounting standards. When an agent acts for a person or organization, its KYA token names them and ties them to that agent, so you know whom to hold responsible. A bot that buys 1,000 pairs of shoes looks like a scalper. An agent making 1,000 purchases for 1,000 named shoppers is serving 1,000 customers, and the KYA tokens show you which is which. If something goes wrong, you or your security vendor can act against the one person or agent at fault, without blocking every other agent from the company that runs that agent, unless that company is itself at fault.
You keep your customer. When an agent shops for your customer, you don’t want another company standing between you and them, running that relationship. Because a KYA token tells you who the shopper is, for example through an email address, it can give you a way to contact them directly. Your own defenses can check a token without contacting its issuer during the sale. Spec in progress: with token exchange, your own account system can log the agent in, so your loyalty program and offers run through you.
You take in only the data you need. The less personal data you take in, the less you have to protect. The “using” draft asks issuers and agents to share the least revealing information that still tells you what you need to know: for example, how strongly the shopper’s identity was checked, not copies of the shopper’s identity documents. The draft also says any business that receives a token and sends it on must treat the token as sensitive personal data.
One customer, wherever they come from. The shopper who sends an agent can also visit your website themselves and use your app. If you start selling through an API, a direct connection that other software can use, you’ll want to recognize the same shopper there too. Because the KYA token names the person, you can match an agent’s visit to that same customer. Wherever the agent goes next, whether to a website, an API, another agent or another program it uses, a new KYA token can carry that same identity. And when the same customer shops in person, for example in one of your physical stores, the identity in the KYA token can let you recognize them there too. The “using” draft defines how KYAPay tokens travel in web requests, to websites or to APIs. Spec in progress: we’re working on companion specifications for other ways agents connect, such as to other programs and to other agents.
One open protocol. You don’t want to depend on a single gatekeeper. KYAPay is open: its six Internet-Drafts are public, and anyone can run an issuer. KYAPay tokens are built on existing web standards. The draft that defines KYAPay tokens (the token draft), the “using” draft and the token exchange draft are all put forward for the IETF standards track, the path by which internet standards are made. And you decide which issuers you trust.
Letting agents in, on your terms
Letting shoppers’ agents in doesn’t mean giving up control. Here are the safeguards described above, in one place:
- You see who is behind the agent. A KYA token names the agent and the person or organization the agent acts for, and no one can change the token without the change showing.
- Your rules stay yours. Your defenses can let an agent in, limit how fast it can make requests, ask for extra verification, or turn it away.
- Spending has hard limits. A PAY token fixes the amount, the currency and the store, and the agent can’t change them.
- No card numbers. A PAY token must never carry a card number; it can carry a network token instead.
- A stolen KYAPay token is worth little. It can be set to expire in minutes, and it works at one store only.
- You act against the one at fault. If something goes wrong, you or your security vendor can act against the one person or agent at fault, without blocking all the other agents from the company that runs that agent, unless that company is itself at fault.
What KYAPay needs from you
When your security vendor checks KYAPay tokens for you, your website needs little to no engineering work. If your checkout needs a login, your account system has to support token exchange (spec in progress) to log the agent in. Selling through an API takes work from your developers.
KYAPay doesn’t ask your developers to build a new API just for agents: the KYAPay token travels in the requests your site already handles, and the “using” draft says sending it that way “requires no change to how a merchant’s site is built”. If your checkout needs a login, your account system can log the agent in through token exchange (spec in progress).
All of that is about your website. Selling through your own API is different: your developers add support for PAY tokens or combined KYA-PAY tokens to that API. How they add it depends on the protocol the API follows. A general-purpose API that takes ordinary web requests can accept PAY tokens or combined KYA-PAY tokens in those requests. If the API instead follows some other protocol, such as a commerce protocol made for AI agents, the tokens travel the way that protocol defines. Spec in progress: we and our partners are defining how KYAPay works with, and adds to, emerging agent and commerce protocols, so KYAPay tokens are designed to give you the same benefits whichever way an agent reaches you.
The token draft is designed so that the security vendors that already sit in front of stores can check and accept tokens for the stores they protect: in the draft’s words, “a standardized network of acceptance across the web security ecosystem”.
Three things to do: ask your security and fraud vendors to check KYAPay tokens for you; decide which issuers you trust; and decide your rules for agents. Skyfire is the first issuer, and it is live today: your website could be agent ready in less than a day. If your checkout needs a login, your website can be ready once your account system supports token exchange (spec in progress). For help with any of these, or if you sell through an API, email me at [email protected].
Get your store ready
If you’re already spending on GEO to bring visitors from AI assistants, those visitors can include shoppers using AI agents. Where your site’s defenses check KYAPay tokens, the site you already have can let in shoppers’ agents that carry a KYA token, and let them buy with a PAY token. A checkout that needs a login can run through token exchange (spec in progress).
To get your store ready for shoppers using AI agents, email me at [email protected].
The KYAPay consortium is the group of organizations listed as participants on kyapay.org. Its members include Akamai, Cequence, DataDome, F5, Fastly, Forter and Imperva.
