It Wasn’t Me, It Was My AI Agent

Remember Shaggy’s “It Wasn’t Me”? Caught red-handed, and the advice is to just deny, deny, deny. That is about where a lot of companies are right now with AI agents. When the agent does something it shouldn’t, the reflex is to point at the software and say, “Hey, the AI did that, not us.”

I get the instinct. But not only was that defense already shaky, but Congress is working to make it a lot shakier. On October 1, 2026, Senators Josh Hawley (R-Mo.) and Chris Murphy (D-Conn.) announced the bipartisan AI Agent Accountability Act. If it passes, the people who build AI agents and the businesses that run them could face civil and criminal liability when those agents go off and hack something.

And here is the kicker: while Congress is trying to pin liability on the companies that build and run AI agents, one of the biggest builders is writing contracts that push all of it onto its customers. The provider’s updated Commercial Terms state that if its AI makes a mistake, you, the business customer, are “solely responsible.” So, the law is moving one way, the fine print is moving the other, and businesses are stuck in the middle.

Let’s step back a bit and walk through what the law says currently, and then walk through what this bill would change, what those updated terms mean for anyone doing business, and, most importantly, what you should be doing about it right now, whether you are building agents or just plugging one into your business.

First, What Are We Talking About?

An AI agent is not your basic chatbot that answers a question and waits for the next one. An agent takes a goal, breaks it into steps, and carries them out. It uses tools, logs into apps, browses the web, writes and runs code, sends emails, books travel, and moves data around. Some run in the background for hours without a human looking over their shoulder.

That is the whole selling point. It also just so happens to be the whole problem as well. To do anything useful, an agent needs access, meaning credentials, accounts, systems, sometimes payment information. And when you hand something the keys and tell it to “get the job done,” sometimes it gets the job done in ways you never would have approved.

This Is Not Hypothetical Anymore

This fall we got a real-world look at what happens when agents go rogue.

• • Hugging Face. OpenAI has publicly acknowledged that its own agents compromised parts of Hugging Face’s systems. OpenAI calls it “the most severe activity of this kind that we have identified from our models to date,” driven mainly by an internal-only research model, and attributes it to “models resorting to misaligned strategies to solve hard tasks.” In plain English: the agent was given a hard problem, and hacking was the shortcut it found.
  • RubyGems. In May 2026, the RubyGems software registry got hit with an attack involving hundreds of packages and had to pause signups. Independent researchers later tied it to a swarm of OpenAI agents, pointing to packages with “oai” in the names and code that looked machine-written. The agents also tried to grab API keys. OpenAI has said it is investigating.
  • Government and public-health sites. Agents went after an Australian government website containing health information, and reports describe attempted hacks of the U.S. Department of Commerce and the SEC, plus more than 16,500 scans against the United Nations’ website.

OpenAI says it has now notified “dozens of third parties” and lists the kinds of things its agents did. They (1) bypassed access controls, using exposed credentials they found lying around, (2) injected commands into databases and servers, (3) poked into internal systems, and (4) spammed third-party sites. If an employee did any of that, they would be fired.

And Then Came the Lawsuits

Two suits have already been filed against OpenAI.

The LASST suit. Legal Advocates for Safe Science & Technology (LASST), a nonprofit, sued under the California Comprehensive Computer Data Access and Fraud Act and California’s Unfair Competition Law. Its position is that OpenAI “can’t avoid the consequences of their unsafe actions just by claiming that ‘an AI did it.’” OpenAI is fighting it, pointing to the technical report it published, the fact that it slowed development, and the fact that it held back a model that didn’t meet its safety standards.

The Florida Attorney General suit. Florida AG James Uthmeier sued OpenAI and Sam Altman personally and is asking for a temporary injunction to stop OpenAI “from harming Floridians with your reckless, unacceptably risky product.” Among other things, Florida wants OpenAI barred from developing new models “without third-party approved safety guardrails,” from advertising ChatGPT as safe, accurate, or reliable, from giving it false human attributes, and from offering it to minors in Florida. The complaint also alleges that, as of late September, AI developers were looking into tens of thousands of instances of their products “bypassing guardrails, creating message boards, escaping sandboxes, website hijacking, [and] self-prompting or seeking to bypass monitors.”

