What Is Agentic Commerce? And Why Your Site Blocks It
AI agents now browse, compare and buy on a shopper's behalf. Here is what agentic commerce is, the traffic it sends, and why your bot rules turn it away.
A shopper asks an assistant to find a replacement water filter, check three sellers, and buy the cheapest one that arrives before the weekend. The assistant opens a browser, works through your product pages, puts an item in a cart and heads for checkout. Every rule you wrote to keep scrapers out watches that session happen and makes a decision about it. There is a decent chance it is the wrong one.
That is agentic commerce, and today it picks up a second obstacle. Cloudflare's new traffic defaults take effect on September 15, 2026, and Agent is one of the two categories now blocked by default on pages that carry ads.
What agentic commerce actually means
Agentic commerce is shopping performed by software acting for a person: it searches, compares across sellers, applies the constraints it was given, fills a cart, and sometimes pays. The person states an outcome ("under forty dollars, here by Friday") instead of a query, and the agent does the clicking.
The word that matters in that sentence is acting. The AI traffic most sites have spent two years arguing about only ever read:
| Kind of visitor | What it does | What it wants from you |
|---|---|---|
| Training crawler | Collects text to train a model | Your content, once, at scale |
| Search crawler | Indexes pages so an assistant can cite them later | Crawl access, in exchange for citations |
| Agent | Acts on a page now, for a person waiting on the result | Search, product pages, cart, sometimes checkout |
The first two are a content-rights decision and an SEO decision, covered in what Cloudflare's crawler defaults mean for your site. An agent is neither. It is a customer arriving through unfamiliar plumbing, and blocking it costs you the order rather than a citation.
The traffic it actually sends
HUMAN Security's 2026 benchmark report, drawn from more than a quadrillion interactions across 2025, gives the clearest public shape of it. AI-driven traffic rose 187 percent between January and December 2025, and automated traffic is now growing roughly eight times faster than human traffic.
Where that traffic lands is the more useful part. Across 2025, agentic activity broke down like this:
- 77 percent on product and search pages
- 8.8 percent on account pages
- 5 percent on authentication flows
- 2.3 percent on checkout
By April 2026 HUMAN put agentic browsers, meaning a real browser being driven rather than a scripted HTTP client, at nearly three quarters of all agentic traffic.
Read those numbers together and the picture is specific. The overwhelming majority of it is browsing, it looks like browsing because it is happening inside a genuine browser, and only a thin slice reaches the page where money changes hands. Most of what you are deciding about is not a purchase attempt. It is research that may become one.
Why your current rules block it
Nobody sat down and chose to turn away shopping agents. The rules that do it were written for a different problem and they generalise badly.
Datacenter origin. Agent sessions frequently run from cloud infrastructure rather than a consumer connection, which puts them in exactly the address space most sites treat as suspicious. That heuristic was built for scrapers renting servers, and it does not distinguish between a scraper and a hosted assistant doing an errand. This is the same trap covered in detecting cloud and hosting IPs: the origin tells you where, never why.
Headless and automation markers. A driven browser leaves tells, and most stacks treat those tells as hostile by default.
Velocity. An agent comparing four sellers reads pages faster than a person does, so it trips rate limits built around human reading speed.
Challenges. An interactive challenge assumes a human is present to solve it. In agentic commerce there is a human present, just not at the keyboard, which is the case challenge flows handle worst.
Each of those was a reasonable rule when automation meant someone copying your catalogue. Then Cloudflare's September 15 defaults added an explicit Agent classification on top, blocked by default on ad-bearing pages for new customers, newly added sites, and free-plan accounts that did not change the setting. A crawler that mixes purposes without separating them gets handled by the most restrictive rule that applies to any of its behaviours.
The legal route just closed
Plenty of retailers assumed this would be settled in court instead. It was tested, and the answer went the other way.
Amazon sued Perplexity in November 2025 over its Comet browser, alleging among other things that the agent transmitted the same User-Agent string as Google Chrome rather than identifying itself. A district court granted a preliminary injunction on March 9, 2026. On August 4, 2026, the Ninth Circuit vacated it, holding that when a person directs the assistant to complete a task on Amazon.com, it is the user rather than Perplexity who accesses Amazon's computers, with the assistant functioning as a tool. The panel did not resolve the factual dispute about whether User-Agent strings were knowingly altered.
Two things follow. Computer-misuse statutes are a weak lever against an agent a customer asked to act, so the decision about who gets in is yours to enforce at the edge and in your terms. And the one case where a major retailer measured this in detail, the operator's own identifying string was the part under dispute. Which is the whole problem with identifying agents by what they call themselves.
Check which network a request actually came from
What separates an agent from an attacker
The signal everyone reaches for first is the one signal the client controls. A User-Agent is written by the sender, so it is a claim, not evidence, and the same is true of any header. What holds up is the set of properties that fall out of how the client is built rather than what it decided to say:
| Signal | Question it answers | Fails when |
|---|---|---|
| IP origin and ASN | What network is this, and who announces it? | The operator rents residential addresses |
| Published ranges, reverse DNS | Is this operator who it claims to be? | The operator publishes nothing to check against |
| JA4 TLS fingerprint | What stack opened this connection? | The client uses uTLS, or sits behind an inspecting proxy |
| Headless markers | Is a browser being driven? | The tooling patches its own tells |
| Session shape | Does the path through the site make sense? | The automation was built to imitate a person |
No single row decides anything. A hosting IP is not a verdict, and neither is a driven browser, because that describes both a shopping agent and a credential-stuffing run. Read across the rows and the ambiguity usually resolves: an agent from an operator that publishes its ranges, arriving at product pages, holding one session, is not the same event as an unverifiable datacenter address cycling through your login form. The full verification mechanics differ per operator and are worth getting right.
This is what Agentscan does in one call. It returns a class, human, known_bot,
ai_agent or malicious_automation, with a confidence value and the signals behind it, fusing
IP origin with headless tells, the JA4 fingerprint and a reverse-DNS-verified allowlist. Cached
verdicts come back in under 50ms, which is what lets the decision sit in a middleware hop instead
of a log review the next morning.
A policy that survives contact with real traffic
- Decide per route, not per site. The traffic split says most agent activity is on product and search pages and very little on checkout. Let agents read the catalogue, apply your real scrutiny to auth and payment, and you have matched the policy to where the risk actually sits.
- Separate the four questions. Is it automated, whose agent is it, is a logged-in person behind it, and what is it doing? A single allow-or-block switch collapses all four into one answer and gets three of them wrong.
- Never allowlist by name alone. Anything can send
ChatGPT-User. Allow by operator, then confirm the source address against what that operator publishes, or the allowlist becomes a free pass for whoever reads their documentation. - Check your Cloudflare setting deliberately. If you are on a free plan or added a site recently and have not touched the AI traffic controls, the September 15 defaults now apply to you. Whether that is right depends on whether you sell things, and the default does not know that.
- Log the class even when you allow it. Agent sessions that convert are worth finding on purpose. You cannot report on a segment you never labelled, and "how much revenue arrived through an agent" becomes an unanswerable question a quarter later.
Bottom line
Agentic commerce is not a crawler problem wearing a new name. A training crawler takes something from you, a search crawler trades citations for access, and an agent is a customer who showed up with software doing the clicking. Your existing rules cannot tell those apart because they were built to answer whether a session is automated, and that is no longer the question worth asking. The court route closed in August, the infrastructure default flipped today, and what is left is the part that was always going to matter: classify what the traffic is, decide per route what each class may do, and base both on signals the client does not get to write about itself.
FAQ