Autonomy is not the risk in an agent. Irreversibility is.
Review boards keep asking how autonomous an agent should be, and the question has no answer, because autonomy is not a quantity anyone measures. The answerable question is which actions leave effects nobody can take back — and that is a fact about the system around the model, not about the model.
The question arrives near the end of the design review and it stops the room every time. How much autonomy should this thing have. Everyone present has an answer, none of the answers are the same, and none of them can be checked. The engineering lead means something about which tools are wired up. The risk lead means something about consequences. The sponsor means something about how much they trusted the demonstration they saw last month.
The meeting resolves the way it always resolves. Somebody picks a level — supervised, semi-autonomous, autonomous — it goes into a slide, and the build carries on unchanged. The label constrains nothing, because there is nothing in the running system that corresponds to it.
Autonomy is the wrong axis. It cannot be measured, so it cannot be reviewed, and a control that cannot be reviewed is a control in name. The axis that works is reversibility: for each action the system can take, whether the effect can be undone, by whom, and within what window. Those questions have answers. Most of the answers are uncomfortable, which is the reason to ask them early, and almost all of them turn out to be facts about the architecture around the model rather than facts about the model.
Excessive agency names the problem and leaves the line to you
The security community got there first. OWASP lists excessive agency in its Top 10 for LLM applications, defining it as the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated model output, and attributing it to three causes — excessive functionality, excessive permissions and excessive autonomy (LLM06:2025). The prevention list is sound engineering: narrow the extensions, narrow the permissions, act in the user context, and require user approval for high-impact actions.
The last one is where teams stall, and the reason is that impact is a judgement. Two people scoring the same action are scoring different things — one is thinking about the customer, one about the balance sheet, one about the story in the trade press — and a room scoring impact does not converge, it negotiates. Reversibility is not a judgement. It is a property of an action and of the system it lands in. Two engineers who will argue all afternoon about how bad it would be to delete the row will agree, in under a minute, on whether the row can be restored.
Where the undo runs out
An effect does not exist or fail to exist. It travels, and it passes a point after which the organisation no longer holds the undo.
- 01 Proposed The action is chosen. Nothing has happened. Reversal is free.
- 02 Executed The effect exists in a system you operate. Reversal is an engineering task.
- 03 Committed It is in a system of record others read as true. Reversal is a correction with a history.
- 04 Released It has crossed into a system you do not control. There is no reversal, only a request.
The fourth column is the one that matters, and it is drawn where most architectures have no boundary at all. An email delivered, a payment instructed, a message posted to a customer, a record written into a counterparty’s platform — for each of these the undo is not an undo. It is a second action asking somebody else to accept a correction, and whether they accept it is outside the system entirely.
Two further properties decide where an action sits, and both are routinely skipped. By whom: an action that can only be reversed by a supplier’s support desk, on a ticket, is not reversible inside an incident. Within what window: a deletion recoverable from a nightly snapshot is reversible at a granularity of one day, and an agent running every hour produces effects that the snapshot was never designed to catch. A reversal that arrives after the next scheduled run has restored a state nobody was in.
The undo is a build item, not a policy
The common failure is to write the boundary into a document and then hand the document to the model as instructions. An instruction is a preference. The boundary is whatever the credentials permit. If the agent holds a token that can delete, deletion is inside the boundary, whatever the policy says, and the first person to discover the discrepancy will be reading an incident timeline.
There is a law that anticipated some of this, and reading it shows how much the ground has shifted. The EU AI Act requires that a deployer of a high-risk system be able to disregard, override or reverse the output, and to interrupt the system through a stop button that brings it to a halt in a safe state (Article 14). Reversing an output is straightforward when the output is a recommendation on a screen and a person acts on it afterwards. An agent collapses the output and the effect into a single event. By the time anyone disagrees with the output, the effect has happened. The stop button still stops the next action, and that is worth having. It does not reach the last one.
This is also the sharpest question to put to a supplier. Not whether their agent has guardrails, which every agent has, but which of its actions are reversible by the buying organisation, using the buying organisation’s own credentials, without contacting them. A vendor who has thought about it answers immediately. A vendor who has not will answer about their monitoring.
What this does not tell you
It does not tell you which actions your organisation should permit. That turns on the estate, the appetite and who carries the consequence, and it is decided per system rather than in the abstract.
It does not make reversibility a proxy for correctness. An action that can be undone can still be the wrong action, taken for a reason nobody can reconstruct, and the record in the list above is what answers that separate question.
Nothing here is legal advice. We deliver readiness and alignment — formal interpretation of any regulation stays with your legal counsel. The institute does not certify anyone, does not audit against a standard, and does not issue conformity opinions. What we do is establish which actions a system can take, where each effect lands, and which of them the organisation could take back.
The list of actions an agent may perform without a person is being written either way. In most organisations it was written by whoever issued the credentials, in an afternoon, to unblock a demonstration. Writing it on purpose costs one design review. The alternative is reading it for the first time in the timeline of the action nobody could take back.