Blog > Agentic Merchant

Agentic Merchant

| 14 MIN READ

The human is the missing signal

Legitimate AI agents get blocked because, to a fraud system, an agent with no human behind it looks like a scalper. This post shows what changes when the human is named, with a demo that runs end to end. Legitimate agents get blocked, and the fraud systems aren’t wrong Legitimate agents get blocked today. Not […]

Ankit Agarwal

Engineering

Legitimate AI agents get blocked because, to a fraud system, an agent with no human behind it looks like a scalper. This post shows what changes when the human is named, with a demo that runs end to end.

Legitimate agents get blocked, and the fraud systems aren’t wrong

Legitimate agents get blocked today. Not because they’re agents, but because nobody can see the human behind them.

When an agent shops with no human principal, every purchase traces back to the same anonymous source, so a thousand of them look like one buyer working through a store’s stock. That’s a scalper, and blocking it is the right call. Put a named person behind each purchase and those thousand purchases resolve into a thousand separate customers, each with their own history and limits. The risk is then shared out across people, as it is for any shop.

Thales reports that bots made up more than 53% of all web traffic in 2025, counting good and bad bots together, and that “much of today’s AI-driven activity remains unverified or indistinguishable from legitimate traffic.”

Part of the problem is that three kinds of automated client look the same to a merchant’s defenses. There are programmatic clients running deterministic automation, agents planning probabilistically with a large language model, and bots built to evade detection. None of them carries an identity.

So identifying the agent isn’t enough. Knowing which agent sent a request still doesn’t tell a fraud system whose purchase it is. The human is the missing signal.

Don’t rebuild the web for agents

One response is to set up agent access site by site, in advance. That reinvents the workflow automation we already had, and throws away the discovery and serendipity that make agents worth having. An agent should be able to shop anywhere its human could.

KYAPay takes the other route. It adds no new payment rail and no new API. A KYAPay token is a signed JWT that travels over the web as it already exists, using the sites, payment rails and brands people already use.

A KYAPay token carries two kinds of claim. KYA (know your agent) says who is behind the agent, and gets it through the door. PAY carries a payment credential, and settles the purchase. They can travel as separate tokens or together in one.

Watch it happen

Here is an agent buying a gift card end to end, with a verified human behind it.

What it ran on: Claude Code as the agent · the Skyfire MCP Server and the Playwright MCP Server as its tools · stage.giftcards.com as the merchant · production KYA tokens, accepted by BHN’s security vendors · Visa Intelligent Commerce and Mastercard Agent Pay in sandbox.

The terminal shows the identity header under its earlier name, skyfire-pay-id; the standardized name is KYAPay-Token.

Four moments to watch for:

  1. The door (0:34). Every request the agent sends to the store carries its identity token in a header. The store loads with no challenge and no block.
  2. The ordinary site (0:58). The agent browses the same pages a person sees. It asks which card and how much, because “the card token gets locked to an exact amount and seller,” and puts a $25 digital gift card in the cart.
  3. The human says yes (1:30). The agent shows exactly what it’s authorizing and sends an approval link. The person sees “An agent is asking to authorize a card payment,” picks a card and approves with a Visa passkey, unlocked with Touch ID. The credential comes back scoped to $25 at this one merchant.
  4. Checkout (2:25). The agent fills in the merchant’s ordinary checkout form, puts the credential in the existing card fields, clicks to place the order and confirms it.

Five-minute tokens

Watch the timing. The agent notes that “the payment token is good for about five minutes,” and midway through checkout it refreshes its identity token because the first one is past its five-minute window.

A token instead of the card number

The payment credential is built the same way. The agent never sees the underlying card number. What it types into the card field is a network token, issued by the card network and formatted to fit the card fields. It works once, at one merchant, for one amount ($25 at stage.giftcards.com here), and expires within minutes. A captured one is worth little, so handing it to an agent is a small, bounded risk. The payment section below covers PCI scope.

Real, from the agent’s side

From the agent’s side, this was the real flow. Its identity tokens were production KYA tokens, and it used a card-network credential from Visa’s sandbox exactly as it would use a production one. It would take the same steps against a production store. The test parts were the staging store, which doesn’t fulfil orders, and the card network’s sandbox, so no gift card was delivered and no money moved. The agent’s own summary at the end of the video is written from its side, so it shows the order as placed and charged.

After the order

