On August 4, 2026, the Ninth Circuit Court of Appeals overturned a preliminary injunction that had prevented the agent browser Perplexity Comet from accessing user accounts on Amazon since March. Formally, this is a dispute between two corporations regarding purchases made through AI. In reality, it is the first appellate decision addressing a question that extends far beyond agent commerce: who exactly "gains access" to another's server when a request is made by automation. Surprisingly, the court's answer hinged not on legal principles, but on network architecture.
What Happened: From Lawsuit to Lifting the Injunction
The timeline of the dispute is as follows:
- November 2025 — Amazon files a lawsuit against Perplexity AI, citing the federal Computer Fraud and Abuse Act (CFAA) and its California counterpart. The claim: the Comet agent logs into user accounts, views products, and initiates purchases, thereby operating in a password-protected area without authorization from the platform itself.
- Background — According to Amazon, the company warned Perplexity at least five times starting in November 2024, imposed a technical barrier in August 2025, and Perplexity released an update that bypassed it within a day. An additional complaint: the agent disguised itself as a regular Google Chrome session.
- March 9, 2026 — Judge Maxine Chesney (Northern District of California) issues a preliminary injunction and orders the destruction of data obtained from Amazon. Her reasoning: access was granted by the Amazon user, but without authorization from Amazon.
- August 4, 2026 — The Ninth Circuit (case No. 26-1444) lifts the injunction: Amazon is unlikely to win on the merits of the CFAA claims.
Amazon stated that it disagrees with the decision and will continue the dispute. Perplexity responded that it will defend users' right to choose any AI. The case has not disappeared; the trial court proceedings are ongoing, and Amazon may seek a review or escalate the matter.
Key Move: The Agent is a Tool, Not a Person
The CFAA penalizes access to a "protected computer" without authorization. The entire dispute boiled down to one verb: who performed the act of access. Amazon claimed it was Perplexity, as it was its agent acting on the platform. Perplexity countered that it was the user who commanded the agent.
The appellate court sided with the latter position and articulated it clearly: no matter how advanced the agent may be, for legal purposes, “it is a tool, not a person”. When a user instructs an agent to perform actions on Amazon.com, it is the user who accesses Amazon's computers.
This is a logical continuation of the Supreme Court's reasoning in the case of Van Buren v. United States (2021), which narrowed the CFAA: the law punishes unauthorized access to areas where access is completely prohibited, rather than for using legitimate access "for improper purposes." An Amazon user has an account and the right to access it. The tool they use to do so does not itself become a subject of hacking.
Why Traffic Architecture Made the Difference
The most interesting part of the decision for practitioners is the technical aspect. The court examined how Comet Assistant is physically structured, and this determined the outcome.
The operational scheme is as follows: the agent takes screenshots of the browser window on the user's machine, sends them to Perplexity's servers, and receives navigation instructions back to the user's computer, which executes the actions. Perplexity's servers do not communicate directly with Amazon's servers. All the traffic that Amazon sees comes from the user's device and IP address.
Hence, the court's conclusion. If the request physically originates from the user, then the "access" in terms of the CFAA was indeed performed by the user.
How This Differs from Power Ventures
Until now, the canonical case regarding third-party access with user consent was Facebook v. Power Ventures (2016). In that case, the court ruled that a platform could revoke access from a third-party service, even if users voluntarily provided their credentials. This precedent was relied upon by the trial judge, extending it to AI agents.
The Ninth Circuit distinguished these cases based on one criterion — and again, it was architectural. In Power Ventures, the defendant's systems directly sent messages to Facebook's platform, bypassing the user's machine. Perplexity does not have such a channel. Different traffic topology leads to a different answer to the question of "who gained access."
The practical significance of this distinction is hard to overstate. It means that the system design — whether a client agent on the user's device or a server-side service accessing the platform on its own — has ceased to be purely an engineering choice and has become a legal argument.
What the Decision Did NOT Do
The court made an effort to limit the scope of its ruling and explicitly stated that it does not create a new legal regime for agent AI. What remains outside the scope includes:
- Violation of user agreements. Claims arising from contracts, torts, and platform rules are not resolved by this decision — they can be pursued separately.
- Claims against users themselves. If access is performed by the user, then the platform can choose to address its claims against them.
- Server architectures. The conclusion is drawn under a specific scheme. A cloud scraper or SaaS agent that accesses the platform from its own infrastructure does not automatically fall under this logic.
- Technical blocks. Not a single word in the decision prohibits Amazon from detecting and cutting off automation. The right to block remains intact — what has disappeared is the ability to support blocking with criminal charges.
This, by the way, represents a shift in the usual picture: previously, the legal risk was on the one who automated, while technical protection was considered a second line. Now, for platforms, technical protection has become the first line.
What This Changes in Practice
For everyone collecting data, automating accounts, or building agents, the decision leads to three practical conclusions.
1. The Traffic Exit Point Has Legal Weight
Previously, the choice between "routing everything through our data center" and "operating from addresses indistinguishable from user ones" was a matter of feasibility and cost. Now it is also a question of whose action is considered the request. The architecture, where the request to the platform originates from the user side, has proven to be more defensible in court — and it historically fares better against anti-bot filters. This is a rare case where legal and technical incentives align and point in the same direction: towards residential proxies and user exit points instead of server subnets. For neutral tasks like monitoring public prices or checking search results by regions, data center proxies are still sufficient — there is no logged-in area or dispute over anyone's account.
2. CFAA Has Weakened — Contracts and Detection Have Strengthened
Do not read the decision as "now it's allowed." The heaviest weapon — the federal statute with criminal potential — has been removed. What remains are user agreements, account blocking, civil lawsuits, and, importantly, the anti-bot stack. Platforms, having lost some legal leverage, will compensate for it with detection: fingerprinting, behavioral analysis, and signed agents. We discussed how the industry is trying to legalize "good" bots through technical means in our article about Web Bot Auth and signed agents.
3. Risk Has Shifted to the End User
The flip side of Perplexity's victory: if the user acts, then the user is responsible. For services that provide automation to clients as a product, this is a reason to clearly state in documentation whose name and IP the actions are performed under and which platform rules are affected.
What to Do Right Now
- Describe your access topology. Answer one question: whose IP does the target platform see in the logs — your server's or the user's? This affects both the legal position and the detection profile.
- Separate public and logged-in. Collecting open pages and performing actions within someone else's account are fundamentally different stories in terms of risk. Mixing them in one pipeline is not advisable.
- Do not aggressively mask after a direct ban. In this case, it was the circumvention of the imposed barrier and the impersonation of the client as Chrome that provided Amazon with the strongest evidence. The CFAA claim fell apart, but other grounds remain.
- Choose the type of exit based on the task. We thoroughly discussed the practical side — how to deploy an agent on Playwright or MCP and correctly route its traffic — in our guide to proxies for AI agents.
Conclusion
The Ninth Circuit did not legalize automation or grant agents access anywhere. It made a narrower but more significant move: it tied the concept of "access" to where the request physically originates. A tool operating on the user's machine does not perform access — the person does. Infrastructure that accesses the platform on its own remains within the realm of old risks.
For the market, this means a shift in the center of gravity. Legal disputes over "whether it is allowed" will increasingly hinge on the engineering question of "whose address is in the log." The struggle for access has definitively moved back to where it has always been — into anti-bot detection, fingerprinting, and the quality of exit points.