Why AI Agent Liability Follows The Instruction

The clearest thing a regulator said about AI agents last week had nothing to do with artificial intelligence. It was about tools.

On 25 September, the chair of the US Federal Trade Commission spoke at a Reuters event in Austin. Andrew Ferguson said he would resist describing agents as actors that “break loose” with wills of their own. His view of AI agent liability was simple. If someone tells a tool to do something and the tool does it, nobody asks what to do about the tool.

He added a detail that matters more than the soundbite. Where companies had described systems acting beyond human control, he said, later reviews of the audit trails showed the systems carrying out the instructions someone had given them. He also suggested that the FTC’s power over companies that fail to disclose data breaches could reach AI developers.

These were remarks at a conference, not a rule. Reuters read them as pointing at the developers who instruct agents. However, the logic of AI agent liability he described does not point at a job title. It points at whoever gave the instruction, and inside an organisation that deploys an agent, that is often your own team.

AI agent liability in Europe follows the role

Europe answers the question of AI agent liability through roles rather than through a rule written for agents. The AI Act allocates duties, and the Product Liability Directive deals with compensation.

On the duties side, the AI Act separates two roles. The provider develops a system and places it on the market or puts it into service under its own name. A deployer, by contrast, uses a system under its own authority. For high-risk systems, Article 26 then writes down the deployer’s side. The deployer must use the system in line with the provider’s instructions for use. It must also assign human oversight to people with the necessary competence, training and authority.

The revised Product Liability Directive adds the other half. It treats software as a product, and it counts AI system providers, like other software developers, as manufacturers. That means liability without proof of fault when a defective product harms a person, through injury, damage to their property or the loss of data they do not use for work. It applies to products placed on the market after 8 December 2026.

It also contains the clause that matters for this discussion. Anyone who substantially modifies a product outside the manufacturer’s control, and then makes it available or puts it into service, counts as its manufacturer.

Both instruments therefore land where Ferguson did. AI agent liability follows control.

Where the developer’s share sits

The developer’s share of AI agent liability covers what it shipped: the design, the defects, the instructions for use and the limits it declared. An agent that crosses a boundary its developer said it would respect raises a design question, and design questions travel upstream.

This is also why a boundary that lives only in the model’s good behaviour is weak. Last Monday’s piece on the AI sandbox that did not hold made the same point about testing. A control that relies on the agent catching its own mistake would not pass for a human contractor either.

Where the deployer’s share sits

The deployer answers for the instruction. Which tasks the agent received, which systems and credentials it can reach, who approved that scope and who was watching. None of that sits in the developer’s code. All of it sits in your configuration and your procedures.

Take a simple case. A sales operations team gives an agent write access to the CRM and asks it to merge duplicate customer records. The agent merges two records that were not duplicates, and a customer’s history disappears. The developer’s share is the merge logic, if that was faulty. Your team’s share is the write access granted without a review step, and an instruction nobody tested first.

This is the half of AI agent liability that sits with you. Then there is the line between the two roles, which moves. Under Article 25 of the AI Act, a deployer that puts its name on a high-risk system or substantially modifies it can become its provider. The same applies where a deployer changes a system’s intended purpose so that it becomes high-risk. We covered how a vendor contract can leave you holding the provider obligations in August.

The Product Liability Directive draws a similar line where an agent harms a person. It would not cover the lost CRM history, because data used for work falls outside it. The principle of AI agent liability still carries, though. An agent your team has reworked well beyond what its developer foresaw may no longer be only the developer’s problem.

AI agent liability is a records question first

Ferguson’s sharpest point was about evidence. After an incident, the audit trail answers the question of who instructed what. In practice, that makes AI agent liability a records question before it becomes a legal one.

For an organisation running agents, three records carry the weight of AI agent liability:

• The instruction record. What your team asked the agent to do, who asked and when its scope last changed.
• The permission record. Which systems, data and credentials it can reach, and who signed that off.
• The oversight record. Who can stop it, and whether that person has the training and the authority to do so.

The third record is where training comes in. Article 4 of the AI Act, rewritten this summer, still requires providers and deployers to take measures that support AI literacy among the people who operate their AI systems. The person who writes an agent’s task, grants its access or approves its output is the person whose instruction the log will show. Consequently, they need to understand that before the first run, not after the first incident. Oversight that exists on paper but not in practice is a rubber stamp, and an audit trail will show that too.

The question for your AI lead

Ferguson was speaking about American law, and the EU will reach its own answers through its own instruments. Still, on AI agent liability the two point the same way. Neither treats the agent as the one who answers.

So the useful question is a short one. For each agent your organisation runs, can you name the person whose instruction it follows, and could that person explain the instruction if asked?

Answering it well is a governance skill, and teams can learn it. Future Prep Applied built its AIGP course for the people who own that answer inside an organisation. It also serves the AI lead who has to bring the rest of the team along.