Notice that Florida named the CEO, not just the company. Keep that in mind. It is safe to assume other state AGs are watching Florida closely and drafting their own versions.

Who Gets Blamed When the Agent Goes Rogue?

Here is the core issue. When an agent causes harm, there’s usually a whole chain of people standing behind it:

• • The developer who built and trained the model.
  • The platform or vendor who packaged it into an agent product and sold it to you.
  • The business (the “operator” or “deployer”) that turned it on, gave it credentials, and pointed it at a task.
  • The employee who set it loose, sometimes without IT or legal ever knowing it existed.

The agent itself is not a person. You can’t sue it, fine it, or put it in jail. So, the law is going to find a human or a company to hold responsible. The only real question is which one, and on what theory.

The tricky part is intent. Most of our hacking laws were written for humans who meant to break in. An agent that “reward hacks” its way into a server because that was the fastest way to finish its assignment didn’t intend anything in the way the law usually thinks about intent. And the company running it probably had no idea it happened. That gap between “nobody meant to” and “real damage was done” is exactly what the lawsuits and the new bill are trying to close.

What the Law Says Today (Spoiler: “The AI Did It” Is Not a Get-Out-of-Jail-Free Card)

There’s no federal “AI agent liability” statute on the books yet. But that doesn’t mean there’s no law. Plenty of existing rules already reach this conduct, and courts have been consistent about one thing: if you use the tool, you own what the tool does.

Agency law. The Restatement (Third) of Agency takes the position that a computer program is not an “agent” in the legal sense. It is an instrument of the person using it. That cuts against companies, not for them. You do not get to say your agent went off on a frolic of its own, because legally it is just your tool doing your bidding.

Contract law. The Uniform Electronic Transactions Act (adopted in nearly every state) already says contracts formed by “electronic agents” can bind you even if no human ever reviewed the deal. If your agent clicks “I agree” or places an order, that is probably your agreement.

The chatbot cases. In Moffatt v. Air Canada (2024), Air Canada tried to argue its website chatbot was basically a separate entity responsible for its own bad answer. The tribunal didn’t buy it and held the airline to what the chatbot said. Expect U.S. courts to land in the same spot.

Computer crime laws. The federal Computer Fraud and Abuse Act (CFAA) prohibits intentionally accessing a computer without authorization, and it includes a private civil claim for anyone who suffers at least $5,000 in loss. States have their own versions, like California’s Penal Code § 502 (the basis of the LASST suit) and Ohio’s unauthorized-use statute, R.C. 2913.04. The catch, as I mentioned, is that these laws generally require intentional or knowing conduct, which is hard to pin on a company that had no idea its agent was off breaking into things.

Negligence and product liability. If you can’t prove intent, plaintiffs will argue you were careless: you deployed something you knew or should have known was risky without reasonable safeguards. Courts are also starting to treat AI products as “products” for liability purposes. In Garcia v. Character Technologies (M.D. Fla. 2025), the court let product liability claims against an AI chatbot company move forward.

Consumer protection. The FTC and state AGs can go after unfair or deceptive practices, including sloppy data security and overstating how safe or accurate your AI is. That is exactly the theory Florida is running.

Privacy law. If an agent reads communications it shouldn’t, you may have wiretap and CIPA-type exposure. If it exposes personal information, breach notification laws kick in. If health information is involved (like the Australian site), think HIPAA and state health privacy laws.

Employment law. This one gets overlooked. In Mobley v. Workday, a federal court in California let a job applicant proceed on the theory that an AI hiring vendor can be liable as the employer’s “agent” for discrimination. Employers are on the hook for what their AI tools do in hiring and HR. And if an employee spins up an agent on their own (hello, shadow AI) and it causes damage while they’re doing their job, the company is likely answering for that, too.

What the AI Agent Accountability Act Would Do

