eBay Banned Shopping Agents. The Consent War Is Just Starting.
A marketplace can block an agent from buying. It cannot block customers from wanting delegated commerce. The next fight is over how that authority becomes visible and provable.
A purchase needs more than a click.
In early 2026, eBay's User Agreement began prohibiting unauthorized third-party AI-powered autonomous tools from buying on its marketplace. That does not end agentic commerce. It sets the real question: whose agent may act, under whose rules, and with what proof?
The practical distinction
Autonomy without a record is a dispute waiting to happen.
A useful consent system has to show a scope, a limit, a revocation path, and an auditable trail. A terms-of-service checkbox cannot do that work alone.
What eBay actually did
eBay's policy is not a blanket rejection of AI. It is a boundary around AI it does not control. The agreement prohibits unauthorized outside tools from making purchases, including buy-for-me agents. The distinction matters because a platform can welcome automation inside its own environment while blocking an independent representative acting for the same customer.
The policy is also a liability decision. Digital commerce disputes were designed around an observable human action: a person logs in, sees a cart, and confirms a purchase. When an agent acts, the record must answer different questions. What did the user authorize? What limits were set? Did the agent act within them? Could the customer revoke the authority? Without those facts, a chargeback, account-takeover claim, or customer-service dispute becomes an expensive reconstruction.
There is a real customer-experience angle here too. A human who delegates shopping does not want a constant stream of prompts, yet they also do not want to discover that an assistant chose a substitute, exceeded a budget, or used a seller they would have rejected. The hard part is not showing a confirmation dialog. It is deciding which choices can be delegated in advance and proving that the eventual transaction remained inside those boundaries.
That explains why eBay's position is commercially rational even if its long-term form changes. It is cheaper to reject an external agent than to be the referee for ambiguous authority at marketplace scale. A platform can preserve the option to launch a first-party agent later, on terms it can monitor and defend.
The fight is over who owns the agent.
Amazon's dispute with Perplexity supplies the live test. Amazon sued over the Comet browser agent's access to its shopping experience. The district-court fight produced a preliminary injunction in March, a temporary pause in the restriction while the case continued, and an appeal that was still active by August. The Ninth Circuit record shows the issue remains contested, not settled.
The important point is not to predict the winner. It is to see what the lawsuit exposes: a shopper may believe their chosen agent is acting as their representative, while the platform may see an unaffiliated automation system that bypasses controls, changes the shopping surface, and creates data-risk questions. That is a power dispute as much as a technical one.
A ban is the fortress answer. It protects the platform's evidence trail and keeps control of the commercial surface. The alternative is not open access without rules. It is a verifiable delegation model that a merchant, processor, platform, and customer can all inspect.
That model changes the product question. Instead of asking only whether an agent can complete checkout, a platform must define a partner path. Who can register an agent? Which identity signals count? What activity rate triggers a review? What happens when the agent makes a purchase the customer says they did not approve? Those are operating rules, not a future legal memo. The company that makes them explicit can offer a measured form of autonomy. The company that leaves them implicit will either block useful activity or absorb disputes it cannot explain.
For adjacent merchant-liability work, see the related agentic commerce authorization analysis. The two issues overlap, but they are not identical: this story is about platform access and consent infrastructure; merchant programs still need their own risk design.
Consent rails are arriving, but they are not a free pass.
Intent mandate
A customer gives an agent a scoped job: find an item, stay under a price, follow conditions.
Cart mandate
The exact cart and amount are bound to an approval when a person is present.
Payment evidence
The payment is tied to the verified instruction and resulting cart, leaving a record for a later dispute.
Google's Agent Payments Protocol describes signed verifiable mandates as transaction evidence, from intent through cart and payment. Mastercard's Verifiable Intent frames the same gap from the network side: consumers need to know instructions were followed; merchants and issuers need facts rather than guesswork.
Those systems reduce ambiguity. They do not automatically grant a third-party agent permission to access a particular marketplace. That is why standards and platform policy are moving together, often uneasily. The protocols are best read as a common language for authority: a way to state what was intended, what changed, and which party can verify it after the moment has passed.
For merchants, the test is practical. If an agent says it had permission to buy, can the merchant retrieve the mandate without asking the agent to explain itself? Can support see the cap, exclusions, and expiry? Can the customer inspect and cancel a standing instruction? A protocol earns its place when it reduces the amount of trust a dispute requires.
The operating model is the real product decision.
Merchant teams should not treat “allow agents” as one switch. An agent that researches publicly available catalog information is different from one that signs into an account, builds a cart, changes a delivery address, applies a payment credential, or places an order. Each step increases the evidence a platform needs and the harm caused if that evidence is weak. The useful policy is granular: define which tasks are discoverable, which require a recognized partner, which need a customer checkpoint, and which are off limits until a credible record exists.
That granularity also protects the customer. A good delegated-shopping experience makes the boundaries visible before money moves. A shopper can allow an agent to search several stores, limit the budget to a stated amount, prohibit substitutions, or require a final approval when a delivery window changes. If the system cannot state those boundaries in plain language, it has not earned the right to make a purchase quietly in the background.
The same discipline helps support and risk teams. When a customer asks why an order happened, the answer cannot be “the AI decided.” The answer must connect the agent identity, the instruction, the catalog state, the cart, the checkout event, and the final order. That chain makes disputes faster to resolve. It also tells a merchant which agent behavior is valuable enough to support, rather than treating every automation request as an unknown threat.
There is a commercial upside as well. Platforms that publish a narrow, trustworthy path for verified agents can invite innovation without surrendering their storefront. They can measure who uses the path, observe conversion and error rates, and improve it with real evidence. A blanket ban may be the right temporary control, but it is not a strategy for a market where customers increasingly expect software to do more of the tedious work on their behalf.
What merchants should decide now
Choose a posture per channel
Block unknown agents, require confirmation, accept verified delegation, or permit a narrowly defined closed loop. The dangerous option is an accidental posture created by mismatched checkout behavior and policy.
Make consent readable
Put category, budget, timing, and cancellation terms in a screen a customer can understand. Consent that survives a dispute is not buried in a lengthy agreement.
Retain decision evidence
Record what was authorized, what data the agent received, what it did, and what the customer saw. A durable record is more useful than a retrospective explanation.
Monitor the rails
AP2, payment-network verification, and checkout protocols are signals to watch. They may become the practical way a platform distinguishes a delegated purchase from untrusted automation.
Start with one concrete journey, not an abstract AI policy. Trace a grocery reorder, a replacement part, or a recurring household purchase from the moment the customer delegates it through payment, fulfilment, and support. The missing evidence will show up quickly. It may be an unrecorded price ceiling, a vague substitute rule, or a checkout that cannot explain whether the shopper saw the final total.
Then decide the failure mode in advance. If the agent cannot produce a valid instruction, should it stop, ask a question, save a draft cart, or hand the task back to the customer? A safe fallback is part of the experience. So is a clear support path that lets a person reverse the wrong outcome without forcing them to understand the whole agent stack.
This is not a call to turn checkout into a compliance maze. It is a call to make invisible authority legible at the moments that matter. The right design keeps routine work quiet, makes consequential changes obvious, and leaves enough evidence behind to protect both the customer and the merchant.
There are questions that no protocol can decide for a business. Does an agent get a lower or higher support priority than its human principal? Can it use a membership benefit? May it negotiate a refund, exchange, or delivery address on the customer's behalf? Those choices belong in product, operations, and policy together. Treating them as isolated fraud controls is how organizations create loopholes between the experience they promise and the evidence they can actually produce.
The most durable approach is to run a contained pilot, measure the failure modes, and publish the boundary before the volume arrives. Invite a small group of recognized agents or customers, audit the customer instructions and support outcomes, then expand only when the record is strong enough to defend. The goal is neither frictionless autonomy nor permanent restriction. It is a commerce system that can move quickly without asking people to take its word for what happened.
FAQs
Did eBay ban AI from its marketplace?+
No. The relevant 2026 policy change targets unauthorized third-party autonomous purchase tools. It is a rule about who may transact through the marketplace and under what authority, not a blanket rejection of AI.
Why is consent difficult in agentic commerce?+
A real record must capture who delegated authority, what could be purchased, the constraints, the resulting cart, and a way to review or revoke the instruction. A click alone cannot answer those questions after a dispute.
Can payment protocols solve platform access?+
No. Payment protocols can make authority more inspectable, but each marketplace can still set its own access and partner rules. Verifiable intent is evidence, not automatic permission.
What should a merchant do first?+
Map agent tasks by risk: discovery, account access, cart construction, payment, and post-purchase changes. Then decide which tasks are allowed, which need a recognized partner or confirmation, and which remain blocked.
Agentic commerce will belong to whoever makes a customer's authority provable.