Your AI agent took the action. Who’s accountable when it goes wrong?

An agent issues a refund it shouldn’t have approved. Or changes a customer’s account. Or deletes data while trying to finish a task. Who owns that decision—and can they explain what actually happened? That’s the part of the agent conversation I think deserves more attention as we move from demos into production. We’re giving software more authority to act. That makes the permissions, contracts and accountability around it much more consequential. Buying access to a model doesn’t automatically mean the vendor accepts responsibility for everything you let an agent do. The actual allocation depends on the agreement, the circumstances and the applicable law. “The AI did it” is a weak operating strategy. But I don’t think the answer is to make a human approve every mouse click. That defeats much of the purpose. The question is how to give agents useful freedom inside limits the business can enforce. A prompt is a request, not a permission. “Never refund more than $100 without approval” might be a perfectly clear instruction. But if the agent has credentials that allow it to refund $10,000 directly, the instruction and its actual authority are different things. For consequential actions, I’d want five things: Enforced limits: The system executing the action checks whether it is permitted. A named decision-maker: Actions that need approval go to someone who can inspect exactly what is proposed. Limited access: The agent gets only the capabilities it needs, with secrets kept out of model context. Safe retry handling: A timeout doesn’t casually turn into a duplicate payment or message. Independent records: Evidence of authorization, approval and execution lives somewhere the agent cannot rewrite. There’s a practical catch: those controls only cover actions that pass through them. Another credential or execution path can leave a hole. Now imagine investigating that wrong refund. One team has a chat transcript saying the agent was told to be careful. Another can show the permission that applied, the approval decision, the exact request sent and the payment provider’s response. Neither record automatically settles legal liability. But one gives the business a much better basis for understanding the incident, correcting it and answering questions. That’s why I see governance as something that makes more autonomy possible. If you can define the boundaries and verify what happened, you have a stronger basis for giving an agent more responsibility. For people running agents in production: who owns their authority on your team? Is it engineering, security, the business owner, or someone else? And what happens when an agent needs to exceed its normal limits? Disclosure: I’m building a product in this space, so I have a commercial interest in the problem. I’m interested in how other teams handle it in practice.