Your bot protection has one job: keep out scrapers, scalpers and card testers. Then a shopper asks her assistant to buy a gift, and a machine turns up at your checkout carrying her money. Block it and you have turned away a paying customer. Let everything through and you have left a door open.
The industry's answer is agent identity: a way for a machine to prove who it is and who sent it. Three efforts are worth knowing.
Visa's Trusted Agent Protocol
Visa and Cloudflare built the Trusted Agent Protocol for this problem. The mechanism is plain. An agent is vetted and gets a signing key. Each request it makes is signed and says what the agent is trying to do, whether it is browsing or buying, whether the shopper has an account with you, and optionally the payment details. You, or your CDN, check the signature against a registry of approved agents. It builds on HTTP Message Signatures and lines up with Web Bot Auth, so it isn't tied to one payment network. (VentureBeat)
Visa describes the merchant side as no-code, though you may need to join its developer program to verify signatures. Approval criteria and fees have not been published, and the rules for a dispute over an unauthorized agent purchase are still open.
Mastercard's Agent Pay
Mastercard takes a similar route from the card side. Agents are registered and verified before they can transact on its network, and each is uniquely identified. Payments use agentic tokens, which Mastercard describes as dynamic, cryptographically secure credentials that make each transaction traceable and authenticated. Purchase intent data, such as basket contents, spending limits and validity windows, shows whether a purchase was agent-assisted or autonomous, and it can serve as an audit trail in a dispute.
For merchants, Mastercard points to the same no-code option: Web Bot Auth at the CDN layer lets trusted agents through and blocks untrusted traffic. Verified agents can also submit a token formatted for ordinary card fields in your existing checkout form. (Mastercard)
The shared piece: Web Bot Auth
Both frameworks lean on Web Bot Auth, an approach in which a bot signs its requests so a site can verify who sent them. Your CDN or bot-management vendor can often check those signatures before a request reaches your servers. That matters, because it means identity can be handled at the edge, where your existing bot rules already live.
Three kinds of visitor
Most stacks treat visitors two ways: allow or block. Agents need a third setting, and the policy is worth writing down.
- Verified agents browse, price and buy at full speed.
- Unverified agents get read-only access and a rate limit.
- People get the experience they get today.
The middle group is the hard one. Many perfectly good assistants won't be registered with anyone for a while. Blocking them costs you reach. Letting them check out unverified invites fraud. Read-only access with a rate limit lets them see your catalog without letting them transact, and you can loosen it as verification matures.
Fraud follows the money
Agents lower the cost of trying things, and returns and chargebacks follow the money. A return score works the same way whether a person or an agent placed the order, which is why we start there. The return fraud field guide shows how a score and a threshold your team controls keep honest customers out of the net, and returns are where margin hides has the numbers.
Three questions are still open, and you should expect them to be settled by the networks and by regulators in the months ahead.
- Who is liable when an agent buys something the shopper didn't intend?
- What counts as proof that a shopper authorized a purchase?
- What happens to a dispute when no person was present at checkout?
Until they are settled, keep a clear record. Log which agent placed each order, whether it was verified, and what the intent data said. That record is what you will need if a dispute lands.
Where to start
Ask your bot-protection vendor and your CDN how they treat signed agent requests today. Then write the three-visitor policy and give it an owner. If checkout and fraud sit in different teams in your business, put them in the same room for this one. The decisions cross both.