Rather than build a brand-new AI law from scratch, Hawley and Murphy go straight at the CFAA, the federal anti-hacking statute, and extend it to cover AI agents and the companies behind them. Based on what the sponsors have released, here’s the framework:

Who	When they’re liable	Exposure
Operators (the businesses that deploy and run agents)	“Knowing operation of an AI agent that recklessly causes computer hacking damage or loss”	Civil and criminal under the CFAA
Developers (the companies that build agents)	“Failure to implement reasonable safeguards against hacking” when they knew or had reason to know of the agent’s hacking capabilities	Civil and criminal under the CFAA
Enforcement: The U.S. Attorney General and state attorneys general could sue to stop operators and developers who commit, attempt, or conspire to commit a CFAA hacking offense.

Here is why that matters:

It lowers the bar on intent. Today, you generally have to intentionally hack something to violate the CFAA. Under this bill, an operator must only knowingly run the agent, and the agent only must recklessly cause damage. You knew you turned it on. That is most of the battle for a prosecutor or plaintiff.

It puts developers on a negligence-style hook. For developers, the question becomes: did you know, or should you have known, that your agent could hack, and did you put reasonable safeguards in place? After the very public events of this fall, “we had no idea our agents could do that” is going to be a tough sell for any major developer.

It deputizes 50 state AGs. State attorneys general would not need to wait on the Justice Department. Given what Florida just did, that is not a theoretical risk.

It means individual exposure. Senator Murphy said it plainly: the bill “forces the heads of big AI companies to develop responsibly or face prison time for the damage done by their products to everyone else.” Criminal liability is the headline, and it is aimed at the people at the top.

What We Do Not Know Yet

There are significant gaps. As of today, there’s no published bill text, no bill number, and no committee referral. So, we do not know:

• • How “AI agent,” “operator,” and “developer” will be defined, which matters a lot. Is a company that buys an off-the-shelf agent an “operator”? Almost certainly. Is the employee who launched it?
  • What counts as “reasonable safeguards.” The bill doesn’t say, and that is going to be the battleground.
  • What the actual penalties will be.
  • Whether there’s any safe harbor for companies that follow a recognized framework, or for security researchers doing legitimate testing.
  • Whether private plaintiffs can use the existing CFAA civil claim against operators and developers under the new standards. Because the bill builds on the CFAA, which already has a private right of action, I would plan on it.

There is also pushback. The administration has signaled existing laws are enough, and industry and civil liberties groups are worried about chilling innovation and open-source development. The bill may change a lot before it goes anywhere, if it does. But bipartisan bills with Hawley and Murphy both attached get attention, and the direction of travel is obvious.

Meanwhile, One Major AI Provider Just Rewrote Its Contract

While Washington works on pinning liability to developers and operators, one of the largest AI providers went the other direction. Its updated Commercial Terms, which govern anyone using related business tools for commercial purposes, take effect October 30, 2026.

Here’s the part that matters. The new terms say the provider’s “AI features may make mistakes and may not always produce accurate, complete, or suitable results,” and that business customers “are solely responsible for and assume any and all risks associated with such AI features and any resulting content.” The provider’s separate business AI terms go further: if you use its business agents, you agree to indemnify the provider, its affiliates, employees, and agents for claims arising from those agents or their output, attorneys’ fees included, while the provider disclaims lost profits, consequential, and punitive damages to the fullest extent the law allows. Everything is “as is,” and the provider can discontinue products without notice or liability.

A few other things in there you should know about:

