The URL still says fraud and security. The previous article on this slug had drifted into a generic list of operations AI can automate. That work lives elsewhere. This page stays in its historical territory — with a problem the old fraud stack was not designed for.
Shopping assistants already research and refer. Protocols exist so agents can check out. Procurement tools will place routine orders. At the same time, attackers use generation for synthetic identities, stolen-credential stuffing, and traffic that looks like a helpful bot.
To the edge of a website, a legitimate buying agent and a hostile script can look similar: automated, persistent, not a person with a mouse. Rules written to block "bots" will hit both. Rules written to welcome "AI traffic" will hit both.
IBM's overview of agentic commerce names the trust barrier directly: consumers already worry about privacy, data misuse, and unsolicited marketing, and some still prefer to complete transactions themselves. That hesitation is rational if the merchant cannot tell who — or what — is on the other side of the order.
Two Machines, One Perimeter
Yesterday's model was human checkout plus fraud filters plus bot mitigation. Humans were the buyers. Automation was the threat, or at best a scraper.
The new model has to hold three cases at once:
- a person buying
- software buying on a person's or company's authority
- software attacking
The cost of fraud prevention is often the revenue you block is the human-checkout problem: false positives, review queues, insulted customers. This article is identity for the non-human case.
Authorizing an agent is not the same as allow-listing user-agents. It is knowing which principal the software represents, what it may see (especially contract price), what it may purchase, in what amount, and how that mandate is logged. Payment networks and agent-commerce protocols are circling delegated credentials and audit for that reason. The merchant still has to bind those credentials to account, catalog, and policy in their own systems. A token from a wallet is not a customer master. Map it or refuse the order.
If you cannot bind them, you have two bad options: treat all automation as fraud, and lose good agent demand; or treat all automation as a customer, and let attackers wear the same costume.
Procurement agents inside a known account are the easier case: they inherit login, contract, and credit. Consumer shopping agents arriving from a third-party assistant are the harder case: the mandate may be a token you did not issue. Do not use the same control for both. The first is an extension of B2B identity. The second is a new principal at the edge.
What Has to Be True Before You Open Agent Checkout
Identity of the buyer behind the agent — person or company — has to survive the handoff. Permissions have to be explicit: browse, quote, place under a limit, never see another account's price. Inventory and price have to be the authorized ones, or an agent will commit you to a deal operations cannot ship. An audit trail has to exist for the same reasons finance already wants one for a sales rep: who asked, what was allowed, what was done.
What agentic commerce means for manufacturers and distributors is why industrial catalogs will be queried by machines. Security is the counterpart: machines that query must be governed, not merely detected.
Fraud teams will still need behavioral and graph tools for attacks. Those tools have to stop using "automation" as a synonym for "guilty." The signal is mandate and reputation, not whether a browser was involved.
Rate limits, device graphs, and velocity rules remain useful against card testing. They should sit behind a classification: human session, known-account automation, unknown-agent, abuse. Unknown-agent without a verifiable mandate is not a customer. Known-account automation without a limit is a blank check.
Arizon Digital's Agentic Commerce Readiness Index includes trust, governance, and agent interfaces because this is a capability, not a plugin. You do not get it by turning off bot management. You get it by deciding what a non-human buyer is allowed to do, then enforcing it the way you already enforce credit and price.
Price and Catalog Leak Through the Same Door
An agent that can buy can often see. Customer-specific price, hidden assortment, and credit limits are the jewels. If the agent interface is a scrape of the storefront, you have published the account. Bind views to the same entitlements as the logged-in buyer. B2B is not a storefront with a login; agent access is that login problem with a machine holding the session.
Logging is not optional theater. When a dispute arrives — "we did not order that" — you need the mandate, the actor, and the SKU list. Human checkout already struggles without that. Agent checkout without it is indefensible.
Do Not Confuse Referral Traffic With a Mandate
AI-referred human shoppers are not agents with wallets. They are people who did research somewhere else. They still need ordinary fraud controls — and they still get insulted by crude bot rules that trip on unusual devices and VPN paths.
True agent checkout is a later, narrower door. Open it on purpose, with identity, limits, and logging. Until then, the security work is distinguishing research traffic, human checkout, and abuse, without collapsing all three into one "AI" bucket.
Incident response has to include a machine-buyer playbook: how to revoke a mandate, how to freeze an integration without killing the human site, whom to call at the assistant platform. If the only play is "block the user-agent," you will take down good demand during an attack.
Leadership should ask a sharper question than "are we ready for agentic commerce?" Ask: if software placed this order tonight, could we prove whom it represented, what it was allowed to buy, and whether we should have said yes? If not, do not open the door. Tighten the human path first, then design the machine one. Both are security. They are not the same control.
Write the policy in language operations can enforce: named accounts may automate replenishment under a dollar cap; unknown assistants may research and refer but not pay; abuse is blocked. Then map each clause to a control. Policy without a control is a blog post. A control without a policy is a false positive factory with a new name.