TL;DR: On August 4, 2026, the Ninth Circuit vacated a preliminary injunction that had blocked Perplexity's Comet browser from acting on customers' Amazon accounts. The panel held that when a user directs an AI agent to take an action on a site the user is already logged into, it is the user who "accesses" that site under the Computer Fraud and Abuse Act, not the AI company. The ruling narrows CFAA exposure for AI agent makers, but Amazon's trademark and breach-of-contract claims survive and go back to district court. Here is what actually changed, what did not, and what to check in your own AI agent policy this week.
What happened on August 4
If your team uses an AI browser agent, one that logs into vendor portals, fills out forms, or manages a subscription on your behalf, a federal appeals court just answered a question that has been open since these tools shipped: when the agent acts, who is legally the one doing the accessing?
The Ninth Circuit's answer, in a case between Amazon and Perplexity, is that it is the human user, not the AI company. That single distinction is why the court lifted an injunction that had barred Perplexity's Comet browser from operating on Amazon.com, and it is the part of the ruling every small team running an AI agent against a third-party site needs to understand, because it changes where legal risk actually sits.
The case, in order
Amazon sued Perplexity in November 2025, alleging that Comet's built-in AI agent, sometimes called the Assistant, covertly accessed password-protected customer accounts on Amazon.com to complete purchases and manage orders, exposing users to security risk and violating both the federal Computer Fraud and Abuse Act (CFAA) and California's Comprehensive Computer Data Access and Fraud Act (CDAFA). Amazon argued that Perplexity's access was not authorized, regardless of whether the individual Amazon customer had given Comet permission to act on their own account.
On March 9, 2026, U.S. District Judge Maxine M. Chesney in the Northern District of California agreed with Amazon and granted a preliminary injunction, finding Amazon was likely to succeed on the merits of its CFAA and CDAFA claims. Perplexity appealed.
On August 4, 2026, a Ninth Circuit panel, in an opinion authored by Circuit Judge Milan D. Smith Jr., vacated that injunction. The core holding, in the panel's own words: "it is the user who 'accessed' Amazon's computers, not Perplexity." The court also wrote that "however advanced the Assistant currently is, it is a tool, not a person for statutory purposes," and applied the rule of lenity, the legal principle that ambiguous statutory language should be read against the party seeking liability, to resolve the CFAA's silence on how autonomous software fits its access requirement.
The panel was explicit that it was treading new ground. It noted there is "little to no existing caselaw directly dealing with how to ascribe responsibility for AI agents" under the CFAA, and it described its own holding as narrow. The case now returns to the district court, where Amazon's trademark claims and breach-of-contract theories, which do not depend on proving unauthorized computer access, remain alive.
Why "the user accessed it" is the whole ballgame
The CFAA and its California counterpart, CDAFA, are anti-hacking statutes. Both require proof that someone accessed a protected computer without authorization. Before this ruling, the open question was whether an AI agent acting on a user's behalf should be treated as a distinct legal actor accessing the target site itself, in which case the agent's maker could be on the hook, or as an extension of the user, in which case the user's own login credentials do the authorizing.
Amazon's theory in the district court was closer to the first view: Comet's Assistant was accessing Amazon's servers in a way Amazon itself had not sanctioned, independent of whether the underlying Amazon customer wanted it to. The Ninth Circuit rejected that framing on the facts before it. Comet's Assistant, according to the record described in press coverage of the opinion, worked by taking screenshots of what the user's own browser displayed and sending navigation instructions back, rather than contacting Amazon's servers directly on its own initiative. Because the human user's browser was the thing actually talking to Amazon, the panel concluded the user was the one accessing Amazon's systems, and Perplexity's software was simply carrying out the user's own authorized session.
That distinction, agent-as-tool versus agent-as-independent-accessor, is the mechanism the whole ruling turns on. It is also exactly the distinction that will matter in the next case, because not every AI agent architecture works the way Comet's did in 2026.
What this means if your team runs an AI agent
Most small teams are not going to get sued under the CFAA. That was already true before this ruling and it remains true after it. What changed is the legal theory a vendor like Amazon can use against an AI agent maker, and by extension, what legal theory is realistically available against your own team if a vendor decides your AI agent's activity on their site crossed a line.
Here is the practical shift. Before this ruling, a company on the receiving end of unwanted AI agent traffic had a plausible anti-hacking claim against the agent's maker, the theory Amazon tried and lost on appeal. After this ruling, at least within the Ninth Circuit, that theory is much harder to win on when the agent is working through a user's own authenticated session rather than contacting the target site directly. Anti-hacking statutes are, for now, a weaker tool against this category of AI agent behavior than many vendors assumed.
That does not mean the underlying conduct became risk-free. It means the fight over "was this OK" is more likely to happen on contract and terms-of-service ground instead of anti-hacking ground. Nearly every SaaS platform, vendor portal, and e-commerce site your AI agent might touch has a terms-of-service clause addressing automated access, bots, or scraping. Those clauses were not at issue in the CFAA holding, and the panel's opinion did not disturb them. If your team's AI agent violates a vendor's terms of service while acting on your account, "the AI did it, not us" is not a defense to a breach-of-contract claim the way it may now be to a CFAA claim.
For a small team, this narrows the question you need to ask before deploying an AI agent against a third-party account from "could we get accused of hacking" to a more mundane but more likely question: "does this vendor's terms of service actually permit automated or agent-directed access to our own account." That is a contract question, not a criminal-hacking question, and it is one your own vendor agreements already control.
What did not change
Three things are worth being precise about, because it is easy to over-read a ruling like this.
First, the holding is narrow and fact-specific. The panel repeatedly emphasized that its reasoning turned on how Comet's Assistant was architected, working through the user's own browser session rather than contacting Amazon's servers independently. An AI agent built differently, one that authenticates directly to a third-party API using stored credentials rather than driving a user's live browser session, is not automatically covered by this same reasoning, and the court said as much when it flagged that agentic AI law "will doubtless change" as more cases reach it.
Second, this is Ninth Circuit precedent only. It binds federal courts in California and eight other Western states. No other federal appeals court has ruled on how the CFAA applies to AI agents, and a different circuit could reach a different conclusion on similar facts. If your organization operates primarily outside the Ninth Circuit's footprint, treat this ruling as a strong data point and an early signal, not settled national law.
Third, and most important for a governance policy, Amazon's non-hacking claims are still very much alive. Trademark claims and breach-of-contract theories survive and return to the district court. The court's reasoning was specific to the CFAA's "access" element; it did not hold that AI agents are immune from liability generally, and it did not touch the enforceability of a site's terms of service against the account holder who deployed the agent.
Five things to check in your AI agent policy this week
1. Pull the terms of service for every vendor account your AI agent touches. Focus on any clause addressing automated access, bots, scraping, or third-party tools acting on the account holder's behalf. Most enterprise SaaS terms already have language here. Consumer-facing sites vary widely.
2. Do not treat "the AI agent did it" as a liability shield. This ruling narrows one specific federal anti-hacking theory against AI agent makers. It says nothing about your own company's exposure under a contract you signed or clicked through. If your AI agent violates a vendor's terms while using your account, you are the party who agreed to those terms.
3. Separate agent architecture from agent behavior when you evaluate a new tool. Ask whether the agent operates through your team's own already-authenticated browser session, closer to the Comet model this ruling addressed, or whether it authenticates independently to third-party systems using stored credentials, a pattern this ruling did not squarely resolve. See our agentic AI vendor contract clauses guide for the specific contract language to ask vendors for on this point.
4. Update your acceptable use policy to require a terms-of-service check before pointing an agent at a new vendor account. This is a five-minute step that most teams currently skip entirely. Our AI browser agent governance policy for small teams has a full rollout template if you do not have one yet.
5. Log what your AI agents do, and when. If a vendor ever challenges your account's activity, whether framed as a CFAA claim, a breach-of-contract claim, or a terms-of-service dispute, having a record of what your agent was instructed to do and when it acted is the difference between a quick resolution and a drawn-out dispute. Our agentic AI liability guide covers what a defensible logging setup looks like for a team without a dedicated security function.
The bigger picture
Agentic AI shipped faster than the law meant to govern it, and this case is the clearest evidence yet of that gap closing in real time. A federal appeals court just wrote, in a published opinion, that there is "little to no existing caselaw" on how to assign responsibility when software acts for a person rather than a person acting directly. That sentence describes the exact governance problem every small team adopting AI agents has been operating inside without a clear answer, and it is not fully resolved by this ruling either. It is one data point in an area the court itself expects to keep changing.
What is settled, for now and at least in the Ninth Circuit, is that anti-hacking statutes are a weaker tool against AI-agent activity conducted through a user's own authenticated session than many companies assumed a year ago. What is not settled, and what your own vendor contracts already govern regardless of how this case turns out, is whether your AI agent's activity on a third-party site complies with that site's terms of service. That is the question worth answering this week, while the ruling is fresh and before a vendor asks it for you.
Related Reading
- AI Browser Agents (Atlas, Comet): 7-Point Governance Policy for Small Teams
- Agentic AI Vendor Contracts: The 8 Clauses You Need in 2026
- Agentic AI Liability: Who Is Responsible When Your AI Agent Makes a Mistake?
- Shadow AI Policy for Small Teams: 2026 Detection and Governance Guide
- AI Vendor Contract Red Flags 2026
- AI Vendor Due Diligence Checklist (2026): 30 Questions Before You Sign
- AI Agent Security Incident Response Playbook (TypeScript)
