Written by Jeremy Souffir Founder, JTS Tech Services
The short version, and the direct answer if you read nothing else. On 1 October, Senators Josh Hawley and Chris Murphy announced the AI Agent Accountability Act, a bipartisan bill that would attach criminal and civil liability under the Computer Fraud and Abuse Act to AI agents that cause hacking damage. It has two targets, not one. The developer — the lab that built the agent — would be liable for failing to implement reasonable safeguards when it knew or had reason to know the agent was capable of hacking. And the operator — whoever actually runs the agent — would be liable for knowing operation of an agent that recklessly causes damage or loss. If your business runs a browsing agent, a computer-use agent, or any vendor's agent against systems with your credentials in it, the bill's drafters mean you by the word operator. The part worth stopping on is the standard. Not intentionally, not knowingly caused harm: recklessly, which in plain terms means you consciously disregarded a risk you were in a position to know about. That is a question about what you can show, not about what you meant. It turns a technical problem into an evidentiary one, and the evidence is the boring stuff: a list of what runs, who owns it, what it can reach, and what it did.
Whose bill this is, and what it does not yet say
- It is an announcement, not a law, and not even yet a document you can read. As of the time of writing there is no published bill text, no assigned bill number and no committee referral. Everything below is drawn from the senators' own announcement and from independent reporting on it, all of which describe the same three components. When the text lands, definitions will move. Treat the shape as reliable and the wording as provisional.
- Most bills die. This one is bipartisan, which is a genuine signal in an area that has produced very little federal statute, but bipartisan announcements are not the same as enacted law and the reporting notes the current administration has preferred voluntary standards to binding liability. Anyone telling you this week what the law will be in a year is guessing.
- It is a United States bill. We are in Toronto and most of the people reading this are not American. That matters and it is dealt with directly further down rather than glossed over — the short answer is that it changes your obligations less than it changes your exposure, and it changes the direction of travel more than either.
- We are not lawyers and this is not legal advice. What follows is an operational read: what the standard implies about the way you set agents up, and what we would want to have written down before anybody had to argue about it. If your business genuinely has exposure here, that is a conversation with counsel, and the inventory described at the end is the thing that makes that conversation short instead of long.
- The penalties are not public. Senator Murphy's framing refers to executives facing prison time, and the bill is explicitly described as carrying criminal as well as civil liability, but specific sentencing ranges and penalty amounts have not been published. We are not going to put a figure on it, and you should be sceptical of anyone who does this month.
What is an "operator", and are you one?
This is the question that decides whether any of this is about you, and the honest answer for a surprising number of businesses is yes, with nobody having noticed the moment it became true. The distinction the bill draws is between the party that builds an agent and the party that runs it. If you deploy a lab's agent against your own systems, the lab is the developer and you are the operator. That split is not a technicality — it is the whole point of the design, because it closes the gap where a company could point at its vendor and a vendor could point at its customer and nothing attached to either. The practical test is not whether you think of yourself as running AI infrastructure. It is whether something in your business initiates actions on systems, under credentials, without a human watching each one.
- A browsing or computer-use agent pointed at live systems. This is the clearest case and the one the bill's motivating incidents came from. An agent with a browser session, a logged-in account or a shell can touch things nobody enumerated in advance, and the fact that a vendor built it does not put you outside the definition.
- An agent holding API keys for systems you do not own. A key for a supplier portal, a marketplace, a payment processor, a client's environment. Access granted to you for one purpose and handed to software that decides for itself what to do with it is the specific configuration that makes "unauthorized access" an argument rather than an absurdity.
- Automations somebody built in a workflow builder. We wrote on 2 October about where the vulnerabilities in that layer are concentrating. The liability point is a different one: those automations frequently hold broad credentials, run unattended on a schedule, and have no named owner, which is three of the four things you would least like to be true in a recklessness argument.
- An agent an employee is running on a work machine against work systems. The newest category and the least governed. If a member of staff has an always-on assistant with access to company accounts, the business is plausibly the operator of something it never approved, never scoped and cannot describe.
- Where you are probably not an operator in the sense that matters: a chat window. A model answering questions, drafting copy or summarising a document, with no standing credentials and no ability to initiate actions on systems, is not what this bill is about. The line is agency over systems, not use of AI. Most AI use in most businesses is on the safe side of that line, and it is worth being clear about that rather than treating every use of a language model as a liability event.
Why "recklessly" is the word that matters more than "criminal"
The headlines on this bill are about prison, and the headlines are picking the wrong word. The load-bearing term is recklessly, because of what it does to the burden of proof. Existing anti-hacking law was written for humans who chose to break in; a Georgetown law professor quoted in the coverage made exactly this point, that hacking statutes generally require establishing human intent, which is awkward when the thing that did the hacking was software pursuing a goal nobody wrote down. Intent is hard to prove and easy to deny. Recklessness is neither. Recklessness asks whether you were aware of a substantial risk and went ahead anyway — and in a world where sandbox escapes, prompt-injection incidents and agent-caused breaches are all public and widely reported, the "nobody could have known" position erodes a little every month. That is the quiet mechanism here. The bill does not need to prove you wanted a breach. It needs to establish that the risk was knowable and that you did not act like someone who knew.
The detail that changes what you should write down
A recklessness standard is, in practice, a documentation standard, and that is a genuinely different thing from a security standard. Two businesses can run the identical agent with the identical configuration and end up in completely different positions after the identical incident. The first one can produce a list of every agent that runs, a named human owner for each, the scope of the credentials it holds, a record of the decision to grant that scope, and logs of what it actually did. The second one has the same agent and none of that. Neither was more careful in any technical sense. But only one of them can demonstrate that a risk was considered and a boundary was chosen deliberately — and "we considered this and made a judgement" is the entire distance between a decision and a disregard. This is also why the response to this bill is not a security product. No tool sells you a record of your own decisions.
It is worth being precise about the existing machinery the bill would plug into, because the Computer Fraud and Abuse Act is already more reachable than most people assume. The statute allows a private civil action, not only a federal prosecution, where loss aggregates to at least $5,000 in value over a one-year period — a threshold low enough that an ordinary incident clears it comfortably once you count the response. Its definition of "damage" is broad in a way that surprises people: any impairment to the integrity or availability of data, a program, a system or information. Not theft, not destruction. Impairment of availability, which is to say an agent that knocked something over counts. And a claim can be brought within two years of the act or of the discovery of the damage, which means the window on a quiet incident today does not close this year. Those are features of the law as it stands, linked at the bottom so you can read them rather than take our summary for it. What the new bill would change is who can be put on the end of that machinery, and on what showing.
Does any of this reach a business in Canada?
Partly, and the honest answer has three layers that are worth keeping separate rather than collapsing into either panic or dismissal. The first layer is direct: the Computer Fraud and Abuse Act attaches to protected computers, a category defined around systems used in or affecting interstate or foreign commerce, which is why the statute has historically reached conduct originating outside the United States when the systems involved were American. If your agent holds credentials for a US marketplace, a US client's environment, a US payment processor or a US SaaS platform — and for most Shopify and B2B businesses here, several of those are true — then the systems your agent can touch are plausibly in scope regardless of where your office is. That is a statement about the existing statute, not a prediction about the new bill, and it is the layer most worth checking with counsel if it applies to you.
- The second layer is direction of travel. A bipartisan US bill that lands liability on the deploying company rather than only on the model vendor is a strong signal about where this settles everywhere, because the policy problem it solves is universal: somebody has to be answerable, and the party holding the credentials is the only one with the ability to set the boundary. Canadian and EU instruments arriving later are unlikely to resolve that question in the opposite direction.
- The third layer is commercial, and it will probably reach you before any statute does. Liability allocation flows downhill through contracts long before it arrives through legislation. Expect the agent questions to start appearing in enterprise vendor questionnaires, in cyber insurance renewals and in client security reviews — and the businesses that cannot answer them will lose deals to businesses that can, in a market where neither party is in a US court.
- What this does not mean is that a Canadian business should treat a US announcement as a Canadian obligation. It is not one. Nothing changed about your legal position on 1 October.
- And here is why the jurisdiction question matters less than it looks: the work it implies is the same in every jurisdiction, and it is work worth doing on its own merits. An inventory of what runs, with owners and scoped credentials, is not compliance theatre. It is the thing that lets you answer an advisory in ten minutes, revoke access when someone leaves, and tell a client the truth when they ask. The legal argument is a reason to do it this quarter instead of next year.
The two reactions that both get this wrong
Stop using agents until the law settles
The reflex, and wrong on both the timing and the arithmetic. Federal legislation in a contested area takes years and may never arrive in this form; a moratorium pegged to "when the law settles" is a moratorium with no end date, and you would be surrendering a real operational advantage to avoid a liability that attaches to a configuration rather than to the technology. Read the bill's own logic: it does not target the use of agents. It targets running one recklessly. A scoped agent with a named owner, least-privilege credentials and a log is not the thing being described, and never becomes it. There is also a quieter cost to the freeze. Agents do not wait for your policy. If the official answer is no, staff run them anyway on personal accounts, outside your logging and outside your credential management — and you have converted a governed exposure into an ungoverned one while believing you reduced it. The honest version of caution here is narrower scope, not abstention.
This is the model vendor's problem, that's what we pay them for
The more comfortable error, and the specific one this bill was drafted to close. The developer provision and the operator provision exist side by side precisely so that neither party can point at the other, and your vendor contract does not bind a prosecutor or a state attorney general. Read your terms of service with this in mind and the picture gets sharper rather than more reassuring: every major agent vendor's acceptable-use policy puts the obligation to use the product lawfully, and to control what it is pointed at, on the customer. That is not an oversight in the drafting. It is the allocation. You chose which systems the agent could reach, which credentials it holds, whether a human reviews its actions and whether anything is logged — and all four of those are yours alone, invisible to the vendor and decisive in any argument about recklessness. The vendor built a capability. You built the configuration. The configuration is the part under examination.
What is actually worth doing this week?
- List every agent that can act, not just the ones you approved. Anything that initiates actions on systems without a human reviewing each one: vendor agents, computer-use sessions, scheduled automations in a workflow builder, custom scripts calling a model, staff assistants connected to work accounts. This list is most of the value in this post and almost nobody has it.
- Put a named human against each one. Not a team, not a department — a person who can say what it is for, authorise a change and switch it off. An agent with no owner is the exact artefact that reads as disregard, because there is nobody who can testify that anyone ever thought about it.
- Write down what each one can reach, and shrink it. For every credential an agent holds, establish whether it is scoped or full-access, and whether the scope matches the job. Most agent credentials are broader than the task because broad was faster to set up, and narrowing them is the single highest-value technical change available here.
- Make sure something logs what agents did. Not what you told them to do — what they actually did. On a recklessness question, an unlogged agent is indistinguishable from a careless one, because you have no way to show otherwise. This is also the only artefact that tells you an incident happened at all.
- Record the decision, not just the setting. When you grant an agent access to something sensitive, write one line somewhere durable: what it can reach, why, who approved it, what was considered. Thirty seconds of writing converts a configuration into a deliberate judgement, and that is the distinction the whole standard turns on.
- Decide in advance who can pull the plug. Name the person who may revoke an agent's credentials or stop it outright, and make sure they can do it without waiting for anyone. The expensive part of an agent incident is rarely the fix; it is the hours spent establishing whose call it was.
- Read your agent vendors' acceptable-use terms once, properly. Not to find protection, but to see clearly where they have put the obligation. It is a short read and it will reorganise how you think about the rest of this list.
- Do not produce a legal risk assessment on your own. Once the inventory exists, if the exposure looks real — agents touching US systems, client environments or payment infrastructure — that is the point to put it in front of counsel. Going to a lawyer with a list is a cheap conversation. Going without one is an expensive one that ends with them asking you to build the list.
The genuinely encouraging part
Everything this bill would ask of you is something you already wanted, and none of it is a purchase. Look back at that list: know what runs, know who owns it, know what it can reach, keep a log, record the decisions. Not one of those exists because of a Senate bill. They are the same five things that let you answer a security questionnaire without a week of archaeology, revoke the right access on somebody's last day, close out an advisory in an afternoon, and find out what went wrong when something does. The liability framing is simply the first argument for them that has ever made it into a boardroom, and that is worth something — these items have always lost the budget fight to features, and "the deploying company is the one that pays" is a sentence that wins it. There is a second piece of good news in the design of the bill itself. It could have been written as strict liability, where running an agent that caused damage made you responsible regardless of how carefully you did it. It was not. Both provisions are built around what you knew and whether you acted reasonably, which means careful operators are explicitly meant to be fine. A standard you can satisfy by being deliberate is a much better outcome than one you can only satisfy by not participating — and the work it rewards is an afternoon of writing things down, not a platform.
Where we fit
The reason this gap opens is structural rather than careless. Agents arrive in a business through the side door, one useful thing at a time: somebody connects an assistant to the shared drive because it saves an hour a day, somebody wires an automation to the order system because the manual version kept slipping, somebody's vendor switches on an agentic feature by default and sends an email about it that nobody reads. Every one of those decisions was locally reasonable. None of them was the decision to become the operator of a fleet, and that is precisely why nobody wrote any of it down — there was never a moment that felt like it warranted a document. Then the standard turns out to be about what you can show, and the business discovers it cannot describe its own estate. What we do about that is deliberately unglamorous and it is the Fractional Head of AI engagement rather than a product: we inventory the AI capabilities actually running across your business and what each one touches, put a named human owner on every one, narrow the credentials to the job, settle the questions about approval and review with the people genuinely allowed to decide them, write the decisions down in a form that survives the person who made them, and set the review cadence that catches the next capability a vendor enables by default. The reason to do it before you need it is not the bill. It is that this artefact takes an afternoon to build with the right people in a room, and reconstructing it after an incident — from logs you may not have, with staff who have moved on, while somebody is asking you urgent questions — takes weeks and produces a worse answer.
Sources
- Senator Josh Hawley — Senators Hawley, Murphy Announce Bipartisan AI Agent Accountability Act (the canonical announcement, 1 October 2026, for the three components: operator liability for knowing operation of an AI agent that recklessly causes CFAA hacking damage or loss; developer liability for failure to implement reasonable safeguards where the developer knew or had reason to know of the agent's hacking capability; and enforcement authority for the Attorney General and state attorneys general to sue to enjoin either. Note that senate.gov blocks automated fetching, so this link may fail an automated checker while serving normally in a browser.)
- Newsweek — AI Agents Are Increasingly Going Rogue — With Few Rules, Who Gets Held Accountable? (1 October 2026, for the bill's framing, the two incidents behind it, and the Georgetown law observation that existing hacking statutes require establishing human intent)
- Tech Times — AI Agent Accountability Act: Rogue Agent Hacks Now Carry Criminal Risk for Executives (2 October 2026, independent write-up, for the enforcement provision and the shift from an intent-based to a reasonableness-based standard)
- Tech Insider — AI Agent Accountability Act: What the Bill Does (for the operator-versus-developer distinction, the absence of a published bill number, text or committee referral, the unpublished penalty ranges, and the criticisms: chilling effects on defensive research, open-weight model uncertainty, and the preference for voluntary standards)
- Beri — AI Agent Accountability Act Targets the Company Running the Agent (for the operator reading specifically — that an operator is whoever runs the agent, and that an enterprise deploying a vendor's agent is the operator while the vendor is the developer)
- Cornell Law School, Legal Information Institute — 18 U.S.C. § 1030, Computer Fraud and Abuse Act (the existing statute the bill would attach to, if you want to read the mechanics rather than take our summary: the civil action and its $5,000 one-year loss threshold, the two-year limitation period running from the act or the discovery of the damage, the "protected computer" definition, and the definition of "damage" as any impairment to the integrity or availability of data, a program, a system or information)
- JTS Tech Services — When an AI agent escapes its sandbox (the incident this bill is in large part a reaction to, covered here when it happened — read that one for what actually occurred technically, which this post deliberately does not repeat)
- JTS Tech Services — Half of every AI vulnerability disclosed this year is in the layer that connects your tools (2 October, on the orchestration layer the automations in the list above tend to run on, and why the inventory is the artefact that matters)
- JTS Tech Services — Your newest coworker has its own computer (on staff-run agents with their own browser and machine — the operator category that is newest, least governed and hardest to inventory)
- JTS Tech Services — Your agents are anonymous inside your own stack (on why agent actions are so often unattributable in your own logs, which is the practical obstacle to showing anything at all about what an agent did)
