The Ninth Circuit ruling means the human who deployed the agent carries the liability for what it accesses.

The Ninth Circuit just ruled that AI agents are tools, not persons, under the Computer Fraud and Abuse Act. That settles the one question every enterprise buying an agent was quietly hoping to leave fuzzy: when your agent scrapes a competitor's site, submits a form it shouldn't, or accesses a system past its authorization, the liability lands on you, the deployer, the same way it would if you had written the script by hand. There is no autonomous-actor shield. There is no "the model decided" defense. If you run an agent against systems you don't own, treat it as your own hands on the keyboard, because the court just did.

Most teams I talk to buying agent products assume the risk sits somewhere else: with the model maker, with the vendor, with the emergent behavior of the thing itself. This ruling puts the risk back where the access happened. Whoever pointed the agent at the system owns the consequences.

The court put the line down this week

The holding is plain. An AI agent is a tool under the CFAA, which means it can't be a defendant and can't hold intent of its own. A tool has no personhood, so a court reaches for the operator to locate the intent behind the access.

This maps onto how the CFAA has always worked. A scraper script is a tool. A curl command is a tool. When either one hits a system past its authorization, the human who ran it answers for it. The agent joins that same category. The court refused to invent a third thing, a machine that acts on its own account and absorbs its own liability. It looked at the agent and saw a tool with a human behind it.

The comforting story people told themselves was that an autonomous agent is its own actor. If it wandered somewhere it shouldn't, that was emergent behavior nobody chose, so nobody could really be blamed. The ruling erases that story. A tool concentrates responsibility on the operator. Autonomy raises the exposure, because now your named agent is out there taking actions at machine speed against systems you have to answer for.

Your exposure is your own agents pointed outward

The teams carrying real CFAA risk today run agents that browse, scrape, fill forms, or hit APIs on sites they don't control. Every one of those agents now belongs to whoever deployed it, all the way down to the actions it takes past authorization.

Picture the concrete case. An agent ignores a robots block on a competitor's site. Or it clicks through a terms gate to pull pricing your team wanted for a market scan. That agent is your CFAA exposure, and the price shows up as legal fees and injunctions on your desk, on the vendor's timeline of nothing. I think most teams underestimate how often their agents cross a boundary they don't own, because the agent does it in a browser tab nobody is watching, at 2am, while everyone assumes it stays inside the guardrails.

Here is the numbered consequence a skeptical CTO should sit with. One: an agent crosses an authorization boundary you don't own. Two: the operator of the crossed system files a CFAA claim and moves for an injunction. Three: the court reaches for the deployer to find the intent, because the tool holds none. Four: your legal team spends weeks establishing who authorized that access, and if the answer is "nobody, the agent decided," you are the party holding the intent by default.

Ownership is the whole design problem

Stop treating the agent as an actor. Treat it as an extension of a named human who signed off on its scope. That is the design move this ruling forces, and it is the same move we build for clients running agents against systems they care about.

Concretely, three things go in before the agent runs. Logged authorization boundaries, so every access the agent makes carries a record of what it was permitted to touch. An allow-list of systems it may reach, written as domains and endpoints. And a person whose name sits on that list, accountable for the scope.

The timing is the point. You build this before the agent ships, not after a subpoena arrives. Reconstructing "who authorized this access" from logs you never designed to answer that question is a discovery nightmare, weeks of an engineer's quarter spent piecing together intent from telemetry. Writing the allow-list up front is an afternoon of work that turns a subpoena into a lookup.

The narrow holding carries a broad signal

Read the honest objection first. This ruling is a CFAA case about unauthorized access, so it is narrow. That is fair. The holding does not decide general AI liability, and I won't pretend it does.

The reasoning is the part that travels. A tool has no personhood, and the operator carries the intent, so a court locates responsibility with the human who deployed the tool. That is the default reasoning courts reach for, and it maps onto every accountability question a deployer will face next. Narrow holding, broad signal. Betting your compliance posture on the holding staying boxed inside the CFAA is a bet against the reasoning courts already use everywhere else.

Second objection: your agents only run inside your own systems, so authorization is a non-issue for you. If that is true, this ruling costs you nothing today, which is exactly why it is worth confirming rather than assuming. The exposure lives wherever an agent crosses a boundary you don't own, and a quick audit usually finds more of those crossings than the team expected. An agent that enriches a lead by hitting a third-party site has crossed a boundary. So has one that checks a competitor's stock levels.

Third objection: the vendor's terms say they handle compliance. The court put the liability with the deployer, and a vendor indemnity clause is a contract you would have to enforce after the fact. It sits alongside the CFAA claim, it does not move where the CFAA lands the access. By the time you are litigating the indemnity, the injunction has already stopped your agent. Read who actually owns the authorization before you bet on that clause.

Do this before the next agent ships

This week, list every agent you run that touches a system you don't own. For each one, name the human accountable, and write down exactly which domains and endpoints it is authorized to reach. If you can't answer "who authorized this access" for a given agent, that is the one to pause first, before it makes another call you would have to explain to a court. The audit is a few hours. Skipping it costs you the weeks of discovery you will spend reconstructing authorization from logs after a claim arrives, plus the injunction that halts the agent while you do it.