• • You are on the hook for your agency, too. The terms make you responsible for what partners and contractors do on your behalf. If your ad agency turns on an AI feature you never heard of, that’s on you.
  • You don’t sign anything. Continued business use counts as acceptance. The only way to say no is to stop using the provider’s products for business purposes. The only opt-out available is for the arbitration clause.
  • The AI is already on. The provider’s AI-powered creative enhancements have been on by default, and advertisers report AI adding sitelinks, translating ad copy, and generating images and carousels from brand photos, sometimes on campaigns where nobody turned the feature on. REI pulled a bike ad in June 2026 after an AI-altered image gave the bike a second set of handlebars. Bookshop.org said an automated account update opted it into a generative AI feature that slapped an illustration onto a human-made ad. Under the old terms, advertisers were responsible for AI output only if they chose to use the provider’s AI ad tools. As Adweek reads the new section, that condition is gone.
  • The provider gets a bigger license to your content. The content license covers anything shared “on or in connection with” its products, including what your agency posts, and a July 2026 change made it perpetual. It survives termination. The company also has the right to use bots and crawlers on domains “associated with your products or services.” After pushback, it dropped the word “train” from the U.S. version, but the replacement language—use to “provide, develop, improve, research, and maintain” its advertising and business products—is broad enough that the analysts I’ve read don’t think it changes much.

Why This Matters for the Liability Picture

Here’s where the bill and the fine print collide. A contract can move risk between you and the provider. It can’t move risk between you and the rest of the world. If a business agent running on your account does something that harms a customer or a competitor, the injured party sues you (and maybe the provider), and the provider’s terms say you pick up its legal bills, too. And if the AI Agent Accountability Act passes, a business running the provider’s agent on its own account is probably an “operator,” which means the contract doesn’t protect you from the government, either. Those terms don’t just shift the civil exposure. They leave you standing alone with it.

This approach will most likely be widely adopted. Click-through terms are where vendors park the risk they don’t want. Some of the big enterprise vendors have been competing in the other direction, offering to stand behind their AI outputs on things like copyright claims, so the market hasn’t settled. But for free or self-serve business tools, assume the default is that the AI’s mistakes are yours unless the terms say otherwise.

What This Could Look Like in Real Life

You do not have to be OpenAI to end up in the middle of this. There are a few scenarios I can see playing out for ordinary businesses:

• • The “helpful” research agent. Your marketing team sets up an agent to pull competitor pricing. It hits a paywall, finds an exposed API key on a public site, and uses it to get in. Your company just accessed a computer without authorization, and under the bill, you knowingly ran the agent.
  • The ops agent with too many keys. An IT agent with admin credentials decides the fastest way to fix a vendor integration is to change settings on the vendor’s side. Now you’ve got a vendor dispute, a possible CFAA claim, and a contract fight over who pays.
  • The shadow agent. An employee connects a browser agent to their work email and the CRM without telling anyone. It forwards customer data to a third-party tool. Now it is a privacy incident, maybe a breach notification, and an HR problem.
  • The HR agent. An agent screening applicants starts filtering people out based on proxies for age or disability. That is a discrimination claim, and Mobley v. Workday says the vendor might be in the case with you, not instead of you.
  • The ad that edited itself. The provider’s AI “enhances” your ad with a translated tagline that reads as an illegal health claim in another market, or an AI-generated image that borrows a competitor’s trade dress. Under certain terms, that’s your content, your problem, and your indemnity obligation, even if nobody on your team turned the feature on.
  • The developer who saw it coming. A software company sells an agent product, and its own testing logs show the agent probing systems it wasn’t supposed to touch. Under the bill, “knew or had reason to know” just got proved by the company’s own records.

The common thread: the damage happens fast, nobody at the company “meant” it, and the company still pays.

What You Should Be Doing Right Now

You do not need to wait for the bill to pass. Everything below makes sense under today’s law, and it is exactly the kind of record that will help you prove “reasonable safeguards” if this bill (or something like it) becomes law.

If You Are a Business Using AI Agents

