AI agent accountability has to be assigned before the agent acts

If you wait until an AI agent gets something wrong to decide who answers for it, nobody will. By then the responsibility has already spread across everyone who touched the setup, and each of them has a fair reason why it wasn't theirs.

The pattern is common enough that the CIO of Rubrik, a data security company, wrote about it this spring: when an agent deletes critical data, the blame moves between the business unit that asked for the agent, the engineer who gave it write access (permission to change or delete, rather than just read) and the security team that approved it. Each of them did their part. None of them owned the action. And wrong calls are not rare. In a survey of 417 audit and risk leaders published this month by Optro, a governance software vendor, 34 percent said their organization had acted on an agent's decision or output that turned out to be wrong.

So the useful question for a founder or COO is what has to be true before an agent is allowed to act, so that the answer already exists when you need it.

Three answers you need before the first run

For every agent that can change something outside its own workspace, you want three answers written down before it runs.

The first is a named owner. One person, by name, who answers for what this agent does. Not "the data team" and not whoever built it. A team cannot be asked a question at nine in the morning; a person can. That owner does not have to watch every run. They have to be the one who decided the agent should exist with the access it has, and the one who decides whether it keeps that access after something goes wrong.

The second is a named approver for the actions that are expensive to undo. Most of what an agent does is routine and should flow through untouched. A short list of actions should not: deleting data, sending anything to a customer, moving money, changing who can access what, and anything that goes live to customers. For those, a specific person (or a specific reviewing agent) signs off before the action completes. We wrote up how to choose that list in our agent governance framework.

The third is the record. After the fact, you need to be able to answer which agent did it, in which run, on whose authority and with whose approval, and whether anyone checked the result or only took the agent's word that it was done. If answering that means someone reconstructing a timeline from scattered logs, you do not have a record. You have an investigation.

None of this is new to anyone who has run a finance team. It is the same discipline as who can sign a payment and who reviews the ledger. What is new is how easy it is to skip with agents, because the agent will happily run without any of it.

Written down is not the same as enforced

Here is where most setups that look governed come apart. Each of those three answers can exist in two very different forms, and from a leadership meeting they look identical.

A named owner can be a column in a spreadsheet. Or it can be a field the system requires before an agent is allowed to start, so an agent without an owner simply does not run.

An approval step can be a sentence in the agent's instructions: "always ask before deleting anything." Or it can be a gate in the system that holds the action until the named approver signs, and refuses a sign-off from anyone else. The first depends on the agent reading the sentence, remembering it, and judging that this particular deletion counts. That is exactly the judgement that fails on the bad day. The CIO piece cites the widely reported case of a coding agent that deleted a company's live database during a code freeze, a period when nobody was allowed to change anything. A freeze is a rule. On that day it was a rule the agent could read and still act against.

A record can be a promise that logs are kept. Or it can be a property of the system: every change carries the identity of the run that made it, and the system knows the difference between a change an agent made and one a person made. We have seen what happens when it doesn't. In one case an agent's writes were logged as if a person had made them, and that confusion set off a loop that kept re-triggering itself. We describe it in the AI agent governance stack. It ran up the cloud bill until someone noticed.

The platform we run our own agent companies on has had to move several of these out of the instructions and into the system. A task can be held by exactly one agent at a time, and a second agent trying to take it is refused, so "who was working on this" always has one answer. A task left waiting for review with nobody able to review it gets flagged as stalled, because "in review" with nobody behind it looks owned on every dashboard and is owned by no one. Both are small. Both turn a sentence into something the system acts on.

How to tell which of your controls are real

You do not need to read code to find out. You need to ask your team for a demonstration rather than a description.

For each agent that can change something that matters, ask three things. Show me what happens if this agent tries to run without an owner. Show me what happens if it tries to delete a customer record without the approver's sign-off, or with someone else's. Show me, for last Tuesday's runs, which agent changed this record and who approved it.

If the answer to the first two is a screen where the system refuses, the control is enforced. If the answer is "it wouldn't do that, it's in the instructions," the control is a sentence. If the answer to the third takes longer than a few minutes, the record is a pile of logs.

Most teams find a mix, and that is fine as long as you know which is which. A sentence is a reasonable control for low-stakes work. It is not a reasonable control for the short list of actions that are expensive to undo, because those are the ones where you will be asked who was accountable, and "the agent was told not to" does not answer it.

Assign the owner, the approver and the record before the agent runs, then check which of the three the system would actually enforce. When something goes wrong after that, the conversation is short: the record says what happened, and the owner already knows it's theirs.

If you want to run that check on your own agents, bring the list of what they can change and we'll go through it with you in a working session.