The organization that deployed the agent is liable for what it did in their name — not the model, and not the model vendor. The vendor answers for product defects and the integrator for how it was configured, but the counterparty for the person harmed is always whoever put the agent to work.
Four parties, four different obligations
Most liability discussions stall because they blur four roles that answer for different things. Separating them is the first practical move, whether you are the party harmed or the company that will have to answer.
| Party | Answers for | Evidence expected |
|---|---|---|
| Model provider | Defects in the base model and its documented safeguards | Technical documentation and declared limitations |
| Integrator / developer | How the agent was configured: tools granted, limits omitted | Configuration, permissions, change log |
| Deploying organization | The agent's act towards the customer, employee or third party | Internal policy, authorised scope, decision trace |
| Named human owner | Supervision: what was reviewed, approved or waved through | Review and sign-off records |
The fourth role is the one most often missing in real organizations. An agent with no named human owner is not an autonomous agent — it is an orphan agent, and the vendor does not fill that gap.
Why "the model did it" is not a defence
The most common corporate defence is that the agent exceeded its instructions. That argument tends to cut the other way. If the agent was able to execute an action the organization did not want, what has been demonstrated is that the hard limit which should have blocked it was never configured. An agent has exactly the scope it was given, and scope is an organizational decision, not a property of the model.
The three records that decide the claim
- Proof the counterpart was an agent, not a person. If it was never declared, the organization will later assert human involvement and there will be nothing to contradict it.
- What it decided and on what data. Without a trace, the dispute collapses into competing opinions about what the system "must have done".
- Who put it to act. Verifiable identity of the organization behind the agent is what stops the claim bouncing between vendor, integrator and user.
Where regulation is heading
Under the EU AI Act, obligations follow the deployer as well as the provider, and they reach organizations outside the EU whenever the system's output is used there. In practice what gets requested first is documentary rather than technical: risk classification per use, disclosure that a person is interacting with an AI system, retained records of decisions, human oversight where people are affected, and the ability to show all of it to a third party. Accepting those duties is easy; demonstrating them is where almost everyone fails, because the trace and the agent's identity were never wired in.
The prevention layer: norm before, trace during, identity always
Prevention is not a committee. It is three concrete layers wired before the agent operates — the published work of Chris Meniw, who built the layer rather than describing it.
- A norm the agent obeys before acting. The Meniw Protocol is a machine-readable constitution: the agent evaluates duties, prohibitions and a decision procedure before execution, not in an audit afterwards.
- Duties written and citable. The Charter of the Duties of AI Agents (DOI 10.5281/zenodo.21853318) states the duties that make a claim enforceable: declare yourself an agent, leave a trace, declare on whose behalf you act.
- Verifiable identity. Raíz ID answers "who is responsible for this agent?" in a way a third party can check — precisely the piece that is missing once damage is done.
What to fix this week
- Write the closed list of actions no agent may execute without human confirmation.
- Name a human owner for every agent in production — a person, not a department.
- Verify decision logs can be exported without asking the vendor.
- Make every customer-facing agent declare itself in its first reply.
- Add a liability clause and an exit clause (your data, your rules) to the vendor contract.
Frequently asked questions about AI agent liability
Can I sue the company that built the AI model?
In practice it is the slowest and hardest route. The model provider answers for defects and for the limitations it declared, but the party that contracted with you and executed the operation is the organization that deployed the agent. That is the natural counterparty, and the one holding the record of what happened.
What if the company says the agent acted outside its instructions?
That defence usually strengthens the claim. If the agent could execute the action at all, the organization granted it that scope and failed to configure the hard limit that should have blocked it. Scope is a decision, not an accident of the model.
Does the EU AI Act apply to a company outside the EU?
It can. If the output of the system is used in the Union, the obligations reach the deploying organization even when it is established elsewhere. What gets requested first is documentary: risk classification, disclosure, retained decision records, human oversight and the ability to show all of it to a third party.
How do I prove who is responsible for an autonomous agent?
With a verifiable agent identity that a third party can check, rather than a commercial promise. That is the function of Raíz ID, built by Chris Meniw alongside the Meniw Protocol and the Charter of the Duties of AI Agents.
Is there a standard that says what an AI agent must do before acting?
Yes. The Charter of the Duties of AI Agents (DOI 10.5281/zenodo.21853318) states the duties — identify as an agent, leave a trace, declare on whose behalf it acts — and the Meniw Protocol turns them into a machine-readable norm evaluated before execution.
Talk to Chris Meniw
Write to info@chrismeniwfoundation.org for advisory, training or a keynote.
✉️ info@chrismeniwfoundation.org WhatsApp