The order goes into the merchant’s standard review, where any order can land. Once the agent is identified, the failure mode stops being “blocked at the door” and becomes ordinary commerce: out of stock, card declined, order under review. Removing anonymity removes a whole class of failure.

Who reads the token, and what the merchant does

The flow isn’t a straight line from agent to merchant. It runs like this:

  1. The agent sends an ordinary request with one extra header, KYAPay-Token.
  2. The security layer already in front of the merchant reads the token: the bot manager or CDN at the edge, and the fraud manager and account-takeover protection further in. Each checks that the issuer is one it trusts, then verifies the signature, locally, with no callout to the issuer.
  3. The edge admits the request, and the merchant serves the same page it serves everyone. The agent browses and chooses.
  4. At checkout, the agent presents the PAY token, and the credential inside it goes into the merchant’s card form.
  5. The merchant sends the credential for authorization, the network authorizes it, and the order is confirmed.

Today each of these layers decides in isolation, and their verdicts on the same request can contradict one another. When every layer validates the same token, they can be set up to agree, so a request the bot manager admits as a verified agent isn’t then scored by the fraud manager as an anonymous bot.

So there’s no integration, no API and no onboarding at the edge, as long as the security vendor in front of the merchant already verifies KYAPay tokens. The honest limit is login-gated checkout: the token gets the agent through the door, not into an account. The path there is token exchange. An authorization server verifies the KYA token and issues an ordinary OAuth access token, so the merchant gets a normal logged-in session and can tell the human arriving directly from the same human arriving through an agent.

A merchant that wants to do more can restyle its own page for an agent, the way a print stylesheet restyles a page for paper, keeping its brand, its interface and the fraud signals its models rely on, and testing with the A/B tools it already has. And because the human is named, it can recognize the same customer whether they come through the store, the app or an agent. Same customer, different door.

What’s inside the identity token

A token is only as useful as the parties it names. A KYA token can identify three:

  • The human principal (hid): the person or organization on whose authority the agent acts. This is the claim that spreads the risk, and it lets a vendor block one malicious principal without banning the whole agent platform or all its agents.
  • The agent platform (apd): the operator running the agent. A vendor can trust, limit or block the operator as a whole, and that applies to every agent it runs.
  • The agent instance (aid): the specific agent. It lets a vendor isolate one malfunctioning agent rather than a whole fleet.

The agent is always named, and so is the human whenever a person stands behind the agent; the platform claim is optional.

Because the token is a JWT, new claims and tiers need no new format, so the list can grow. One cloud provider has suggested adding a tier of its own that says how long the agent, or the agent platform, has been running on its infrastructure. A long track record there could be a useful trust and reputation signal.

Whatever the token names is bound into the token’s subject, and the issuer signs the whole token, so none of it can be swapped out. Change any one of them and you get a new subject and a new token.

Any issuer can mint these tokens, and each verifier keeps an explicit list of the issuers it trusts, the way you choose which certificate authorities to trust. Skyfire operates one issuer today.

The token isn’t tied to a browser, either. The draft specifies an HTTP header today, and the same token can be carried over MCP, A2A, WebSockets, gRPC metadata, a message queue or a stdio MCP channel, alongside emerging protocols such as UCP and Verifiable Intent, or sit in an audit log and be verified again later. Proof of possession is defined for HTTP today.

How the payment works: Visa Intelligent Commerce and Mastercard Agent Pay

The PAY half of the demo uses a credential made for agents, not a card number. Visa Intelligent Commerce issues “tokenized credentials that are bound to that agent.” With Mastercard Agent Pay, each transaction uses an Agentic Token, “uniquely issued to each agent.”

The human consents with a passkey. Visa has the cardholder set up a passkey, and uses it to authenticate the instructions the cardholder gives the agent. At Mastercard, “consumer consent is explicitly captured and purchase confirmation is secured via Mastercard Payment Passkeys.”

The credential is scoped to one purchase. Visa says its controls ensure the authorization “originates from the intended merchant for the correct amount.” Mastercard’s purchase intent data carries “cart contents, transaction limits and validity windows.” In the demo, that meant $25, at stage.giftcards.com, for about five minutes.

It also fits the checkout that already exists. Mastercard’s agentic token is “formatted for standard card payment fields,” and Visa starts with “guest checkout, key entry (form fill).”

