Agentic AI oversight
IMDA Agentic AI Framework v1.5 §2.1.1 and §2.2.2 — Reversibility of agent’s actions
Nothing in law requires an agent to stop and ask before doing something that cannot be undone. The EU AI Act treats reversibility as a criterion the Commission weighs when classifying systems, not as a duty owed by anyone. The recommendation to gate irreversible actions comes from a framework, and the hard part is deciding which actions those are.
§ 1 — Who it binds
Which agents this reaches, and which fall outside
Any agent with write capability — able to modify data, to transact, or to communicate with a party outside the organisation. Read-only agents fall outside by construction, on the framework’s own reasoning that an agent which can only read from a database cannot impact the database. The trigger is capability rather than intent, so a tool the agent has never yet invoked still counts.
§ 2 — In practice
Reversible in whose sense
The provision most often produced against this question creates no duty at all. Article 7(2)(i) of the EU AI Act lists, among the criteria the Commission weighs in deciding whether to add a use case to Annex III, the extent to which the outcome produced involving an AI system is easily corrigible or reversible — adding that outcomes having an adverse impact on health, safety or fundamental rights shall not be considered to be easily corrigible or reversible. It binds the Commission, exercising a delegated power to amend an Annex. Reading it as an obligation to gate irreversible actions is a category error and a common one. Irreversibility appears once more in the Regulation, inside the Article 3(49)(b) definition of a serious incident, where it describes a harm that has already happened.
The IMDA Model AI Governance Framework for Agentic AI, version 1.5 (20 May 2026, updated 5 June 2026) treats reversibility first as an impact factor and then as a gate. §2.1.1 asks, where an agent can modify data and systems, whether such modifications are easily reversed, noting that modifications may not be easily reversed if they trigger downstream obligations, for example entering into a contract or sale. Its worked contrast is domestic: an agent scheduling meetings can easily reschedule them if an error is made, against an agent that sends email communications to external parties. §2.2.2 then turns it into a checkpoint, asking for approval especially before sensitive actions are executed and naming irreversible actions as a category — permanently deleting data, sending communications, making payments.
What decides most determinations is the distinction between technical and legal reversibility, and it is the legal one that governs. A payment can be reversed technically and remain irreversible in every sense that matters: the counterparty has been notified, the offer accepted, the disclosure made. Sending an email is the framework’s own pure case, and it is pure because the compensating action does not exist — there is no operation that unsends. An organisation whose determination asks only whether its platform supports a rollback has answered a question about its own database rather than about the world the agent acted on.
Two artefacts are routinely produced against a reversibility finding, and neither answers it. The first is a rollback runbook: the draft MAS Guidelines, paragraph 4.25(b), address rolling a system back to a previous version, which is sound practice about a different object — restoring a model version undoes nothing the previous version sent. The second is a two-tier scheme, automatic or forbidden, which forces every partially reversible action into one extreme and, since nobody wishes to forbid a useful action, usually into the permissive one. The Dayos case study runs three: low severity and fully reversible, automated with a biweekly audit; moderate severity and partially reversible, propose-and-approve; and high severity with limited reversibility — production deployments, security changes, permission modifications — where the agent does not touch these at all. The middle tier is where the design work sits, and it only comes into existence once the action envelope has been drawn per action type.
No penalty attaches to failing to gate an irreversible action as such, and it is worth being exact about where exposure does arise, because it arrives from the other end. An irreversible harmful outcome may be a serious incident under Article 3(49) with the reporting duty that follows; and for a deployer of a high-risk system the duties in Article 26 to inform the provider and the authority, and to suspend use, are triggered by having reason to consider a risk rather than by a harm that has materialised. The Act’s nearest controls are narrower than they appear: Article 14(4)(d) contemplates a person disregarding, overriding or reversing an output, and 14(4)(e) a stop button allowing the system to come to a halt in a safe state. Halting is not undoing, and an output is not an effect on somebody else’s system.
§ 3 — What a weak answer looks like
The rollback runbook answering a different question
A rollback plan, produced with confidence, against a finding about actions that cannot be undone. It describes restoring a model version or a database snapshot and it is usually a good plan — about the system rather than about the world. Nothing in it retracts a message, cancels an accepted offer or unmakes a disclosure. The subtler form is a scheme with two settings and no middle: because nobody wants to prohibit a useful capability, everything partly recoverable is filed as automatic, and the tier where the judgement belonged is never reached.
§ 4 — What discharges it
What a gating decision leaves behind
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
A reversibility determination per action type, with the mechanism named
Not a rating. For each action: what the compensating action is, how long the window to execute it lasts, who executes it, and what it cannot restore. The last column changes tier assignments, and it is the one most schemes do not have.
02
Gate configuration exported from the running system
Reconciled line by line against the determination. Where the two disagree the running configuration is the fact, and the distance between design intent and deployed behaviour is the finding rather than the document.
03
A reversal that was actually performed
One case, end to end, with elapsed time and an honest statement of what remained un-restored once it completed. A capability nobody has exercised establishes that somebody believed it would work.
04
Time-window and rate constraints on consequential actions
The Terminal 3 case study sets a ceiling amount for the consolidated bank transfer, at base salary plus a buffer margin and explicitly declared before each run. A constraint of that kind bounds what a gate failure can cost, and it is testable in a way an approval step is not.
05
The list of action types barred entirely, and who decided
Dated and attributed. Its absence is informative: either the organisation concluded that none of its agent’s actions is consequential enough to prohibit, or the question was never put to anyone able to answer it.
06
The downstream-obligation test, applied
The framework’s own limit is that modifications may not be easily reversed where they trigger downstream obligations, such as entering into a contract or sale. The artefact is the list of actions creating an obligation to a third party, drawn up by someone able to recognise one.
§ 5 — Worked example
Worked example — the credit and the email
A software firm gives a support agent the ability to issue account credits, close tickets and email customers. Credits above two hundred dollars need approval; everything below is automatic. Engineering has pointed out that credits are ledger entries reversible by a single administrative action, so finance agreed the threshold could be raised. Customer emails go out through the ordinary transactional service with no gate at all.
Which of the agent’s actions should be gated, and on what basis?
The email, before the credit — which is the opposite of where the controls currently sit. A credit is technically reversible and, at that value, consequential only narrowly; but a customer told they have been credited has been told, and amending the ledger entry does not retract the statement. The email is the pure case: no compensating action exists, and there is a counterparty at the other end. A defensible determination would set out, for each action type, the mechanism of reversal — what the compensating action is, how long the window lasts, who executes it, and what it cannot restore — and would find the email row empty in three of those four columns. It would also produce a barred tier. An organisation with no action its agent may not take at all has either concluded that nothing it does is that consequential, or has never run the exercise; in the Dayos scheme the barred tier accounts for about a tenth of volume.
§ 6 — Elsewhere
Adjacent provisions, and what they actually cover
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
Article 14(4)(d) contemplates a person overriding or reversing the output of a high-risk system and 14(4)(e) a stop button bringing it to a halt in a safe state. Both concern the system’s own operation; reversibility here concerns effects already had on systems outside it.
NIST AI RMF
MANAGE 2.3 addresses mechanisms for superseding, disengaging or deactivating a system whose behaviour is inconsistent with its intended use. It addresses stopping rather than undoing, which is the distinction this page turns on.
MAS instruments
The draft Guidelines, paragraph 4.25(b), would have a financial institution able to roll a system back to a previous version. It concerns the system rather than the effects of what it did, and it is a proposal in a consultation paper.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 7 — When it applies
When the recommendation appeared
20 May 2026
The date version 1.5 published, updated 5 June 2026. It is a publication date, not a compliance date: the framework recommends gating and no instrument requires it, so nothing is owed from this day or any other.
§ 8 — provenance
The provision itself
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
- IMDA and the AI Verify Foundation, Model AI Governance Framework for Agentic AI, version 1.5 — the reversibility impact factor at §2.1.1 and the irreversible-actions checkpoint category at §2.2.2.
- Version 1.5 published 20 May 2026, updated 5 June 2026. A publication date, not a deadline.
- Regulation (EU) 2024/1689 — Article 7(2)(i), the criterion applied by the Commission under the Article 97 delegated power; Article 3(49)(b); and Article 14(4)(d) and (e).
- MAS Consultation Paper P017-2025, November 2025; paragraph 4.25(b) is a draft Guidelines paragraph at §6, which numbers separately from the consultation paper.
§ 9 — Also read
Also read
EU AI Act Article 26 — deployer duties, including suspension
Certification
Assessed on the same standard of evidence
Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The free AI Literacy Certificate is open to any adult today, and the register lists what is open for enrolment.