Who is accountable when an AI agent is allowed to act?

The question is not whether an AI agent will make a mistake. It will.

The more useful question is what happens when it does. Can we identify who gave the agent authority, what that authority covered, and which person or organization must answer for the consequences?

We often talk about an agent as if it were an employee. The comparison is useful up to a point. An employee has a role, a manager, and a place in an organization’s accountability structure. An agent may have access to systems without anyone having clearly defined the boundaries of its authority.

That gap is where responsibility becomes difficult to locate.

The experts in the supplied AI podcast transcripts make a practical point: AI capability is jagged. A system can perform impressively on one task and fail at another that appears similar. People also have to specify what they want.

When an agent fails, the instruction may have been unclear. The environment may also have allowed it to reach data or take actions it should never have been able to reach. Those are different failures, and they need different responses. Calling both “the AI made a mistake” tells us very little. It can also give the people who set up the system a convenient way to avoid examining their own decisions.

An agent cannot be accountable in the human sense. It cannot explain its actions to a customer, repair a damaged relationship, or accept a consequence. Accountability has to remain with the people and institutions that decide where it may act.

That does not mean a human must approve every click. If a person has to review an endless queue of routine decisions, the promised speed disappears. If that person is asked to approve without enough context, oversight becomes theatre.

The design question is more demanding: where can the agent act on its own, what must it never do, and which decisions require a person with the authority and information to intervene?

Recent OECD practitioner research looks at how organizations are developing, deploying, and governing agentic AI. Based on interviews, it offers early insight into practice; it does not measure how common any one approach is. That distinction matters. We are still learning how these systems behave inside real organizations, processes, and decision structures.

PwC’s July 2026 guidance offers one commercial view of controls worth considering: give each agent a verified identity, a defined role, task-specific permissions, and auditable records. It also argues that human oversight should rise with an agent’s autonomy and the consequences of its actions. The advice is sensible, though responsibility cannot be outsourced to a checklist—or to a consultant.

An agent should receive only the authority needed for the task, for only as long as it needs it. If it is asked to review documents, that should not quietly grant it authority to alter customer records or send external messages. The organization should be able to reconstruct what happened: which agent acted, under whose authority, what it accessed, what it changed, and whether a person approved the consequential step.

This is not a demand for perfect prediction. A model may misunderstand a request or encounter conditions its designers did not anticipate. A well-designed system can still limit the damage, make the action visible, and give people a clear path to stop or correct it.

Think of the difference between handing someone a key to one room and giving them the master key to an entire building. If the wrong door opens, we should ask not only whether the key-holder made a bad choice, but who issued the key and why it opened that door.

With agents, the “key” is a combination of identity, permissions, data access, tools, and the ability to act across connected systems. A single action can trigger a payment, notify a customer, or change what another system does next. Reviewing isolated actions may miss what the full chain accomplished.

That is why “a human was in the loop” is not enough. Which human? At what point? With what information? Could they stop the action? Were they accountable for the outcome, or merely asked to click approve after the important choices had already been made?

The answer belongs in the operating model before an agent is allowed to act. Name the accountable owner. Define the agent’s scope and limits. Keep its access narrow. Record actions in a way that supports review. Escalate decisions in proportion to their potential impact. Test the agent in the environment where it will actually work; capability shown in a controlled test does not automatically transfer to a live process.

We should not confuse delegation with abdication. Delegating a task to software can be useful. Delegating responsibility to software is not.

The more autonomy we give an agent, the clearer our own accountability should become. If an organization cannot say who authorized the agent, what it was permitted to do, and who must respond when its actions cause harm, then it is not ready to give that agent this level of authority.