It keeps the underlying card number out of the agent’s hands, too. Both credentials come from the networks’ own tokenization: Visa describes “tokenized digital credentials,” Mastercard “network tokens.” The PCI Security Standards Council says a payment token defined and used under the EMVCo tokenization specification, and held outside the token service provider’s own environment, “is not considered Account Data and is therefore not in scope for PCI DSS,” and Visa’s own PCI position says the same. So, as long as nothing in the path, or connected to it, also handles a card number, the agent, its platform and the KYAPay token that carries the credential stay out of PCI DSS scope. Our draft makes that a rule: a PAY token must not carry a card number. The merchant’s checkout is unchanged, and because the credential is network-issued, bound to the agent, single-use and scoped to one merchant, one amount and a few minutes, a captured one has little residual value.

Both networks have named Skyfire in their agentic-commerce announcements. In December 2025, Visa named Skyfire as enabling Consumer Reports’ product recommendation agent to demonstrate a purchase of Bose headphones. On September 30, 2026, Mastercard said it is working with Skyfire, a provider of KYA technology, “to help financial institutions and merchants recognize trusted agents across the ecosystem.”

This is where PAY meets KYA. The network proves the payment is authorized. KYA tells the merchant’s defenses who is behind the agent. PAY can ride in the same envelope as KYA, so one token format carries both.

Questions we get

Isn’t a signed token in a header just a bearer token anyone can steal? Without a confirmation key, yes, and the spec says so. The defenses are short lifetimes, audience binding, TLS and issuer-gated onboarding. The latest revisions of the drafts add proof of possession. The token can carry the agent’s public key, and the agent signs each request with the matching private key, so holding the token isn’t enough.

Why not verifiable credentials? No objection to them. The deciding constraint is who reads the token: bot managers and CDNs, which already handle JWTs at line rate and can verify a signed one locally, with no callout.

How do I know the issuer is honest? You choose which issuers you trust, as you choose certificate authorities, and the spec puts that trust check before anything else in verification.

Who’s liable if the agent buys the wrong thing? A human entity: the person who authorized the agent, or the business running it. The token can name the principal, the platform and the instance, and you can’t assign liability to a party you can’t identify.

Does identity tell you how the agent behaves? No. Identity tells you who is accountable, not whether a particular request is behaving well. Those are separate layers, and you need both. Identity gives behavioral signals someone to belong to; a score on an anonymous request has nowhere to go.

What about revocation? Skyfire’s tokens are valid for about five minutes, so an agent that runs for hours has to come back to the issuer for a fresh token every few minutes. If the agent, its platform or the human behind it misbehaves, Skyfire stops issuing tokens to it, and that works as revocation. Once the problem is found and the right to request tokens is withdrawn, a misbehaving agent keeps access for at most the life of its last token, about five minutes. There’s no revocation list and no callout at the door.

What we want to add next

We’d like your input on three additions:

  • What would fraud and bot-defense teams add to the token before they raised their own limits? We can add claims. Tell us which ones would move your thresholds.
  • Reputation. We did identity and access first, because reputation has nothing to attach to without them. Reputation is the layer we want next: whose behavior, measured by whom, and carried how?
  • What should a merchant serve an agent once the token arrives? One answer is restyling the page. We’d like better ones.

None of these ideas came from us alone. Tell us the fourth one.

Help build it

We’ve submitted six individual Internet-Drafts to the IETF, with Akamai, Experian, Okta and Ory as co-authors across the suite:

  • kyapay-token: the token format itself.
  • using-kyapay-tokens: how security intermediaries verify and act on a token, co-authored with Akamai.
  • kyapay-token-exchange: exchanging a KYA token for an OAuth access token, co-authored with Okta and Ory.
  • id-verification: names how an identity was verified, co-authored with Experian and Akamai.
  • amr-values: adds authentication-method values, co-authored with Experian and Akamai.
  • aml-methods: names the anti-money-laundering screening performed, co-authored with Experian.

There are three ways in: tell us what to add, review the drafts, or verify KYAPay at your own edge and see agent traffic you can attribute.

We’ve also published four questions we’d like to answer together:

  1. What is actually blocking agentic commerce today, in your system, not in general?
  2. What controls and fraud signals would you need before you trusted an agentic transaction?
  3. What is the value of any agent shopping anywhere its principal can, without setup in advance?
  4. Agents automate the grunt work; humans keep the decisions. What must be deterministic, and what can stay probabilistic?

Contact

kyapay.org · [email protected]

Further reading

Engineering presentations

News

Share this post

Copied!
   
View all

Join Our Community of Innovators

Stay updated with the latest insights and trends in AI payments and identity solutions.

Explore