If the AI gets it wrong, can we undo it — and how much autonomy does that justify?
Baseline: 3Enhanced: 25 controls
Who it applies to
Enter for every AI system. Some of its controls apply only where it acts on its own (B3). Go as deep as your system letter, and implement in your mode.
Why it exists
Before you grant any AI the power to act on its own, ask one question: if it gets this wrong, can we undo it? Some actions are two-way doors — cheap to reverse, so a system can be trusted to walk through them alone and be corrected afterwards. Others are one-way doors — once taken, the cost, the reputation, or the legal consequence cannot be recalled — and at those doors a human must stand. Make this the organising rule of autonomy: the more irreversible the action, the less autonomy the AI is permitted, without exception for how impressive the system is. Sophistication is not a reason to widen a one-way door; it is usually the reason someone asks you to.
This dimension sets the rule and the classification; the machinery that enforces it in daily operation — the interfaces through which humans intervene, the override mechanisms, the competence of the people doing the overseeing — is specified in the Human Oversight domain. Here, decide the policy: which actions the AI may take alone, which it may only prepare, and which it may never execute.
Action type
Reversibility
Permitted autonomy
Governance control
Synthesis and analysis (e.g. summarising a document)
Fully reversible — a bad output is simply discarded
Complete: the AI acts alone
Continuous logging; outputs labelled as AI-generated.
Administrative and workflow support (e.g. preparing an expense approval)
Partially reversible — correctable, at some cost
Supervised: the AI prepares, a human validates before anything takes effect
A human confirms before execution; the confirmation is recorded.
Critical operations (e.g. executing a payment; a decision affecting a person)
Irreversible in at least one ledger
None alone: strict human-in-the-loop
Dual authorisation for the highest stakes; the AI may prepare but never execute.
What to actually do
Classify every action an AI can take by its reversibility, before granting any autonomy. For each use case in which an AI acts — not merely answers — ask how hard the action is to undo and what undoing it would cost. That answer, and not the capability of the model, sets the autonomy you permit. Record the classification; it is the decision every later control enforces.
Judge irreversibility across four ledgers, and take the worst. An action can be technically reversible and still irreversible where it counts. A payment can sometimes be recalled; a message to a customer cannot be unsent; a decision about a person, once communicated, cannot be uncommunicated. Assess every action across four ledgers — financial, operational, legal, and reputational — and let the worst of the four govern, because the worst is the one that will define the incident.
Give mixed workflows the autonomy of their most irreversible step. An agent that drafts a message (reversible) and sends it (usually not) is, for governance purposes, a sending agent. When a workflow chains reversible and irreversible steps, the whole workflow inherits the autonomy ceiling of its most irreversible step — otherwise the reversible steps become the corridor through which the irreversible one is reached unsupervised.
Write each agent’s limits down as a charter. One page per agent: what it is for and what is out of scope; the tools and data it may use; the actions it may take alone, those it may only prepare, and those it may never take; its oversight position (Domain 6); its owner; and how it is stopped. The charter is the single piece of evidence for the classification, the autonomy decision, and the oversight position.
Bound the damage, not only the action. Express the autonomy ceiling also as limits on value and volume: the largest amount an agent may move, the most records it may change, the most messages it may send, per action and per day. A limit of this kind contains the failure that the classification did not foresee.
Raise autonomy in stages. A new agent first runs in shadow — it proposes and a person executes; then with limited autonomy, under a low ceiling and with its actions sampled; and only then at the autonomy its classification permits. It moves up a stage on recorded evidence — the error rate observed at the stage before — never on confidence in the model.
Controls
Baseline3 controls
Control 68
Classify every agentic use case by reversibility before granting autonomy.
BaselinePreventiveall rolesper systemagentic
What it is
The classification is recorded and is the input to every autonomy decision.
How to implement it · Steps
List every action the agent can take, not just answer: send, pay, change or delete records, publish, book
For each action, ask how hard it is to undo and what undoing would cost
Rate it on four ledgers: financial, operational, legal, reputational
Take the worst ledger as its class: reversible, partially reversible, irreversible
Record the classification with date and owner; it is the input to the autonomy decision
How to start
For your first agent, list every action it can take on one sheet and rate each on the four ledgers.
Evidence
The dated reversibility classification for each agentic use case.
Mode: light / standard / full
light
The owner-manager and whoever set up the agent classify the actions together in a spreadsheet.
standard
The system owner classifies with IT and the business process owner, and the committee reviews it.
full
Risk and the system owner classify jointly with a standard method, recorded in each agent's charter.
Control 69
Set the permitted autonomy inversely to irreversibility, per use case, in writing.
BaselinePreventiveall rolesper systemagentic
What it is
Full autonomy only where fully reversible; human validation where partially; human execution where irreversible.
How to implement it · Minimum rules
Fully reversible: the agent may act alone; actions are logged
Partially reversible: the agent prepares; a human validates before execution
Irreversible: the agent may only propose; a human executes
Write it per use case in a one-page agent charter: actions alone, prepare only, never; owner; how it is stopped
Signed by the system owner; changed only by reclassifying
How to start
Write the autonomy level next to each classified action and have the system owner sign it.
Evidence
The signed autonomy decision or agent charter for each use case.
Mode: light / standard / full
light
The owner-manager signs a one-page charter per agent and keeps it with the inventory.
standard
The system owner signs and the committee approves any action granted full autonomy.
full
Charters are approved by the committee and the levels are configured as permissions in the agent platform.
Control 70
Mandate a human in the loop for every irreversible action.
BaselinePreventiveall rolesper systemagentic
What it is
No exception for model quality, urgency, or volume; the exception process is a change to the classification, not a bypass of it.
How to implement it · Minimum rules
Every irreversible action needs explicit human approval before it executes
Enforce it technically: the agent lacks permission to execute alone; a prompt instruction is not enough
The approver sees what will be done, to whom and for how much
Record each approval: who, when, what
No exception for urgency, volume or model quality; the only route is reclassification
Test that an irreversible action without approval is blocked
How to start
Remove the agent's direct permission for each irreversible action and route it to an approval step in the tool's settings.
Evidence
The approval records for irreversible actions and the result of the block test.
Mode: light / standard / full
light
Use the agent tool's built-in confirm-before-acting setting, with the owner-manager or a named person approving.
standard
IT configures approval steps and the system owner reviews the approval log monthly.
full
Approvals run through the workflow engine with segregated approvers, and block tests are repeated at each release.
Enhanced2 controls
Control 71
Apply the autonomy ceiling at workflow level.
EnhancedPreventiveall rolesper system
What it is
The most irreversible step in a chain governs the whole chain.
How to implement it · Steps
Map each workflow end to end, including steps carried out by the tools the agent calls
Identify its most irreversible step from the reversibility classification
Apply that step's autonomy level to the whole workflow: an agent that drafts and sends is a sending agent
Look for routes around: reversible steps that automatically trigger an irreversible one
Record the workflow-level ceiling; reassess when a step or tool is added
How to start
Take the agent with the most steps, draw its workflow on one page and mark the most irreversible step.
Evidence
The workflow-level ceiling assessment for each agent.
Mode: light / standard / full
light
The person who set up the agent maps the workflow and the owner-manager signs the ceiling.
standard
The system owner and IT map workflows and record ceilings in the agent charters.
full
Architecture maps workflows formally and the ceiling is enforced in the orchestration layer.
Control 72
Require dual authorisation for the most critical irreversible operations.
EnhancedPreventiveall rolesper system
What it is
Two humans, independently, for the actions whose failure the organisation could not absorb.
How to implement it · Minimum rules
List the critical irreversible operations, e.g. payments above a threshold, mass customer messages, bulk deletion, decisions about many people
Two different people approve each one independently; the requester cannot be one of them
The system blocks the second approval from the same account
Both approvals logged with time and what each approver saw
Review the list and thresholds at least annually
How to start
List the operations whose failure the organisation could not absorb and configure a second approver for each in the system that executes them.
Evidence
The list of critical operations and the dual-approval records.
Mode: light / standard / full
light
Two named people, e.g. the owner-manager and a partner, approve; where the tool lacks dual approval, the second confirms in writing before release.
standard
IT configures dual approval in the executing systems and the system owner reviews the log.
full
Dual approval is enforced in the workflow engine with segregation of duties and audited periodically.
Evidence
The reversibility classification per use case; the recorded autonomy decisions; the human-validation and dual-authorisation records; workflow-level ceiling assessments.