Who pays when the AI agent makes a mistake? Liability and the approval step

Imagine an agent in your company answering a customer inquiry, confirming a delivery date, and in the process granting a discount that does not exist. Nobody saw the text beforehand, the customer has the commitment in writing, and the next morning management asks: who is accountable for this? That question is uncomfortable, and it is usually only asked once the incident has happened. This article asks it beforehand.

The occasion is a statement from the financial industry. On the quarterly earnings call of the US bank JPMorgan Chase on October 13, 2026, CEO Jamie Dimon, according to media reports, said that the bank currently does not allow external AI agents direct access to customer accounts. The sentence "There’s a liability transfer" came up in that context, meaning that a shift of liability takes place. The topic is therefore not a one-day event but an evergreen. In a single statement, it shows what matters for every agent with real authority: the question of what it may do on its own and where a human has to agree.

One important caveat up front: the case concerns an American major bank and its retail customers. It is no indication of how German, Austrian or Swiss banks or courts would decide. We use it as an illustrative example, not as legal advice. There is no product launch here; availability is therefore not relevant. This is about a concept that you can clarify today, independently of any vendor.

What JPMorgan actually said, according to the reports

Let us start with what the sources provide, and separate it from what they do not. The news site Let’s Data Science reported on October 13, 2026, citing CNBC, that JPMorgan is blocking external AI agents that access customer accounts directly and act there. Dimon reportedly described the situation as "too risky for clients and for JPMorgan." A spokeswoman reportedly confirmed to CNBC that external agents are currently not allowed to act on behalf of retail customers.

The second important point concerns login credentials. According to the report, the spokeswoman said: "we do not permit third parties to access accounts by obtaining customers’ banking credentials". Third parties may therefore not gain access by collecting a customer’s online banking credentials and logging in in that person’s name. According to the article, the rule applies to agents from external providers, not to all of the bank’s AI functions. A bank-owned application called "Smart Cash" is reportedly being tested.

The trade publication The Paypers adds a detail on October 15, 2026 that makes the difference between reading and acting tangible: the bank continues to support customer-authorized data sharing via open banking providers. Agents could therefore still read some data, such as account balances, if Plaid or another connector holds the credentials. They could not, however, send money or pay bills.

Then comes the sentence this article is about. According to the Banking Dive report cited by the source, Dimon warned customers who give an agent access to their accounts about the risks. He said: "There’s a liability transfer." A customer who gives a third-party agent their credentials may therefore, under certain circumstances, bear the consequences of what the agent does with them. In addition, there is Dimon’s warning about "rogue agents" that could potentially act in large numbers.

What the sources do not say

Care is warranted here, because a headline quickly turns into a legal claim. The two reports contain no written policy from the bank and no date from which it applies. They give no breakdown of liability between customer, agent provider and bank. They do not say whether the rule also applies to business customers; only retail customers are mentioned. They offer no figures or evidence on how many "rogue agents" have actually appeared; the warning is an assessment by the CEO. And they contain no legal evaluation. Anyone who concludes from the case that "in Germany, the customer would then be liable" goes beyond the sources.

The date of the statement also deserves a note. The reports date from October 13 and 15, 2026. The primary source is an oral statement in a call with analysts, which we know only through media reports. We therefore present it as something reported, not as the wording of a document.

The core question is not whether agents make mistakes. It is who pays for the mistake when nobody looked beforehand.

Why this is more than a banking topic for mid-sized companies

A mid-sized company usually has no customer accounts that an outside agent accesses. But it has something similar: mailboxes, a CRM, accounting, a shop system, a cloud with contracts. As soon as an agent works there with its own access, the same constellation arises as in the banking example, on a small scale. Someone has given the agent access. The agent acts. And if the result is wrong, then in case of doubt the person or company behind it, who granted the access, is the one answerable.

This becomes especially clear in three places. First, with money: an agent that can approve invoices or trigger payments can multiply a mistake within seconds. Second, with contracts: a draft is harmless, a commitment that has been sent is not. Third, with outbound customer communication: a reply that has been sent cannot be recalled, and the recipient is entitled to take it seriously.

There is also an organizational problem that appears in no report but will sound familiar to any managing director: diffuse responsibility. If nobody has determined who approves an agent, who manages its access and who decides when something goes wrong, then in practice management is liable, without having consciously taken that on.

The approval step: what it is and what it is not

An approval step is a deliberately built-in point in the process at which an action takes effect only after confirmation by a human. In technical terms, this is called human-in-the-loop. It is not a vote of no confidence in the technology but a division of labor: the agent prepares, and the human decides on whatever has an external effect or cannot be reversed.

A note on the state of the sources: the organization OWASP, which is known for security standards in software development, has according to its website published the "OWASP Top 10 for Agentic Applications for 2026"; the page is dated December 9, 2025 and describes the document as a "globally peer-reviewed framework that identifies the most critical security risks". That is the publisher’s own description. We could not read the content of the individual risks on this page, as it points to a downloadable document. We therefore quote nothing from it. If you want to go deeper into the security of agents, this document is a sensible starting point, one that you should download and read yourself.

What an approval step is not can also be stated. It is not a guarantee that the human actually looks. Anyone who clicks through every approval unread has in effect abolished the step but kept the responsibility. A good approval step therefore always involves a design question: what does the approving person get to see, how long do they have, and how easy is it to say no?

