← All articles

AI shopping agents at checkout: allow, block or verify?

Author
Artem Kireev
Read
5 min
Category
E-commerce & CRO

Stores are starting to shut their doors on AI shopping agents. Amazon reportedly removed Meta's Muse assistant in September, Delta keeps outside agents from booking flights, and the big US banks keep bots out of customer accounts. Most of these blocks are blunt, and many catch customers who are simply using an assistant.

This article argues that "block or allow" is the wrong question for an e-commerce team. The useful one is which steps of your checkout an agent may touch, and how you would know it is the agent your customer sent. It is for store owners, product managers and designers who have to decide before an agent shows up in their analytics.

Article cover with an ASCII texture
fig. 01 · Article cover with an ASCII texture

§ 01

The blocks are arriving faster than the rules

In mid-October, Android Headlines summarized the latest wave: Amazon pulling Meta's Muse assistant off its shopping platform, Delta stopping external agents from booking flights, and JPMorgan Chase, Bank of America and Citigroup keeping automated bots out of accounts. The same piece notes there is no clear industry standard for telling an authorized user bot from a malicious scraper.

That missing standard explains most of the mess. Anti-bot systems built to stop scrapers see a headless browser clicking through a cart and treat it the same way. The article points out that Cloudflare-style challenges often throw CAPTCHAs that stop an agent mid-checkout. The shopper never learns why the assistant failed. They just see it fail.

Platforms already tried to draw a line once. In 2025, Modern Retail reported that Shopify added language to the default robots.txt on merchant storefronts saying that "any end-to-end flow that completes payment without a final review step is not permitted." Shopify's Ilya Grigorik said the change added or removed no rules and mainly pointed integrators to Checkout Kit. Analyst Juozas Kaziukėnas read it as a note for developers, and merchants can override the file.

Put those together and you get a policy vacuum. The platform wrote a sentence, the CDN is guessing, and the merchant, who owns the customer relationship, usually hasn't decided anything.

§ 02

Blocking all agents has a real cost

The reflex is to keep everything out. It feels safe, and for banks it often is. For a store it is a bet that agent-assisted shoppers are worth less than the risk.

Consider what the customer sees. Baymard's cart abandonment benchmark puts the average at 70.22% across 50 studies, and among reasons shoppers give, 17% say checkout was too long or complicated and 17% cite site errors or crashes. A shopper who hands the chore to an assistant is trying to skip exactly that friction. If your bot wall breaks the assistant halfway, the failure lands on your brand, not on the assistant.

Agents also compare. If one store lets them read prices, stock and shipping cost, and the next store throws a challenge page, the first store is the one that gets considered. I think this will matter first in repeat-purchase categories where the shopper already knows what they want and only wants it ordered.

None of this means "open the gates". Fraud, price scraping and inventory hoarding are real. It means the blanket block deserves the same scrutiny as any other decision that removes a path to purchase.

§ 03

Three tiers instead of a yes/no switch

A better frame splits the journey into three tiers and sets a policy for each.

Read is the first tier: product pages, prices, availability, shipping and return terms. These are public already. Make them machine-readable with clean structured data and plain-text policies, and rate-limit rather than block. An agent that can read your return policy accurately is better for you than one that guesses.

Act is the second tier: adding to cart, applying a discount, choosing a shipping option. Here you want to know who is asking. Allow it for identified agents, and keep it behind your normal bot defenses for anonymous ones.

Pay is the third. This is where Shopify's wording about a "final review step" makes sense, and I would copy the principle. Let the agent assemble the order, but have the human confirm the total, delivery date and return terms before money moves. That also protects you from the angry-customer case where an agent bought the wrong size.

Tiers give a design team something concrete to work from. Each one maps to screens, states and error messages, rather than to a firewall rule nobody in product ever sees.

§ 04

Verified identity is the missing piece

Tiering only works if you can tell agents apart. The most credible attempt is Web Bot Auth, where an operator signs each request with a private key and the site verifies it against a public key the operator publishes. The IETF draft describes it as an architecture for identifying automated traffic using HTTP Message Signatures.

Be honest about its status. That draft is an individual submission, now expired and replaced by a newer one, and the IETF has not endorsed it. It also settles who is calling, not what they may do. Whether to allow, throttle or block a verified agent stays your decision, which is precisely why you need the tiers above.

On the transaction side, Stripe describes the Agentic Commerce Protocol, co-developed with OpenAI and released as open source in September 2025, as keeping the business as the merchant of record. Merchants decide what is sold, how it is displayed, how payment is processed, and can accept or decline any order on fraud signals. The relevant point for design is that the protocol assumes you keep control of the decision points. Sources disagree on how much live volume ChatGPT's own checkout has seen, so I would treat adoption claims with caution and the protocol's control model as the useful part.

§ 05

What to do this week

You don't need a protocol to start. You need an owner and a list.

First, find out what is happening. Pull a week of bot-challenge logs from your CDN and look for challenges served on cart and checkout URLs. If you see them, you are already blocking someone's assistant, whether you meant to or not.

Second, write the three-tier policy on one page: what agents may read, what they may do with a verified identity, and what always needs a human confirmation. Get product, engineering and whoever owns fraud to sign it. Fifteen minutes in a room beats a year of defaults.

Third, fix the read tier. Check that prices, stock, shipping cost and return terms appear in plain HTML and structured data, without a script that must run first. This also helps ordinary search and accessibility, so it pays off even if no agent ever arrives. Baymard's top abandonment reason is extra costs at 40%, so show total cost early for humans and machines alike.

Fourth, design the review step. Decide what the confirmation screen shows when an agent built the cart, and what the shopper sees if the agent is stopped. Write that error copy now. A clear "your assistant couldn't finish, here is your cart" message turns a failure into a handoff.

Then revisit the policy each quarter. The standards will move, and the first version of yours only needs to be deliberate, not final.

// new articles by email

Get the next article in your inbox.

About one a week, on product design for SaaS and e-commerce. Unsubscribe anytime.

Explore my projects selected work
/01 2026
Doc's Diesel

Doc's Diesel

E-commerce Design & CRO

/02 2026
CAPN Security

CAPN Security

Web Design & Development