Singapore wrote the first rulebook for AI agents, and almost nobody building agents has read it.
That is a shame, because it is short, unusually concrete, and written by people who have clearly looked at production systems rather than at press releases. It names Model Context Protocol and Agent2Agent by name. It distinguishes an agent's action-space from its autonomy and explains why the two need separate controls. It tells you not to send a human a raw execution trace when you want them to approve something. Very little regulatory writing about AI is this close to the work.
It is also voluntary, which is the first thing worth being clear about, and the reason to read it anyway is not compliance.
What is Singapore's Model AI Governance Framework for Agentic AI?
The Model AI Governance Framework for Agentic AI is guidance published by Singapore's Infocomm Media Development Authority for organisations deploying AI agents. Minister Josephine Teo launched Version 1.0 at the World Economic Forum in Davos on 22 January 2026. IMDA published Version 1.5 on 20 May 2026 and updated it on 5 June 2026.
The update matters and a fair amount of published commentary has not caught up with it. Version 1.5 runs to 51 pages, folds in feedback from more than 60 organisations including AWS, DBS, Google and Salesforce, and adds more than ten worked deployment case studies. The four-dimension structure is unchanged. What changed is depth: systemic risks in multi-agent systems, a taxonomy of control types, change management, and sharper guidance on automation bias. If you are working from the January text, you are working from the outline.
The four dimensions are:
- Assess and bound the risks upfront
- Make humans meaningfully accountable
- Implement technical controls and processes
- Enable end-user responsibility
Those are the framework's actual organising structure, and it is worth stating plainly because several summaries in circulation list reversibility, agent identity and bounded tool access as the dimensions. They are not. They are recommendations that live inside dimension one.
Is the framework mandatory?
No. The framework is voluntary guidance and carries no penalties. Singapore's Personal Data Protection Act and sectoral regulation continue to apply to agent deployments on their own terms, and nothing in the framework alters them.
The reason to take it seriously is different, and I would put it in two parts.
First, it is the clearest statement any regulator anywhere has made about what responsible agent deployment looks like in practice. When binding rules arrive, in Singapore or elsewhere, they will be drafted by people who read this document. The vocabulary propagates before the obligation does. Teams that can already produce evidence against these dimensions are ahead of a curve others will follow.
Second, and more immediately, IMDA published a discussion paper on legal responsibility for AI agents on the same day as Version 1.5. A regulator that is simultaneously issuing practical deployment guidance and thinking publicly about liability allocation is not doing this as an academic exercise.
There is a third reason that has nothing to do with regulators. Most of what the framework recommends is what you would do anyway if you had thought carefully about running an agent against a production database. It is a good engineering checklist that happens to have a government logo on it.
What does it require for human accountability over agents?
The framework asks organisations to allocate responsibility explicitly across the agent value chain and inside the organisation, then to design human oversight that survives contact with machine-speed execution. It treats human in the loop as a claim to be tested rather than a control to be asserted.
On allocation, Version 1.5 sets out a value chain running from model developers through agentic AI system providers and tooling providers to the deploying organisation and end users, and it now separates platform providers from system providers and app developers, because those roles carry different obligations and were being conflated. Inside the organisation it distributes responsibilities across key decision makers, product teams, cybersecurity teams and users, with specific tasks named for each.
On oversight, the framework asks organisations to define significant checkpoints requiring human approval, and it names four categories: high-stakes actions and decisions, irreversible actions, outlier or atypical behaviour, and user-defined boundaries where users may hold different risk appetites from the organisation.
Then it does something I have not seen elsewhere in regulatory writing and which is the most useful paragraph in the document. It addresses the form of the approval request. Keep it short and contextual rather than handing the reviewer long logs or raw data. Match the input to the decision: a simple approve or reject for straightforward actions, but for something like reviewing an agent's plan before execution, let the human edit the plan rather than just accept or refuse it.
Anyone who has built an approval queue knows why that matters. A reviewer facing a wall of trace output approves everything by the third day.
Which brings the framework to automation bias, and to its most demanding recommendation. Organisations should train humans to spot common failure modes, and should regularly audit whether human oversight remains effective over time. Version 1.5 adds measurable indicators for that audit: human override rates and human response times during review.
That is a real bar. It means the question is not whether a human approval step exists. It is whether the humans are still meaningfully deciding, evidenced by numbers. An override rate approaching zero and a response time approaching zero describe an approval step that has become a button.
What does reversibility mean for an AI agent, and why does a regulator care?
Reversibility is whether modifications an agent makes to data or systems can be easily undone. The framework treats it as a factor affecting the impact of a risk, sitting alongside the agent's access to sensitive data, its access to external systems, and the scope of its actions.
The illustration IMDA uses is deliberately mundane: an agent that schedules meetings against an agent that sends email communications to third parties. Both write. Only one can be unwound. The framework does not reach for the dramatic case, and that restraint is instructive, because most reversibility failures in production are ordinary.
Reversibility appears a second time, as a named category of checkpoint requiring human approval, with examples that read like a list of things agents actually do: permanently deleting data, sending communications, making payments.
Why a regulator cares is straightforward once you see it stated as a risk factor rather than a feature. Reversibility determines whether a mistake is a cost or an incident. An agent that reorders inventory wrongly has created a problem with a remedy. An agent that emails a customer's data to the wrong recipient has created a problem with no remedy, only a notification obligation. The framework's cascading-effect example makes the same point at system level: a hallucinated inventory figure passed to downstream agents produces reorders that are difficult to walk back once acted on.
The design implication is that reversibility should be assessed at the planning stage, not discovered at the incident. If an action cannot be undone, it belongs behind a checkpoint. If you cannot say which of your agent's actions are reversible, you have not done the risk assessment the framework's first dimension asks for.
Related, and easy to overlook: the framework asks organisations to design mechanisms and procedures to take agents offline and limit their scope of impact when they malfunction. A stop that halts execution is a different artifact from a stop that raises an alert.
How does the agentic framework relate to MGF-GenAI's nine dimensions?
They are siblings rather than parent and child. The Agentic AI framework states that it builds on the Model AI Governance Framework of 2020, not on MGF-GenAI. MGF-GenAI, published by IMDA and the AI Verify Foundation on 30 May 2024, extended the same 2020 base to generative AI across nine dimensions.
The lineage runs: Model AI Governance Framework first edition on 23 January 2019, second edition in January 2020, MGF-GenAI on 30 May 2024, MGF for Agentic AI on 22 January 2026 and updated on 20 May 2026. Two branches from one trunk.
That structure explains why the documents look so different. MGF-GenAI addresses an ecosystem question: how to allocate responsibility and build trust across model developers, deployers and cloud providers, covering accountability, data, trusted development, incident reporting, testing, security, content provenance, safety research and public good. It is written substantially for policymakers.
The agentic framework addresses a deployment question, and it is written for the organisation running the agent. That is why it descends to tool permissions and approval-request design. The shift is from what a model is to what a system does, which is exactly the shift agents force.
For a team subject to both, the practical reading is that MGF-GenAI governs your relationship with the model you build on, and the agentic framework governs the system you wrap around it. Neither displaces the other.
A closing observation about how to use any of this. The framework is explicit that it is a living document, and the record bears that out: Version 1.0 in January, Version 1.5 in May, an update to Version 1.5 two weeks later in June. Building a compliance artifact against a specific version of a voluntary framework is a way to be out of date by the next quarter, and possibly by the next fortnight. Building the underlying capability, meaning knowing what your agent did, which human approved it, whether that approval was real, and whether the action can be undone, is durable regardless of which framework asks next.
Truveil scores AI agents against Singapore's Model AI Governance Framework and five other frameworks, and produces the evidence described here.