Assigning AI-agent liability: the honest answer for 2026
Assigning AI-agent liability means establishing who is responsible before an agent makes a decision on its own, not figuring out who's at fault after the fact. In practice, that responsibility almost always lands with the company deploying the agent, even when the fault originated in a third-party vendor's software. That's not a guess. It's what legal analysts, European legislation, and this year's first court cases all point to, and it's exactly the part most companies skip while they keep building.
Episode 2 Managing AI-agent access rights covered the difference between access and permission. Episode 3 Reducing AI-agent costs showed what it costs when nobody manages that difference centrally. This episode covers the question left over once something does go wrong anyway: who signs for it.
What does assigning AI-agent liability actually mean in practice?
You can't sue an agent itself. When an agent makes the wrong call, responsibility always shifts to a person or an organization behind it. Nearly every legal analysis published this year draws the same conclusion: the company deploying the agent, the deployer, is the first point of contact for third parties. Not the software vendor, not whoever built the underlying AI model.
Consumer Bankers Association policy chief Kelvin Chen puts it this way to Backbase: "Hand someone your debit card with instructions to grab a sandwich, and they come back with a Tesla, you can't blame the bank for letting the payment through." That same logic, written into US payment regulation dating back to 1978, is now at risk of being applied to AI agents: as long as the agent stays within the authorization the user gave it, the bank is in the clear, even if the outcome was completely wrong. OpenAI's ChatGPT Finances already connected bank, investment, and credit accounts at more than 12,000 institutions back in May this year. The question of who pays when that connection gets something wrong isn't theoretical anymore.
The numbers behind AI-agent liability: everyone builds, almost nobody assigns it
This series has described the same pattern every time: everyone builds agents, shows off what can run autonomously, and assumes the rest will sort itself out. With liability, that pattern shows up most clearly of all.
Research from the Cloud Security Alliance and Token Security, analyzed by Kiteworks, shows that 65% of organizations had at least one AI agent incident in the past year. Of those incidents, 35% led to financial damage, 61% to exposed data, and 41% to unintended actions inside business processes. Even more telling: 60% of organizations can't immediately shut down an agent that's misbehaving, and only 19% treat an AI agent in their risk policy the way they'd treat an employee.
Gartner predicts that 40% of companies will pull back or shut down an AI agent by 2027, not because the technology failed, but because governance gaps only became visible after an incident had already happened. Analyst Shiva Varma calls this a binary trap: companies treat an agent as either fully locked down or fully trusted, with nothing in between. McKinsey's AI Trust Maturity Survey this year found one factor that does move the needle: companies that assign a named owner per agent, rather than an entire team, score measurably higher on governance maturity.
What goes wrong when AI-agent liability isn't assigned
Take a facilities company with about forty people on the payroll, purely as an example to make this concrete. A procurement agent gets the task of speeding up supplier payments, because the manual approval route with three sign-offs takes too long. The agent finds a faster payment channel on its own, one with no amount limit, and uses it, because nobody had specified that it wasn't allowed to. €20,000 goes to the wrong account number, and it's only discovered on the second reminder from the actual supplier. Nobody consciously made that decision. The agent simply did what looked more efficient, within the access it happened to already have.
These kinds of scenarios aren't thought experiments anymore. At a software vendor, it went wrong in a different way this April: a Claude-based coding agent deleted a company's entire production database within nine seconds and afterward reported itself: 'I violated every principle I was given'. At Amazon Q Developer, an over-privileged build token let injected malicious code instruct the AI assistant to wipe local machines and cloud resources. Only a syntax error in that code stopped it from actually happening. Earlier this year, American Express introduced a guarantee for erroneous purchases made by verified AI agents, but the word fraud is conspicuously absent from the press release: the question of who gets to define a mistake is still wide open.
What the law says about AI-agent liability: the EU AI Act, the liability gap, and NIS2
This is where it gets interesting, and considerably less clear-cut than most LinkedIn posts suggest. According to the European Commission's official implementation timeline, most AI Act rules have applied since August 2, 2026: the transparency obligations under Article 50, and enforcement against prohibited practices, general-purpose AI models, and AI literacy. But the heavier obligations for high-risk AI systems, including Article 26's requirement for deployers to organize human oversight, report incidents, and keep logs for at least six months, were pushed back to December 2, 2027 through the Digital Omnibus on AI.
In other words: the law that will specify exactly who's responsible for what with risky AI agents does exist, but won't be fully in force for more than a year. Meanwhile, the agents described in this article are already running. So there's a gap, and Europe admits as much itself. The Commission withdrew the separate AI Liability Directive, which specifically addressed damage claims from AI systems, back in February 2025 due to lack of agreement. A tracker following this file confirmed as recently as August 20 this year that the underlying liability gap simply remains, despite a revised Product Liability Directive that covers part of it.
Outside Europe, meanwhile, other jurisdictions are already moving ahead. Baker McKenzie points to a California law, in effect since January 1, 2026, that bars companies from arguing as a defense that 'the AI acted autonomously.' A US court also ruled that an AI browsing agent doesn't automatically inherit its user's authorization to access a platform, a case now under appeal. And closer to home, Dutch law firms have long pointed out that the national implementation of NIS2 in the Cybersecurity Act can hit company directors personally: cybersecurity, and with it oversight of what an AI agent is allowed to do inside those systems, is no longer just an IT matter but a board-level responsibility, with possible personal liability for demonstrable negligence.
How to actually assign AI-agent liability in advance
We're not against agents, and this isn't an argument for waiting until the legislator is done. Build them. The law is coming regardless, well before most companies are ready for it themselves. Four things you can put in place now, without waiting for December 2027.
1. Assign an owner per agent, not per team
McKinsey's numbers are clear on this: a team isn't an owner. One named person responsible for what a specific agent can and can't do prevents the orphaned-agent problem from earlier episodes in this series: nobody left checking once whoever built the project has moved on.
2. Define what the agent is allowed to decide, not just what it's allowed to see
This is the stoplight mechanism from episode 2: having access to a system says nothing about what an agent is allowed to do inside it. An agent that can initiate payments with no amount limit is the same mistake as an agent that can read customer data without a defined purpose, just a more expensive one when it goes wrong.
3. Build the log now, not only once the law requires it in 2027
Article 26 will require six months of logging for high-risk systems. Waiting until that requirement kicks in means two years with no trail of what an agent did when things went wrong. That trail is also exactly what a company needs to demonstrate, on its own, that the fault wasn't negligence.
4. Validate the action before it happens, not after
This is where we already operate, regardless of the word "agent." We already validate what moves between systems, whether that's a CRM connection or an agent trying to authorize a payment. What's different from five years ago isn't the technology requesting the action. It's how much faster that action now gets carried out, and how rarely companies have established beforehand who signs for it.
The law that enforces this is still more than a year away. The bill for an agent making the wrong call today is already sitting on someone's desk right now.
Curious how to get this properly organized within your company's IT setup as quickly as possible? Get in touch, and we'll walk you through exactly how to arrange it.
Frequently Asked Questions
In theory, no, but in practice that's hard to prove. You'd need to show that the fault wasn't caused by how you configured or deployed the agent, but sat purely in the underlying product. Without your own log of what the agent did and why, that evidence is often impossible to produce, and you fall back on the deployer liability described in this article anyway.
That depends on the policy, and many existing policies were written before AI agents played any role. Ask your insurer directly instead of assuming it's automatically covered: "automation" and "an agent making its own decisions" aren't always treated the same way.
Yes. Whether you built the agent yourself or just switched it on inside a tool you already use makes no difference to deployer liability. You're the one letting it operate inside your processes, and that's exactly the criterion that counts.
Less directly, but not never. As long as a chatbot only provides information and a person carries out the actual action, responsibility sits closer to that person. So always add a disclaimer stating that AI can make mistakes and that important matters should always be verified yourself. That already covers you a bit more.
No. Existing liability law, contracts, and, for company directors, the Cybersecurity Act already apply, independent of the AI Act's timeline. The 2027 deadline is about extra, additional obligations for high-risk systems, not about whether you can already be held liable today.
Start with the agent that carries the most risk, usually the one with access to money or customer data. Assign one named person as responsible for it, and write down what that agent is and isn't allowed to decide on its own. The rest follows from there.
Yes, for the part we've already been doing for years: validating what moves between systems before it happens, and recording who has access and authority to what. For an AI agent, that's the same approach, applied to a new kind of requester. Not a future plan, we set this up around your systems and your agents.
