Your AI Agent Can Bind You to a Deal You Never Authorized
Who Pays for a Loss When an AI Agent is Liable
by
Teddy Ellison
AI & Data Agreements
Summary
AI agent liability has two layers that founders routinely collapse into one. A spending cap or merchant restriction you set in code controls what your agent is authorized to do, but it does not necessarily limit what a counterparty can hold your company to. Agency law separated those two questions before AI agents existed. An agent that transacts on your behalf can stay inside the cap you set and still commit you to a deal you never approved.
When an AI agent authorizes a payment or agrees to terms on your behalf, it is making a commitment in your company's name. Founders have been careful about what their agents are allowed to do, but founders may still be on the hook when an agent does something it was not supposed to and a counterparty has already acted on it.
AI agent liability is largely decided by two distinct, but often conflated, forms of authority. Actual authority is what you grant the agent. Apparent authority is what a counterparty reasonably believes the agent can do, built from what your product showed them. The company can be held to what the counterparty believed even when it set the agent's actual authority with care.
Authority is not the only body of law in play once the agent moves money. A bank can push the loss of a bad payment order back onto you under the rules for funds transfers, and a founder selling into the EU can face strict liability if the agent is part of a defective product. These questions run on law that predates AI agents by decades, and most teams building agents have not sorted out which ones apply to them.
What you control before the agent ships
Before an agent ships, the one thing a founder controls is its actual authority. That is the set of actions the founder has authorized the agent to take on the company's behalf, fixed by the spending caps, merchant restrictions, and context limits set in the product (Restatement (Third) of Agency §§ 2.01 and 2.02). When you cap the agent at a fixed amount, restrict it to a named merchant, or limit it to a defined task, you are drawing the boundary of what it is authorized to do. Inside that boundary the agent acts for you, and outside it the agent has no actual authority.
California's AB 316 (codified at Civil Code § 1714.46, effective January 1, 2026) removes the founder's fallback defense. A defendant who developed, modified, or used an AI system alleged to have caused harm can no longer argue the system acted on its own. The statute removes a defense rather than creating liability, so a plaintiff still proves causation and foreseeability, and it sets no strict-liability standard.
A Florida jury already put a number on the blame-the-system posture in Benavides v. Tesla, a $243 million verdict with $200 million of it punitive, and the trial court denied Tesla's post-trial motions in February 2026 with the case now on appeal. AB 316 turns that jury instinct into a rule a defendant cannot argue around.
A dated, specific record of what the agent may do, and against which limits, is what lets you prove the authorization if a transaction is ever challenged. Without it, you are asking a court to infer what you authorized from your source code, which is a far weaker place to argue from than a document you can hand over.
Where the counterparty's belief takes over
The limits you set are visible only inside your company. Apparent authority depends on what the counterparty reasonably believed the agent could do, and the counterparty builds that belief from what your product showed them. The cap in your code is not automatically part of that belief.
Apparent authority is the power an agent has to bind a principal when a third party reasonably believes the agent is authorized, and that belief traces back to the principal's own conduct (Restatement (Third) of Agency § 2.03). For an AI agent, the belief is built from what your product presented to the counterparty, not from the instruction buried in your code. If your product holds the agent out as able to transact for your company, and nothing the counterparty can see contradicts that, the counterparty's belief can bind you to a deal the agent had no actual authority to make.
UETA § 14 confirms that a contract can form through the actions of an automated agent even when no person reviewed the terms. It does not decide whether you are bound when the agent acts outside its scope, and that question goes back to agency law.
The company ends up bound to a transaction the founder never authorized, because the limit lived in the code and nowhere the counterparty could see it. The only thing that would have changed the result is putting that limit somewhere the counterparty could see before the agent acted.
What changes when the agent moves money
An agent that settles payments or signs contracts on its own is past the point you should handle without counsel. The question stops being whether a contract is formed and becomes who absorbs a real financial loss.
When an agent signs contracts or moves money on its own, the answer depends on your product, the counterparty, and the platform at the same time. Once money moves, a second body of law decides who absorbs a bad transfer, and it is not always the party whose authority was exceeded. A commercially reasonable security procedure can shift the loss of an unauthorized payment order onto you regardless of what your agent was authorized to do.
When your agent initiates funds transfers, UCC Article 4A governs the payment orders. Under §§ 4A-202 and 4A-203, if you and your bank agreed on a commercially reasonable security procedure and the bank accepts a payment order in good-faith compliance with it, then the order is treated as authorized and the loss of a fraudulent or unauthorized order can fall on you.
Platform terms create a second way to be bound, separate from your relationship with the user. A marketplace or payment platform your agent runs on can, through its own terms, treat your agent as authorized to act for you, and that treatment can bind you to the platform even if you told the user or the agent something narrower.
Founders with EU users face one more source of liability. The revised EU Product Liability Directive (Directive (EU) 2024/2853) treats software and AI systems as products subject to no-fault liability, and it applies to products placed on the EU market or put into service on or after December 9, 2026. If your agent is part of a product reaching EU users, a defect claim does not require proving your company was at fault.
A framework for founders
The expensive version of this problem does not come from founders who ignored the authority question. It comes from founders who answered the half they controlled, capped the agent in code, and assumed that settled it.
Knowing which decisions require a lawyer, which require careful self-review, and which are straightforward is what keeps that gap from opening in the first place. Our Tech Founder's DIY Legal Guide offers a general framework for how to approach these decisions, which we have translated to some agent-liability-specific guidance below.
What founders can handle themselves
You can define and document your agent's actual authority without a lawyer. Write down what the agent may do, against what caps, for which counterparties, and from what date, and keep the record where you could produce it if a transaction is ever questioned. The spending cap, the merchant allowlist, and the context limits are product decisions you are already making, and the only added step is writing them down as what they legally are (i.e. the authority you gave the agent).
You can also map, in plain terms, where your agent touches a third party. An agent that acts only inside your own systems carries less risk than one that transacts with outside counterparties or on someone else's platform. Sorting your agent's actions into those two groups is something you can do from your own architecture, and it tells you which sections above apply to you.
Where it gets complicated
It gets harder the moment the agent acts toward someone outside your company, because the limits you set stop deciding whether you are bound. Whether a counterparty who never saw your cap can still bind you depends on what your product presented and what that counterparty reasonably believed, which is a fact-specific read rather than a setting you can toggle.
Communicating your agent's authority limits to counterparties is the step that starts to constrain apparent authority, and almost no product does it today. How you surface those limits, whether in the interface, in the terms a counterparty accepts, or in the credential itself, is a design decision with legal consequences. Getting it right is worth a review before the agent is transacting at volume, not after the first disputed deal.
Where expert counsel becomes mandatory
An agent that moves money, signs contracts, or settles transactions on its own is past the point your own documentation can settle who is liable. The funds-transfer loss allocation under UCC Article 4A, the platform representations that can bind you independent of your user terms, and the EU product-liability regime for founders with EU users all interact, and getting one wrong is not something you can assess from your own records.
The question no US court has yet answered is whether scoping an agent's authority through a bank-issued single-use credential binds the principal under agency law or functions only as a spending cap. If your product depends on that scoping holding up as a legal limit, it needs a real analysis before you rely on it. Serotonin Legal works through exactly this kind of authority-and-liability mapping for founders building agents that transact autonomously.
For more on which legal decisions founders can handle on their own and which call for counsel, we answer the questions tech founders ask us most here.
Final Thoughts
The two authority questions were separated long before AI agents existed. An agent that transacts on your behalf can obey every limit you set and still bind you to a deal a counterparty can enforce, and you will not see it until a transaction is disputed.
The first reported US decision applying apparent authority to an AI-agent transaction will become the precedent every founder in this category has to build around, whether or not their product was designed for it. . If you are shipping an agent that moves money, transacts with outside counterparties, or relies on a scoped credential as a legal limit, reach out and we will give you a clear read on where you stand.
Serotonin Legal advises technology founders on corporate, regulatory, and transactional matters at the intersection of AI, blockchain, and fintech. This guide is for general informational purposes and does not constitute legal advice. No attorney-client relationship is formed by reading this material.
FAQs
Who is liable when an AI agent causes a loss?
Liability for an AI agent's loss runs to the people and companies behind the agent, never to the agent as an autonomous actor. Which of them is on the hook depends on the type of loss. For a transaction the agent entered, it depends on whether the agent had authority to bind the company and whether a counterparty reasonably believed it did. For a harm the agent caused, California's AB 316 forecloses the argument that the agent acted on its own, leaving the developer, deployer, or user to answer for it. The one answer never available is that the agent absorbed the liability itself.
Can an AI agent be a party to a contract?
An AI agent is not a legal party to a contract. It acts as an instrument of the person or company that deployed it, and any contract it forms binds that principal, not the agent. UETA § 14 confirms that a contract can form through an automated agent even when no human reviewed the terms, so the absence of a person in the loop does not stop a binding agreement from forming. What the agent cannot do is hold rights or owe obligations in its own name. The party on the hook is the company behind the agent, which is why the authority you gave the agent, and what a counterparty believed about that authority, decide what you are bound to.
What is the difference between a developer and a deployer under AI liability law, and which am I?
A developer builds or materially modifies the AI system, and a deployer puts it into use to act on users or third parties. Under California's AB 316, both are exposed, because the statute reaches anyone who developed, modified, or used an AI system alleged to have caused harm, and none of them can defend by pointing to the agent's autonomy. Which label fits you is a factual question about what you built versus what you put into use, and many founders are both at once. The practical consequence is that being "only the deployer" does not move the liability off you the way founders often assume.
Can a company avoid liability by saying the AI acted on its own?
No, at least not in California. AB 316, effective January 1, 2026, makes that an unavailable defense, so a company sued over harm its AI system caused cannot escape by arguing the system acted autonomously. The statute does not make the company automatically liable for everything the agent does, since the plaintiff still has to prove the agent's action caused the harm and that the harm was foreseeable. What it removes is the specific argument that the agent, rather than the company, was the actor. Founders who assumed autonomy was a liability shield are building on a defense that no longer exists where the statute applies.
If my AI agent spends on a scoped, bank-issued card, does the scope limit its legal authority or just the dollar amount?
A scoped, bank-issued card limits the dollars your agent can spend, and whether it limits the agent's legal authority is a separate and unsettled question. Scoping the credential by amount, merchant, and context defines what you authorized the agent to do, which is actual authority. It does not by itself control apparent authority, which depends on what a counterparty reasonably believed based on what your product showed them. No US court has yet ruled on whether a scoped single-use credential binds the principal as a legal limit or functions only as a spending cap, so a founder relying on it as a legal boundary is relying on an open question.
Curious to learn more about Serotonin Legal? —
Get in Touch
Your AI Agent Can Bind You to a Deal You Never Authorized
Who Pays for a Loss When an AI Agent is Liable
by
Teddy Ellison
AI & Data Agreements
Summary
AI agent liability has two layers that founders routinely collapse into one. A spending cap or merchant restriction you set in code controls what your agent is authorized to do, but it does not necessarily limit what a counterparty can hold your company to. Agency law separated those two questions before AI agents existed. An agent that transacts on your behalf can stay inside the cap you set and still commit you to a deal you never approved.
When an AI agent authorizes a payment or agrees to terms on your behalf, it is making a commitment in your company's name. Founders have been careful about what their agents are allowed to do, but founders may still be on the hook when an agent does something it was not supposed to and a counterparty has already acted on it.
AI agent liability is largely decided by two distinct, but often conflated, forms of authority. Actual authority is what you grant the agent. Apparent authority is what a counterparty reasonably believes the agent can do, built from what your product showed them. The company can be held to what the counterparty believed even when it set the agent's actual authority with care.
Authority is not the only body of law in play once the agent moves money. A bank can push the loss of a bad payment order back onto you under the rules for funds transfers, and a founder selling into the EU can face strict liability if the agent is part of a defective product. These questions run on law that predates AI agents by decades, and most teams building agents have not sorted out which ones apply to them.
What you control before the agent ships
Before an agent ships, the one thing a founder controls is its actual authority. That is the set of actions the founder has authorized the agent to take on the company's behalf, fixed by the spending caps, merchant restrictions, and context limits set in the product (Restatement (Third) of Agency §§ 2.01 and 2.02). When you cap the agent at a fixed amount, restrict it to a named merchant, or limit it to a defined task, you are drawing the boundary of what it is authorized to do. Inside that boundary the agent acts for you, and outside it the agent has no actual authority.
California's AB 316 (codified at Civil Code § 1714.46, effective January 1, 2026) removes the founder's fallback defense. A defendant who developed, modified, or used an AI system alleged to have caused harm can no longer argue the system acted on its own. The statute removes a defense rather than creating liability, so a plaintiff still proves causation and foreseeability, and it sets no strict-liability standard.
A Florida jury already put a number on the blame-the-system posture in Benavides v. Tesla, a $243 million verdict with $200 million of it punitive, and the trial court denied Tesla's post-trial motions in February 2026 with the case now on appeal. AB 316 turns that jury instinct into a rule a defendant cannot argue around.
A dated, specific record of what the agent may do, and against which limits, is what lets you prove the authorization if a transaction is ever challenged. Without it, you are asking a court to infer what you authorized from your source code, which is a far weaker place to argue from than a document you can hand over.
Where the counterparty's belief takes over
The limits you set are visible only inside your company. Apparent authority depends on what the counterparty reasonably believed the agent could do, and the counterparty builds that belief from what your product showed them. The cap in your code is not automatically part of that belief.
Apparent authority is the power an agent has to bind a principal when a third party reasonably believes the agent is authorized, and that belief traces back to the principal's own conduct (Restatement (Third) of Agency § 2.03). For an AI agent, the belief is built from what your product presented to the counterparty, not from the instruction buried in your code. If your product holds the agent out as able to transact for your company, and nothing the counterparty can see contradicts that, the counterparty's belief can bind you to a deal the agent had no actual authority to make.
UETA § 14 confirms that a contract can form through the actions of an automated agent even when no person reviewed the terms. It does not decide whether you are bound when the agent acts outside its scope, and that question goes back to agency law.
The company ends up bound to a transaction the founder never authorized, because the limit lived in the code and nowhere the counterparty could see it. The only thing that would have changed the result is putting that limit somewhere the counterparty could see before the agent acted.
What changes when the agent moves money
An agent that settles payments or signs contracts on its own is past the point you should handle without counsel. The question stops being whether a contract is formed and becomes who absorbs a real financial loss.
When an agent signs contracts or moves money on its own, the answer depends on your product, the counterparty, and the platform at the same time. Once money moves, a second body of law decides who absorbs a bad transfer, and it is not always the party whose authority was exceeded. A commercially reasonable security procedure can shift the loss of an unauthorized payment order onto you regardless of what your agent was authorized to do.
When your agent initiates funds transfers, UCC Article 4A governs the payment orders. Under §§ 4A-202 and 4A-203, if you and your bank agreed on a commercially reasonable security procedure and the bank accepts a payment order in good-faith compliance with it, then the order is treated as authorized and the loss of a fraudulent or unauthorized order can fall on you.
Platform terms create a second way to be bound, separate from your relationship with the user. A marketplace or payment platform your agent runs on can, through its own terms, treat your agent as authorized to act for you, and that treatment can bind you to the platform even if you told the user or the agent something narrower.
Founders with EU users face one more source of liability. The revised EU Product Liability Directive (Directive (EU) 2024/2853) treats software and AI systems as products subject to no-fault liability, and it applies to products placed on the EU market or put into service on or after December 9, 2026. If your agent is part of a product reaching EU users, a defect claim does not require proving your company was at fault.
A framework for founders
The expensive version of this problem does not come from founders who ignored the authority question. It comes from founders who answered the half they controlled, capped the agent in code, and assumed that settled it.
Knowing which decisions require a lawyer, which require careful self-review, and which are straightforward is what keeps that gap from opening in the first place. Our Tech Founder's DIY Legal Guide offers a general framework for how to approach these decisions, which we have translated to some agent-liability-specific guidance below.
What founders can handle themselves
You can define and document your agent's actual authority without a lawyer. Write down what the agent may do, against what caps, for which counterparties, and from what date, and keep the record where you could produce it if a transaction is ever questioned. The spending cap, the merchant allowlist, and the context limits are product decisions you are already making, and the only added step is writing them down as what they legally are (i.e. the authority you gave the agent).
You can also map, in plain terms, where your agent touches a third party. An agent that acts only inside your own systems carries less risk than one that transacts with outside counterparties or on someone else's platform. Sorting your agent's actions into those two groups is something you can do from your own architecture, and it tells you which sections above apply to you.
Where it gets complicated
It gets harder the moment the agent acts toward someone outside your company, because the limits you set stop deciding whether you are bound. Whether a counterparty who never saw your cap can still bind you depends on what your product presented and what that counterparty reasonably believed, which is a fact-specific read rather than a setting you can toggle.
Communicating your agent's authority limits to counterparties is the step that starts to constrain apparent authority, and almost no product does it today. How you surface those limits, whether in the interface, in the terms a counterparty accepts, or in the credential itself, is a design decision with legal consequences. Getting it right is worth a review before the agent is transacting at volume, not after the first disputed deal.
Where expert counsel becomes mandatory
An agent that moves money, signs contracts, or settles transactions on its own is past the point your own documentation can settle who is liable. The funds-transfer loss allocation under UCC Article 4A, the platform representations that can bind you independent of your user terms, and the EU product-liability regime for founders with EU users all interact, and getting one wrong is not something you can assess from your own records.
The question no US court has yet answered is whether scoping an agent's authority through a bank-issued single-use credential binds the principal under agency law or functions only as a spending cap. If your product depends on that scoping holding up as a legal limit, it needs a real analysis before you rely on it. Serotonin Legal works through exactly this kind of authority-and-liability mapping for founders building agents that transact autonomously.
For more on which legal decisions founders can handle on their own and which call for counsel, we answer the questions tech founders ask us most here.
Final Thoughts
The two authority questions were separated long before AI agents existed. An agent that transacts on your behalf can obey every limit you set and still bind you to a deal a counterparty can enforce, and you will not see it until a transaction is disputed.
The first reported US decision applying apparent authority to an AI-agent transaction will become the precedent every founder in this category has to build around, whether or not their product was designed for it. . If you are shipping an agent that moves money, transacts with outside counterparties, or relies on a scoped credential as a legal limit, reach out and we will give you a clear read on where you stand.
Serotonin Legal advises technology founders on corporate, regulatory, and transactional matters at the intersection of AI, blockchain, and fintech. This guide is for general informational purposes and does not constitute legal advice. No attorney-client relationship is formed by reading this material.
FAQs
Who is liable when an AI agent causes a loss?
Liability for an AI agent's loss runs to the people and companies behind the agent, never to the agent as an autonomous actor. Which of them is on the hook depends on the type of loss. For a transaction the agent entered, it depends on whether the agent had authority to bind the company and whether a counterparty reasonably believed it did. For a harm the agent caused, California's AB 316 forecloses the argument that the agent acted on its own, leaving the developer, deployer, or user to answer for it. The one answer never available is that the agent absorbed the liability itself.
Can an AI agent be a party to a contract?
An AI agent is not a legal party to a contract. It acts as an instrument of the person or company that deployed it, and any contract it forms binds that principal, not the agent. UETA § 14 confirms that a contract can form through an automated agent even when no human reviewed the terms, so the absence of a person in the loop does not stop a binding agreement from forming. What the agent cannot do is hold rights or owe obligations in its own name. The party on the hook is the company behind the agent, which is why the authority you gave the agent, and what a counterparty believed about that authority, decide what you are bound to.
What is the difference between a developer and a deployer under AI liability law, and which am I?
A developer builds or materially modifies the AI system, and a deployer puts it into use to act on users or third parties. Under California's AB 316, both are exposed, because the statute reaches anyone who developed, modified, or used an AI system alleged to have caused harm, and none of them can defend by pointing to the agent's autonomy. Which label fits you is a factual question about what you built versus what you put into use, and many founders are both at once. The practical consequence is that being "only the deployer" does not move the liability off you the way founders often assume.
Can a company avoid liability by saying the AI acted on its own?
No, at least not in California. AB 316, effective January 1, 2026, makes that an unavailable defense, so a company sued over harm its AI system caused cannot escape by arguing the system acted autonomously. The statute does not make the company automatically liable for everything the agent does, since the plaintiff still has to prove the agent's action caused the harm and that the harm was foreseeable. What it removes is the specific argument that the agent, rather than the company, was the actor. Founders who assumed autonomy was a liability shield are building on a defense that no longer exists where the statute applies.
If my AI agent spends on a scoped, bank-issued card, does the scope limit its legal authority or just the dollar amount?
A scoped, bank-issued card limits the dollars your agent can spend, and whether it limits the agent's legal authority is a separate and unsettled question. Scoping the credential by amount, merchant, and context defines what you authorized the agent to do, which is actual authority. It does not by itself control apparent authority, which depends on what a counterparty reasonably believed based on what your product showed them. No US court has yet ruled on whether a scoped single-use credential binds the principal as a legal limit or functions only as a spending cap, so a founder relying on it as a legal boundary is relying on an open question.
Curious to learn more about Serotonin Legal?
Get in Touch
