Perplexity Beat Amazon Because of Where Its Code Runs

Surya Pratap
By Surya Pratap

August 9, 2026

10 min read

AI & Technology
Breakdown of the Ninth Circuit's Perplexity ruling: the client-side architecture that decided the case on the left, the claims that survive it on the right

On August 4, a unanimous Ninth Circuit panel vacated the preliminary injunction that had kept Perplexity's Comet browser and shopping assistant off Amazon.com. The holding: under the Computer Fraud and Abuse Act, an AI agent is a tool, not a person. When a user points an agent at a website, it is the user who accesses it.

That is being read this week as a green light for agentic commerce. It is not, and the gap between what the court said and what people think it said is where founders will get hurt. The more useful thing in the opinion is narrower and more actionable: the fact that decided the case was architectural. Perplexity won partly on how it built Comet.

The fact that decided it

Comet does not work the way most people assume an AI shopping agent works. Perplexity's servers never talk to Amazon's servers. The Assistant takes a screenshot of the page on the user's own machine, sends that image to Perplexity for processing, and gets back navigation instructions that the user's computer then executes. Every packet that reaches Amazon comes from the user's device, over the user's connection, in the user's session.

The court's reasoning follows directly from that. “Access” under the CFAA means entering a computer system, and the statute contemplates access by a person. The agent is instrumentality — the panel wrote that it is “a tool, not a person for statutory purposes,” and that “the focus of the inquiry is still on the person accessing or causing the access.” So it was the user who accessed Amazon, with the help of Perplexity's agent.

The panel reinforced this with the rule of lenity. The CFAA is a criminal statute. If Amazon's theory were right — that the agent's operator is the one accessing — the same logic would expose ordinary people to criminal liability for using an AI assistant to buy something. Courts avoid readings of criminal statutes that sweep that broadly, and this one did.

Why this should change how you read your own architecture diagram

Client-side versus server-side execution has always been a decision about latency, cost, and where credentials live. As of August 4 it is also a decision about your legal posture. The Ninth Circuit's analysis rests on the absence of server-to-server communication. An agent whose backend fetches the page itself is not obviously covered by this reasoning, and the court did not say it was.

What the ruling did not do

The panel was unusually explicit about its own limits: “We do not establish a new legal regime governing agentic AI.” Take that literally. Five things did not change.

  • Terms of service still bind. The court addressed anti-hacking statutes and expressly left contract claims open. If a site's terms prohibit automated access, that prohibition is as enforceable today as it was last month. This is now the main battlefield, not a footnote.
  • Tort theories survive. The opinion left them open by name. Interference with contractual relations, unfair competition and related claims were not touched.
  • This is a preliminary injunction ruling. The standard is likelihood of success, not final merits. The case goes back down and Amazon continues litigating.
  • It binds one circuit. The Ninth Circuit covers California and the West Coast, which is where a lot of this industry sits — but it is not national law, and another circuit can disagree.
  • Autonomy was not tested. The reasoning turns on a user directing a tool in the moment. An agent running unattended on a schedule, taking actions no human specifically initiated, is a materially different fact pattern that this opinion does not resolve.

The consequence nobody is celebrating

Here is the part that should concern you more than the win reassures you.

If anti-hacking law no longer reaches the agent's operator, platforms will move the fight to contract. That is the obvious response and Eric Goldman has already flagged where it leads: sites tighten their terms to prohibit agent-assisted access, and the person bound by those terms is the account holder. Your user.

Read the logic of the win again and you can see the trap inside it. The court held that your user is the one accessing the site. That is exactly the premise a platform needs to argue your user is the one in breach — and to suspend their account rather than sue you. You escape liability by successfully arguing that your customer is the actor. Winning that argument twice is not obviously good for your product.

So the realistic near-term future is not open agent access. It is a mix of tightened terms, more aggressive bot detection, and account-level enforcement against end users — with a legal question resolved in the agent industry's favour sitting underneath it, doing less work than the headlines suggest.

What to do if you are building agents that touch other people's sites

  • Know where your requests originate, precisely. Draw the actual packet path for every third-party interaction: user device, your backend, or a headless browser in your cloud. If the answer is “our backend fetches it,” you are outside the architecture this ruling blessed. That may still be the right engineering call — just make it knowingly, not by default.
  • Read the terms of the sites you depend on. This is now the live constraint, and it is one you can actually check. If your product's core loop requires an interaction a major platform's terms prohibit, you have a business risk that no court ruling fixes.
  • Do not let your users be surprised by what they are agreeing to. If a platform can plausibly treat agent use as a breach by the account holder, your users are carrying a risk on your behalf. Say so plainly, keep the agent's actions visible and reviewable, and never take an account-level action the user did not understand they were authorising.
  • Treat credential handling as the thing that gets you sued. Amazon's complaint alleged the agent covertly accessed password-protected accounts. The CFAA claim failed on who accessed, not on whether the credential handling was defensible. Keep credentials on the user's device or in a vault the user controls, and never in a place where you would struggle to explain the design to a regulator.
  • Do not build a moat out of undetectability. If your advantage is that a platform cannot tell your agent from a human, you are one detection upgrade away from a dead product. Bot detection is going to get more aggressive precisely because the legal route narrowed.
  • Prefer sanctioned paths where they exist. An API, a partnership, or an affiliate programme is a worse product experience and a much better business. The agent-versus-website fight is worth avoiding entirely when someone offers you a door.

The strategic read

I am not a lawyer and none of this is legal advice — if agent access to third-party platforms is load-bearing for your product, that is a conversation to have with counsel, not with a blog post. What I can offer is the engineering observation, and it is the one worth carrying.

A systems-design choice made for latency and credential-handling reasons turned out to determine the outcome of a federal appeal. Perplexity almost certainly did not build Comet client-side in order to win a CFAA case. It built it that way because screenshotting locally is a sensible way to operate inside a user's authenticated session, and the legal benefit fell out of it.

That is the pattern to internalise. This has been the week for it: on Friday, a chip company betting that where a model physically lives changes its economics; today, a court finding that where an agent physically runs changes who is legally acting. In both cases the boundary that mattered was a deployment boundary, not a product decision. As agents start doing things with real-world consequences — spending money, signing up, sending mail, holding credentials — the question “whose computer is this running on?” stops being an implementation detail and starts being one of the load-bearing facts about your company.

Share this post :

Related Posts

Your AI Agent Has a Security Problem: A Founder's Security Guide for 2026July 17, 2026
AI Agents Need Permission Systems, Not Better Prompts — A Founder’s GuideJuly 14, 2026
OpenClaw and the Agentic OS Shift: What Founders Should Learn Before Building Their MVPMarch 2026