With and without an approval step: a comparison

The difference can be shown with a simple process, without our having to invent any figures. Take an agent that handles customer inquiries from the mailbox.

Without an approval step, the agent reads the inquiry, drafts the reply and sends it. The customer has it immediately. If the agent has quoted a price incorrectly, the price is in writing with the customer. The correction costs time, trust and possibly money, and nobody in the company saw the reply beforehand.

With an approval step, the agent reads the inquiry, drafts the reply and saves it as a draft. A human sees the draft, edits or confirms it, and only then does it go out. The effort is smaller than writing it by hand, but responsibility is clearly assigned. This is exactly how we describe it on amazing-agents.com: every agent runs within a defined framework with approval steps for critical actions, and emails, for example, are created as drafts, not sent directly.

The difference is not that the second process sounds safer. It is that in the second process, a named person made a named decision. In a dispute, that is the difference between "the agent did it" and "we approved it".

Which agent plays which role

On amazing-agents.com, we assign this topic to two agents that work at different ends of the question. The Code-Operator is described there as "bugs, fixes, pull requests with your approval". It shows the pattern in its simplest form: the agent proposes a change, a human approves it, and only then is it adopted. The Memory-Layer is described as "shared context across all agents", so that nothing has to be explained twice. For our topic it matters because it is the place where you can record which rules apply to all agents: what must be approved, who approves, and what is documented.

On permission management, our frequently asked questions say: you determine which agent accesses which systems, auditable and revocable at any time. And in the description of the control center where all agents come together: critical actions need your approval. These are commitments about our approach. They are not proof that a mistake can never happen, and we do not claim that.

The difference that matters in the end: an agent with limits and an approval step versus an agent that simply acts. The first costs some speed per transaction. The second saves that speed and shifts the risk to where nobody planned for it.

How we proceed in an audit

So that this does not stay abstract, we describe how we approach the question in an audit. We claim no figures and no references here; we describe a procedure that you can follow even without us.

Step one is an inventory of access. We list which systems an agent is supposed to touch: mailbox, CRM, accounting, file storage, shop. For each system, we record whether the agent should only read or also write. This list alone is new for many companies, because access has so far been granted one by one and without an overall picture.

Step two is sorting actions by their effect. We distinguish actions that have only an internal effect and can be reversed from actions that go outside or concern money, contracts and personal data. The second group gets an approval step; the first the agent may, as a rule, carry out on its own.

Step three is assigning the approval to a person. Not "the team" approves, but a named role with a deputy. This includes the question of what happens if nobody responds: the process waits; it does not continue automatically.

Step four is the log. Every action of an agent is recorded so that it can later be traced what happened, on whose approval and with what data. Without a log, nothing can be settled in a dispute; with a log, at least the question of fact can.

Step five is the legal review of the open points. How liability, data protection and contracts play out in an individual case is something we do not assess. That belongs with your legal counsel or your data protection officer. We prepare the questions so that this advice can be efficient.

What you can prepare this week

Since this is about a concept and not a product that you can use from today, what remains is preparation. The following steps need no vendor and no new software.

1. Write down what an agent can already do at your company today, or should be able to do soon. A list of ten lines is enough. Next to each line, note which system is touched.
2. Mark every line that concerns money, a contract or an outbound message. Exactly these lines need a named approving person before deployment.
3. Clarify who in your company is responsible for the agents’ access. If the answer is "everyone does it as it suits them", you have found your first action item.
4. Check your contracts with vendors and customers for statements on automated decisions. You do not have to assess them alone, but you should know where you need to ask.
5. Define what happens first when an action goes wrong. Who is informed, who stops the agent, who speaks with the person affected? A two-page procedure is enough and saves hours in an emergency.

Common objections

"That slows down automation." It slows it down where it can do the most damage, and nowhere else. Most actions of an agent are internal and reversible. No approval is needed there. The approval concentrates on the few places where a mistake becomes truly expensive.

"My employees click through everything anyway." That is a real risk, and the answer is design, not giving up on approvals. In the approval, show the essentials first, such as the amount, the recipient and whatever differs from the normal case. And make rejecting as easy as confirming.

"The vendor is liable, after all." Possibly, possibly not. The bank reports show precisely that liability can in practice be shifted when a customer gives credentials to an agent. How this applies to your contracts is stated in your contracts, not in this article. Check it before the case arises.

"We are too small for that." Small companies in particular rarely have a legal department that cleans up afterward. A one-page sheet of approval rules is cheaper than any rework.

Conclusion

The JPMorgan case is a US example, and it is reported second-hand. We draw no legal conclusions from it for your company. But it makes visible what every organization has to clarify that equips agents with real access: who may do what on their own, who approves, who bears the damage in case of doubt? Anyone who answers these questions before deployment has an agent with limits and an approval step. Anyone who answers them afterward has usually answered them under time pressure.

A brief overview of sources: Let’s Data Science, "JPMorgan blocks external AI account agents", October 13, 2026 (report citing CNBC and Banking Dive); The Paypers, "JPMorgan Chase blocks external AI agents from customer accounts", October 15, 2026; OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications for 2026", page date December 9, 2025.