If your AI commerce plan assumes an assistant can find a product, sign in and complete the purchase, the Perplexity-Amazon dispute exposes a flaw in that model: discovery, account access and transaction authority are separate permissions.
A preliminary injunction now prevents Perplexity’s Comet agent from entering Amazon’s password-protected areas and requires Perplexity to delete the Amazon data it collected. That does not end AI shopping, but it gives SEO, ecommerce and agent teams a practical warning: being visible to an AI system does not give that system permission to act inside a platform.
The injunction targets authenticated access, not all AI shopping
The scope matters. U.S. District Judge Maxine Chesney issued a preliminary injunction concerning Comet’s access to password-protected parts of Amazon, including areas used by Prime members. It is not a final judgment declaring every AI shopping agent unlawful, nor does it establish that public product pages cannot be found, interpreted or recommended by AI systems.
The central distinction is between two kinds of authorization. A customer may authorize an assistant to use the customer’s account, but the platform may still withhold authorization from the assistant itself. The judge cited strong evidence that users granted Comet access while Amazon did not. For anyone building an agent, user consent is therefore necessary but may not be sufficient.
Amazon has accused Perplexity of computer fraud and unauthorized access, including allegedly allowing Comet to make purchases without identifying itself properly as a bot. Those are Amazon’s allegations, not settled findings on every claim. At issuance, the injunction was suspended for one week so Perplexity could appeal.
The deletion requirement deserves as much attention as the access restriction. An agent team may need to identify and remove data by platform, account, user and collection method. If you cannot isolate data at that level, a dispute over one integration can turn into a much larger data-governance problem.
Discovery, recommendation and purchase are separate systems
AI commerce is often discussed as one continuous journey, but three layers determine whether it works. Each has a different owner, failure mode and remedy.
| Layer | Question it answers | Typical responsibility | Common failure |
|---|---|---|---|
| Visibility | Can an AI system find and understand the product? | SEO, content, structured data and public-site engineering | The product is absent, misunderstood or cited inaccurately |
| Recommendation | Does the product fit the user’s request well enough to be selected? | Product information, positioning, availability and the agent’s decision logic | The product is understood but not chosen |
| Execution | Can the agent enter an account, modify a cart or complete a purchase? | Authentication, platform policy, security, legal review and approved integrations | The journey stops at sign-in, checkout or another protected action |
Schema markup can improve machine understanding at the visibility layer. Clear product details can strengthen the recommendation layer. Neither one grants an agent access to an authenticated account. Treating them as substitutes for platform permission creates a false sense of readiness.
The same distinction applies to robots.txt and other crawl controls. A public crawling directive is not a purchasing authorization system. It does not answer whether an agent may use a signed-in session, accept terms, place an order or retain account data. Those questions need explicit product, security and legal decisions.
Your SEO work still matters, but it cannot grant access
The wrong reaction would be to stop optimizing products for AI discovery. The injunction concerns authenticated access, while much of the discovery and evaluation journey happens through public information. Your content can still help an assistant understand what a product is, who it suits and where the customer can continue safely.
- Give each important product a stable public destination. Use a consistent canonical URL and make variant handling predictable so an agent does not have to reconcile several conflicting versions of the same offer.
- Put decision-critical facts in accessible page text. Product names, identifiers, specifications, compatibility, options, limitations and fulfillment conditions should not exist only inside images or interface states that require interaction.
- Keep structured data aligned with the visible page. Markup that contradicts the page can produce incorrect extraction and erode trust. Treat structured data as a machine-readable representation of the offer, not a place to publish claims the customer cannot verify.
- Separate product availability from transaction capability. An agent may be able to report that an item appears available without being authorized to buy it. Use language and interfaces that do not blur those two states.
- Provide a durable human handoff. If automated checkout is unavailable, preserve the selected product or variant in a public deep link and let the customer sign in, review the cart and confirm the purchase.
- Publish an approved path for automation if you offer one. Document the permitted integration, identity requirements, data limits and prohibited actions. Do not force agent developers to infer transactional permission from crawlability.
Measure these layers separately as well. AI referrals and product-page visibility tell you about discovery. Product selection or cart initiation tells you about consideration. Completed orders tell you about execution. Combining all three into a single “AI traffic” measure hides the exact permission gate where the journey fails.
Audit the handoff before an agent reaches login
You do not need to wait for another court dispute to find the weak point in your own workflow. Trace one high-value purchasing journey from the first public result through order confirmation, then record the identity, permission and data rules at every transition.
- Mark every access boundary. Label which pages and actions are public, account-gated, membership-gated or restricted to an approved integration. Include cart changes, saved payment methods, order history and purchase confirmation.
- Name the permission owner. Record whether the customer, merchant, marketplace, payment provider or another party controls each action. If two parties must consent, capture both rather than treating the customer’s approval as universal authorization.
- Define agent identity. Decide how an automated system identifies itself and how your service distinguishes it from the human account holder. Do not rely on the fact that the agent is operating through a customer’s browser session.
- Minimize retained data. Keep only what the approved workflow needs, attach provenance to it and make deletion possible by source and account. The Amazon data-deletion requirement shows why broad, unlabelled data stores create operational exposure.
- Design a graceful stop. When the next action is not authorized, the agent should explain the boundary, preserve useful context and return control to the customer. It should not repeatedly retry, conceal its identity or route around the restriction.
- Test the fallback as a primary path. Confirm that the customer lands on the correct product and variant, can see what remains to be reviewed and can complete the protected steps without rebuilding the transaction.
If your agent enters authenticated services or makes purchases, do not attempt to evade a platform block or disguise automated traffic. That can increase contractual, security and legal exposure. Have qualified counsel review the relevant terms, authorization model and data practices before launch; this dispute is too narrow and preliminary to serve as a universal legal rule for another platform or implementation.
Key takeaways for AI commerce teams
- A user’s permission to use an account does not necessarily provide the platform’s permission for an agent to access it.
- The injunction is specific to Perplexity’s Comet agent and password-protected Amazon areas; it is not a general ban on AI product discovery or shopping assistance.
- SEO, AEO and structured data improve visibility and understanding, but they do not authorize account access or transactions.
- A useful agent-ready journey needs both a machine-readable discovery layer and an explicitly permitted execution path.
- When full automation is unavailable, a precise human handoff is better than an agent that fails silently at login or checkout.
- Data provenance and targeted deletion are core integration requirements, not cleanup tasks to invent after a dispute begins.
Your next move should be concrete: diagram one purchasing journey, circle every point where the agent crosses from public information into protected action, and assign an owner to each permission. Keep optimizing the public layer for discovery, but do not describe the journey as agent-ready until the authenticated steps have an approved path or a tested human handoff.
