Nyyon · Blog

Your agent's access is your access, and the Ninth Circuit just wrote it down.

The Ninth Circuit ruled that an AI agent is a tool under the CFAA, which puts every boundary it crosses on the desk of the human who deployed it.

The Ninth Circuit has ruled that an AI agent is a tool under the Computer Fraud and Abuse Act, which lands the liability for what it accesses on the human who deployed it. A tool carries no intent of its own, so when an agent crosses an authorization boundary the court reaches past the software and asks which person pointed it there. Every team buying agent products has been hoping that question would stay fuzzy. It is answered now, in the circuit that covers most of the companies building these things.

The comforting version had the agent as its own actor. It wandered somewhere it should have avoided, the behavior was emergent, and responsibility dissolved across the model maker, the vendor, and the agent itself. The court looked at that and saw a scraper with better manners. Whoever aimed it owns the result.

The comforting story spreads liability across four parties, while the court routes access through the tool to a single operator.

The court read the agent as a tool and stopped there

The holding is plain. An AI agent is a tool under the CFAA, so it can stand as a defendant in roughly the sense a hammer can. Personhood is what lets a court locate intent, and the intent behind an agent's access sits with the operator who set it running.

This is how the statute has always run. A scraper script is a tool. A curl command in a cron job is a tool. When either one reaches a system past its authorization, the human who scheduled it answers for it. The Ninth Circuit put the agent in that same box and declined to invent a third category, a machine that acts on its own account and absorbs its own consequences.

Autonomy raises the exposure. A script does one thing on a timer, against one endpoint, in a shape you reviewed. An agent improvises across a hundred pages at machine speed, under your API keys, against sites your legal team has never seen. The operator's name sits behind every one of those requests.

Your exposure is the agent you pointed outward

The teams carrying real CFAA risk today run agents that browse, scrape, fill forms, or call APIs on properties somebody else owns. Every one of those agents belongs to whoever deployed it, down to the actions it takes past authorization at 2am while the team sleeps.

Picture the concrete case. An enrichment agent walks past a robots block on a competitor's site to pull pricing for a market scan. It clicks through a terms gate on the way, because the gate looked like a form and the agent fills forms. No human chose that step. The bill arrives as a CFAA claim and a motion for an injunction, on the plaintiff's schedule, and the vendor whose product you are running watches from the stands.

The chain runs four steps and a skeptical CTO should walk all four. One, an agent crosses an authorization boundary on somebody else's system. Two, that operator files a CFAA claim and moves for an injunction. Three, the court looks for the intent behind the access, finds a tool holding none, and keeps looking until it reaches a person. Four, your legal team spends weeks reconstructing who authorized that access, and where the record answers "the agent decided", the person holding the intent by default is you.

Four steps running from an agent crossing a boundary to the deployer holding the intent by default.

Name the human before the agent runs

Treat the agent 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 one we build in for clients running agents against systems they care about. The agent becomes the hands of a person with a title, a calendar, and a boss.

Three things go in before the first run. Logged authorization boundaries, so every access the agent makes carries a record of what it was permitted to touch. An allow-list of domains and endpoints it may reach, written down in a file a lawyer can read without an engineer translating. And one name on that list, a person accountable for the scope who reviews it when the scope moves.

Three controls to put in place before an agent runs: logged boundaries, an allow-list, and a named owner.

The timing carries the whole value. Reconstructing "who authorized this access" out of logs built for debugging is weeks of an engineer's quarter spent inferring intent from telemetry, under discovery deadlines, while an injunction holds the agent still. Writing the allow-list up front is an afternoon that turns the same subpoena into a lookup.

A comparison of answering the authorization question before an agent ships versus after a claim arrives.

A narrow holding with reasoning that travels

Take the strongest objection first. This is a CFAA case about unauthorized access, so the holding is narrow and bounded by that statute. Fair. The reasoning travels further than the holding does: personhood is what makes a defendant, the intent sits with the operator, and responsibility lands on the human who deployed the tool. Courts reach for that logic by habit, and it maps onto the next accountability question a deployer will face. Betting a compliance posture on the holding staying boxed inside one statute is a bet against reasoning courts already run everywhere else.

Second objection: your agents only run inside your own systems, so authorization is settled for you. If that holds, the ruling costs you an afternoon of confirming it, which is cheaper than assuming it. An agent that enriches a lead by calling a third-party site has crossed a boundary. So has one that checks a competitor's stock levels, and so has the one your growth team stood up last month and told nobody about.

Third objection: the vendor's terms say they carry compliance. The court placed the liability with the deployer, and an indemnity clause is a contract you enforce after the fact, in a second proceeding, on a slower clock. The injunction stops your agent while that proceeding runs. Read who owns the authorization before you price that clause into your risk.

The audit that fits in an afternoon

This week, list every agent you run that touches a system somebody else owns. For each one, write the name of the accountable human and the exact domains and endpoints it is authorized to reach. Where the answer to "who authorized this access" comes back empty, pause that agent first, before it makes another call you would have to explain to a court.

The audit costs a few hours. Skipping it costs the weeks of discovery you spend reconstructing authorization from logs that were built to answer a different question, plus the injunction that holds the agent still while you do it. Agents are worth running against the outside world. They are worth running with a name on them.


← All articles