Accountability for AI agents requires naming specific people in four roles before deployment: the employee who initiated the work, the agent itself (named and registered), the business owner accountable for that agent, and the person who approved the outcome. Record all four on every run. Design agents to gather evidence rather than make consequential decisions, so accountability stays with the human approver using a process your organisation already operates. This turns a philosophical problem into a bookkeeping one you can solve now.
Why is “a human in the loop” not an answer?
Because it names no one.
Ask a team who is accountable for their agent and you will usually get some version of it. There is a human in the loop. There is oversight. Someone reviews the output. All of that can be true and still leave you unable to say, twelve months later, which individual signed off on a specific case and what they were looking at when they did.
An accountability model has to survive three fairly ordinary situations. Someone leaves the company and their agent keeps running. An incident review asks who authorised a change to the agent’s permissions in April. An access review asks which systems this agent can reach and who decided it should. “A human in the loop” answers none of them.
The useful version is duller and more specific: a named role for each part of the chain, recorded at the time, not reconstructed afterwards from Slack messages.
What actually goes wrong today?
Agents commonly run on shared credentials, and that single fact causes most of the trouble.
An agent is deployed, it needs to read four systems, and the fastest way to make that work is a service account. Now every action it takes appears in those systems as the service account, which tells you an action happened and almost nothing else. It does not tell you which employee’s request set it off, which agent among the six you now run actually acted, who in the business owns that agent, or which person approved the result.
Six months later something goes wrong and the investigation starts from a log line that reads like a database wrote it. The team spends two days reconstructing the chain by hand, from tickets, chat history and memory. They usually get there. But the reconstruction is the finding, because a control you have to reconstruct is not a control you can evidence.
There is a second problem underneath. When several agents share one identity, you cannot revoke one of them. Tightening the permission affects everything using that account, so in practice nobody tightens it.
What is the accountability chain?
Four roles, and they are genuinely different people.
The initiator. The employee who opened the case or triggered the run. Not a service account, a person. This is what connects agent activity back to ordinary business work.
The agent. A named agent with a registered purpose, not “the LLM” or “the pipeline”. If you run six agents against your onboarding workflow, the record has to say which one acted.
The owner. A business person accountable for that agent existing. They approve changes to what it can reach, they answer for its outcomes, and they can switch it off. This is usually the person who owns the workflow already, which is the point. You are not inventing a new accountability structure, you are attaching agents to the one you have.
The approver. The named person who accepted, rejected or escalated the result. In a regulated workflow this is the decision of record.
Keep those four separate and most awkward questions become answerable. Collapse any two of them, which shared credentials do by default, and you are back to reconstruction.
What does owning an agent actually mean?
Three concrete obligations, and if none of them apply to the person named as owner, they are not really the owner.
They approve what the agent can reach. Adding a data source or a new action is their decision, not a deployment detail. If a permission change can ship without the owner knowing, the ownership is decorative.
They answer for its outcomes in the same forum where they already answer for the workflow. If the head of onboarding answers for onboarding quality, they answer for the onboarding agent’s contribution to it too.
They can switch it off, quickly, without filing a ticket and waiting. This one is the tell. Ownership that cannot stop the thing is not ownership.
Notice what is not on that list. The owner does not need to understand the model, review the prompts, or attend the architecture review. They need to know what the agent is for, what it can touch, where its hard line sits, and what evidence it leaves. That is a short enough list for a business leader to hold in their head, which is the only way this works in practice.
What if the agent cannot make a bad decision?
Then the question changes shape, and this is the part worth designing for rather than arguing about.
Most of the accountability anxiety around agents comes from imagining an agent that decides. Approves the customer. Books the correction. Clears the alert. If that is your architecture, you are trying to assign human accountability to a machine action after the fact, and it will always feel unsatisfying, because it is.
The alternative is to scope the agent to evidence. It gathers, compares, flags conflicts, scores against a rubric you wrote, and proposes. The consequential action is not in its permitted set at all, so an attempt to invoke it fails and gets logged. A named person then decides, on evidence the agent assembled.
Now accountability is ordinary. The approver is accountable for the decision, exactly as they were before agents existed. The owner is accountable for the agent’s quality and reach. And you have better evidence than you had before, because the assembly work that used to happen in six browser tabs is now recorded.
This does not make the agent’s quality unimportant. A poor agent that surfaces the wrong things wastes an approver’s time and can bias them, which is a real risk and one worth measuring. But it is a quality problem with a named owner, not an accountability vacuum.
What questions will an incident review ask?
Six, and you should be able to answer all of them from the record without an engineering investigation.
What was the business case, and who opened it. Which agent acted, and under which registered purpose. Which policy and prompt version were live at that moment. What did the agent read, and when. What did it attempt that was refused. Who approved the outcome, and what did they write.
That last pair does most of the work in a review. The refused actions show the boundary was enforced instead of merely documented. The approver’s rationale shows a person engaged with the evidence instead of clicking through.
If your answer to any of the six is “we would have to check with the team who built it”, that is your gap, and it is much cheaper to find it now than during an actual incident.
How does this show up in an access review?
As the question nobody can answer quickly.
An access review asks which identities can reach a given system and whether each one still should. Human identities are handled: there is a joiner-mover-leaver process, a manager who confirms, an audit trail. Agent identities usually are not, because they arrived as service accounts and inherited whatever permissions made the integration work on the first day.
So the reviewer sees an account with read access to four regulated systems and no clear answer to who owns it, why it needs all four, or whether the project that created it still exists. The safe response is to leave it alone, which is how permission creep becomes permanent.
If each agent carries a registered owner, a stated purpose and an explicit list of what it may reach, the review becomes the same conversation you have about a person: does this still need this, and who says so. That is not a technology change so much as a bookkeeping one, which is why it is worth doing early, while you have six agents instead of sixty.
The measurable version, and a fair one to hold yourself to: how long does it take to trace one agent action end to end, and how many of your agent identities currently have no named owner. Both are countable today.
What is under development?
Agent identity as a platform capability is under development at moring, and it would be dishonest to describe it otherwise.
What exists today is the control pattern: registering an agent with a purpose, an owner and a risk tier, restricting what it can reach, keeping consequential actions behind a named human approval, and retaining the evidence including refusals. That is available now and it carries most of the argument in this article.
What is being built is the identity layer that makes the four-role chain hold automatically, including when an agent crosses from one cloud environment to another, so that the initiator, agent, owner and approver stay attributable in a single decision record instead of being reassembled from several systems. Two related controls are already live and worth separating from that. Skills and tools are scanned before they are published, and every call through the gateway records a guardrail verdict of passed, flagged or blocked. What is still being built is re-checking an agent’s tool access while it runs, instead of only at the point it was registered.
Treat both as in progress. If you are writing a control framework this quarter, write it against the pattern that exists, not against the layer that is coming.
On what it is worth: as an illustration only, a firm running 300 audit, access or incident reviews a year and saving two hours on each at an $80 loaded hourly cost recovers roughly $48,000 of control-team capacity. At 2,000 reviews a year on the same assumptions it is roughly $320,000. Those are modelled figures with visible assumptions, and you should replace them with your own review volume and your own tracing time. They also leave out the things that are harder to count, like faster incident containment and cleaner segregation of duties.
Key takeaway
Accountability for agents is not a philosophical problem, it is a bookkeeping one you can solve before you need it. Record four roles on every run: who initiated, which agent acted, who owns that agent, and who approved the result. Give the owner three real powers, especially the power to switch it off. Scope the agent so the consequential action is not available to it, and the accountability question collapses back into one your organisation already answers every day.
Then check yourself against the six incident questions. If any of them needs an engineer, fix that now, while it is a bookkeeping exercise instead of an investigation.
Book a diagnostic workshop to map your agent accountability chain and find the gaps before an incident does: moring.ai/contact
