Who is accountable when an AI agent makes a mistake?
The person or team who deployed the agent owns what it does. An audit trail of who approved each action is how you prove it.
The person or team who deployed the agent is accountable for what it does. An agent is a tool you pointed at a task, so a bad outcome traces back to whoever ran it, configured it, and approved the steps it took. The practical version of accountability is a record: who started the agent, what it tried to do, and who approved each action that had a real effect.
This is not legal advice, and the precise answer for your company depends on contracts, policy, and jurisdiction. But the operational stance is steady across all of them. Software does not absorb blame. The humans around it do, so the useful question is rarely "who is at fault" in the abstract. It is "can you show what happened and who signed off."
Key takeaways
- An AI agent has no accountability of its own. Responsibility sits with the person or team who deployed it, the same as any tool they run.
- Accountability in practice is a record: who started the agent, what it did, and who approved each action with a side effect.
- Without an approval trail, "the agent did it" is unfalsifiable. With one, every consequential action has a name attached.
Why the agent itself is never the answer
An agent does not own assets, sign contracts, or face consequences. When a deploy goes wrong or a file gets deleted, the chain of responsibility runs back through the person who launched the agent, the person who set its permissions, and the person who approved the specific step. Calling the agent autonomous does not move accountability onto it. It just makes the human chain harder to see.
That is the real risk of running AI agents unsupervised. They are rarely malicious. The problem is that they let everyone point at the software. "The agent did it" only works as an excuse if nobody can reconstruct who let it.
Accountability is a record, not a feeling
If you cannot answer three questions after the fact, you do not have accountability, you have a story.
- Who started this agent and on what task?
- What did it actually do, step by step?
- Who approved the action that caused the problem, and through which channel?
Each of those needs to be recorded at the moment it happens, not reconstructed from memory. A chat log of the agent's reasoning is not enough, because reasoning is not the same as the action that hit production. You want the action, the decision on it, and the human attached to that decision.
Human-in-the-loop is what creates a name to attach
A record is only meaningful if a human was in the path for the actions that matter. That is the point of putting approvals on consequential steps: the agent pauses before it pushes, deploys, deletes, or spends, a person says yes or no, and that answer becomes part of the record.
Pushary runs this on CLI agents (Claude Code, Codex, Gemini CLI, Cursor, Hermes) through a hook that gates the tool before it runs. The agent stops, you get a push notification, and nothing with a side effect happens until a person answers. The approval is a logged event with a source: phone, web, or Slack. So the record shows more than "this was approved." It shows who approved it, from which channel, and when. More on the model in the human-in-the-loop docs.
For the actions you do not want a human approving every time, a permission policy draws the line by command and arguments, so reads run on their own and writes, pushes, and spends stop for a person. The auto-approved read-only floor was decided from 1,721 real production questions, the commands that were read-only every single time. Auto-approving those keeps your attention on the prompts that carry consequences.
What an audit trail actually has to show
A useful trail is not a log dump. For each session it should show the structured tool actions, a what-changed view, and an answer-source record for every decision, all exportable. That is the difference between "we think the agent did roughly this" and a per-session receipt you can hand to a teammate or an auditor.
See the audit trail page for the shape of it and the audit log docs for what gets captured. On data handling, the security page is honest about the limits: Pushary is GDPR-aligned but self-assessed, with no SOC2 or ISO certification, so the trail is evidence of who decided what, not a compliance seal.
One real caveat. The Claude Desktop connector can notify and ask but cannot block a tool, because Desktop has no hook to gate at. So on Desktop the trail records the notification and the answer, but enforcement is voluntary. Enforced gating is a CLI feature, worth knowing before you lean on it for accountability.
Common questions
Who is legally responsible when an AI agent makes a mistake?
In practice, responsibility falls on the person or organization that deployed and operated the agent, the same as for any tool they run. The exact legal answer depends on your contracts, policy, and jurisdiction, so treat this as the operational default and not legal advice. What you can control is the evidence: a record of who approved each consequential action.
Can you blame the AI vendor or the model?
Usually not for how you used it. The model maker is responsible for the model, but the decision to point an agent at your production system and grant it permissions is yours. That is why the deploying team carries the operational accountability, and why a record of your own approvals matters more than where the model came from.
How do you prove a human approved an action?
You log the approval as an event with a source and a timestamp at the moment it happens. Pushary records every decision with its channel (phone, web, or Slack), so each consequential action has a named approval behind it rather than a guess after the fact.
Accountability comes down to who can be named when something goes wrong, and that requires the agent to pause for a person and the decision to be recorded. See how the audit trail captures every approval, or put the gate and the record on your agents from pricing.