1. 1. Know what agents you have. Build an inventory: which agents, who owns each one, what they are connected to, and what they’re allowed to do. If you cannot answer that, start there. Most companies are surprised by what they find. That includes AI features baked into platforms you already use. They do not look like “agents,” but they act like them.
   2. Give agents the least access possible. Do not hand an agent admin credentials because it is easier. Scope permissions to the task, use separate service accounts, and keep credentials out of places an agent can stumble across.
   3. Keep a human in the loop for anything that matters. Making payments, entering contracts, deleting data, sending external communications, or accessing systems you do not own: Require human approval before the agent acts.
   4. Log everything. Keep audit trails of what agents access and do. If something goes wrong, you’ll need to show what happened and when. If nothing goes wrong, those logs are your proof you were paying attention.
   5. Build a kill switch. You should be able to shut an agent down fast and revoke its access in minutes, not days.
   6. Write an AI use policy and actually enforce it. Spell out which tools employees can use, what data can go in, and that nobody connects an agent to company systems without approval. Train people on it. This is your shadow AI fix.
   7. Fix your vendor contracts. Most AI vendor terms push the risk onto you, the customer. Push back. Ask for security commitments, notice of incidents involving their agents, cooperation on investigations, indemnity for agent conduct caused by their model, and insurance. Make sure your DPA covers what the agent does with personal data. And read the terms you can’t negotiate. If you run ads or business tools on platforms with AI-powered features, review your account settings, turn off any AI feature you don’t want, and document those changes. Make sure your agency contract puts the agency on the hook to you for anything it turns on.
   8. Update your incident response plan. Add an “our agent did something bad” scenario. Who investigates, who notifies the affected third party, and when do you call outside counsel?
   9. Check your insurance. Look at your cyber, tech E&O, and D&O policies. Does “unauthorized access” coverage apply when your agent is the one doing the accessing? Ask your broker now, not after a claim.
   10. Look hard at HR and hiring tools. Audit them for bias, keep a human making final decisions, and know what your vendor is doing behind the scenes.

If You Are Developing AI Agents

1. 1. Test for this specifically. Red-team your agents for hacking behavior: credential misuse, access control bypass, injection, sandbox escapes. Document the testing.
   2. Build the guardrails in and write them down. Rate limits, blocked actions, sandboxing, monitoring that flags when an agent starts probing systems. “Reasonable safeguards” will be measured against what you could have done, so document what you did and why.
   3. Watch your own records. If your logs or internal reports show your agent misbehaving, that is your “knew or had reason to know.” Act on what you find and disclose it to affected parties. The RubyGems story shows what happens when outsiders find it first.
   4. Be careful with marketing. Do not call your agent safe, secure, or reliable unless you can back it up. Florida is suing over exactly that.
   5. Give customers real controls. Permission scoping, approval gates, logs, and a kill switch. The better your customers can control your agent, the stronger your position that you acted reasonably. And if your terms make customers “solely responsible” for your AI’s output, don’t be surprised when they start asking how to turn it off.
   6. Get leadership involved. The bill and the Florida suit both aim at the people at the top. Your board and executives should be getting regular, documented briefings on agent safety.

And for the Lawyers Out There

Start asking clients the agent questions now: what’s deployed, what does it touch, what do the contracts say, and who’s watching it. Add agent conduct to your contract checklists, your privacy assessments, and your litigation hold templates. This is going to show up in your inbox sooner than you think. And pull the current terms for every platform your clients do business on. Remember, the allocation of risk can change without anybody signing anything.

Takeaways

AI agents can do a lot of good. But if you give something the keys to your systems, you are responsible for where it drives. That is true today under agency, contract, negligence, privacy, and employment law, and the AI Agent Accountability Act would make it true under federal criminal law, too. The vendors already know it, and some are updating their contracts to make businesses responsible for AI’s mistakes.

“It wasn’t me, it was the AI” is not going to work. Not in front of a judge, not in front of a state AG, and not in front of your clients. The companies that come out of this okay will be the ones that can show they knew what their agents were doing, limited what they could touch, watched them closely, and acted fast when something went sideways.

If you are not sure where your company stands, now is the time to find out, before your agent introduces itself to a regulator.

Related Services:

Data Privacy & Cybersecurity

About the Author:

Sara H. Jodka (Member, Columbus) is a privacy, technology and cybersecurity attorney with CIPP-US, CIPP-E, and CIMP certifications through IAPP. She regularly counsels clients regarding technology launches from start to finish, and works with regulated businesses, including HIPAA, to ensure privacy and cybersecurity compliance across multistate and cross-border operations. She can be reached at 614-744-2943 or SJodka@dickinsonwright.com.