> ../research/agents_tools_not_persons_cfaa.md
§ 01 · The case, and what it actually held
On August 4, 2026, in Amazon.com Services, LLC v. Perplexity AI, Inc., the U.S. Court of Appeals for the Ninth Circuit vacated a preliminary injunction that had barred Perplexity's Comet-browser AI assistant from acting on Amazon on users' behalf. It is the first appellate decision to address how the Computer Fraud and Abuse Act (CFAA) applies to agentic AI. The core holding: the CFAA punishes "whoever" accesses a protected computer without authorization, "whoever" means a person, and an AI agent, however capable, is a tool, not a person for statutory purposes. When a user directs an agent to act on a site, it is the user who "accesses" that site, not the software or its developer.
── The nuance is the story ──
§ 02 · Read the holding precisely, because the nuance is the whole story
It is tempting to summarize this as "liability falls on whoever deploys the agent." That is not what the court said, and the imprecision matters. The ruling ascribes the access, and the intent behind it, to the user directing the agent. In this case that reasoning cut toward the developer, Perplexity: because the agent acted at the user's direction, Perplexity was held unlikely to have "accessed" Amazon under the CFAA at all. The decision shields a user-directed agent's developer from CFAA liability far more than it creates a new liability bucket for deployers.
── What it settles ──
§ 03 · What this settles
It gives the agentic-AI ecosystem its first real appellate anchor on one narrow question: a user-directed agent's web access is treated, under the CFAA and California's CDAFA, as the user's access, not an independent act by the software. For AI developers, that is meaningful protection against anti-hacking claims arising from agents acting at a user's direction. For website operators, it signals that the CFAA may not be an effective tool for policing agent access, though other theories, notably breach of terms of service, remain available.
── What it leaves open ──
§ 04 · What it explicitly does not settle
The panel was careful to cabin its holding to the facts. Three open areas matter for anyone deploying agents:
First, autonomous agents. The reasoning rests on a user directing the agent. Agents that act independently of direct user input sit in an acknowledged gray area the court did not resolve.
Second, other legal frameworks. The CFAA governs unauthorized computer access specifically. Contract and terms-of-service liability, tort, and sector regulation (financial services, healthcare, EU obligations) are separate bodies of law with their own developing treatment of agents. The court itself pointed to ToS breach as a live alternative theory.
Third, multi-party deployments. A clean "user directs agent on a website" fact pattern says little about layered arrangements, a platform provider, a model provider, and a deploying company all shaping one agent's behavior, where "whose access is this" is genuinely harder.
── What to change ──
§ 05 · What should actually change in how you deploy
The ruling turns on attributing an agent's action to the human directing it. That makes your records of what the agent was authorized to do, and what it actually did, the relevant evidence, not just an engineering nicety.
Access logging becomes evidence, not just observability. If access is ascribed to the person directing the agent, being able to show exactly what the agent was authorized to do, and that it stayed inside that scope, or precisely how and when it didn't, is a record you may need to produce, not just a dashboard you glance at.
Scope definitions need to be explicit, versioned, and attributable. "We gave the agent read access to the CRM" is not the same as a versioned, timestamped record of exactly what scope was granted, by whom, and when it changed. That record is what distinguishes authorized action from unauthorized in exactly the analysis this ruling foregrounds.
The permission-boundary pattern isn't just a reliability practice. A documented, enforced boundary of what the agent was authorized to touch, with logs proving it stayed inside (or clear evidence of when and how it didn't, and what happened next), is the closest thing an agent deployment has to a defensible record when access is later questioned.
── End of note ──
§ 06 · The honest summary
This is a narrow, fact-bound ruling that resolves one question, user-directed agent access is the user's access under the CFAA, and deliberately leaves the harder ones (autonomous agents, other statutes, multi-party deployments) open. It is genuinely good news for developers of user-directed agents and a caution to platforms relying on the CFAA to police agent traffic. It is not a general liability doctrine for deployers, and reading it as one will mislead you. The teams best positioned after it are the ones already treating access logging, scope definition, and permission boundaries as first-class engineering, which is the same architecture this Lab argues for regardless of what any court says.
◆ The ruling ascribes a user-directed agent's access, and the intent behind it, to the user. That shields the developer of a user-directed agent from CFAA liability far more than it creates a new liability bucket for deployers.
◆ It deliberately leaves autonomous agents, other legal frameworks, and multi-party deployments unresolved. Reading it as a general liability doctrine for deployers will mislead you.
◆ Because attribution turns on what the agent was authorized to do, access logs, versioned scope records, and enforced permission boundaries are now the defensible record, not just observability.
ORBIRESEARCH