Review the recovery boundary of every agent action
Review an agent’s permitted actions, their consequences and recovery paths. Reversibility gives the architecture review a concrete question about who can correct an effect and within what time.
Trace the interfaces between applications and records before changing a system.
An autonomy label does not specify an agent’s operating boundary. Establish which tools it can call, what permissions those calls use and which actions require approval. These properties can be inspected in the running system.
Describe the permitted actions alongside any autonomy label. A supervised system may perform an irreversible action after one approval, while an automated system may be confined to recoverable work. The label is useful when it corresponds to explicit controls and responsibilities.
Reversibility provides another review axis. For each action, establish whether the effect can be corrected, who has authority to do so, the available window and the cost of recovery. Assess these alongside impact and degree of autonomy rather than treating reversibility as a complete risk measure.
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.
Impact requires judgement about the people and operations affected. Reversibility adds a concrete test but also needs qualification: restoring a record may not reverse an earlier disclosure or a decision made from it. Review technical recovery and the remaining consequence together.
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. Review the proposal before execution.
- 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. Check recall, correction and reconciliation paths.
External effects can be difficult to reverse. A delivered email, released payment or counterparty record may require another party to accept a correction. Document any cancellation or recall mechanism, its limitations and the point beyond which the organisation cannot rely on it.
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
Enforce the action boundary in permissions and receiving-system controls. Model instructions explain the policy but should not be the sole barrier to an effect. Test the intended scope against what the credentials actually permit.
For high-risk systems, Article 14 of the EU AI Act addresses effective human oversight, including the ability, as appropriate, to disregard, override or reverse output and interrupt operation safely. Stopping further actions may leave earlier external effects unchanged. Distinguish those capabilities in the design.
Ask suppliers which actions the buyer can reverse through its own authorised processes, what requires supplier support and what cannot be undone. Require a demonstrated recovery path and the evidence it preserves. Monitoring alone does not establish that recovery works.
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.
Before release, review the action inventory with identity, operations and risk owners. Record authority, approval, recovery and remaining consequences for material actions. This makes the boundary a design decision that can be tested and reconsidered.