On 22 January 2026, at the World Economic Forum in Davos, Singapore's Minister for Digital Development and Information, Josephine Teo, announced the Model AI Governance Framework for Agentic AI, published by the Infocomm Media Development Authority (IMDA). IMDA's own press release describes it as the first in the world to include a comprehensive guide for enterprises to deploy agentic AI responsibly. A revised version followed in May.
This essay is a plain reading of what the framework says, who it is addressed to, and what an organisation would have to do to take it seriously. It is written for people who have to decide, not for people who want to be impressed.
A note on sources before going further. We read the January text of the framework itself, and IMDA's press release. We did not obtain the May revision in full, so what we say about it comes from published law-firm and compliance summaries, and we label it as such. Where we offer a judgement of our own, we say so. The framework is described as a living document, and you should read the current text before acting on any summary, including this one.
What it is, and what it is not
The framework is voluntary. Its language is built on "should consider" and "may consider", and we found no certification scheme or audit regime attached to it. It builds on IMDA's earlier Model AI Governance Framework, translating established principles into the setting of agents, and it sits alongside other IMDA work that the press release names, including the AI Verify toolkit and a starter kit for testing applications built on large language models.
It does not change the law. Obligations under existing legislation, the Personal Data Protection Act among them, apply to what an agent does as they do to any other system the organisation operates. A separate IMDA discussion paper on legal responsibility for AI agents, published in May 2026, takes up the question of who bears the loss when an agent causes harm. According to Latham & Watkins' summary, it looks at civil liability across the AI value chain and explores fault-based and strict liability approaches without reaching firm conclusions. Treat that question as open.
Voluntary does not mean ignorable, and this is our judgement, not IMDA's. A government-authored description of what responsible deployment looks like is likely to become the vocabulary in which boards, auditors, procurement teams and insurers ask whether you were careful. It is easier to have answered the questions in advance.
Who it applies to
The framework is addressed to organisations looking to deploy agentic AI, whether by developing agents in-house or using third-party agentic products. That second half matters. If you buy an agent embedded in a software package, you are a deploying organisation, and the framework places accountability with you, not with the supplier.
It identifies five actors in the value chain: model developers, providers of agentic systems, deploying organisations, providers of tooling, and end users. Responsibilities are shared, and the deploying organisation is the one that has to manage the relationships among them. According to Baker McKenzie's summary of the May update, the revision distinguishes more carefully between the roles of platform providers and those of system providers or application developers.
On definition, the framework refers to systems that can plan across multiple steps to achieve specified objectives, using AI agents, with a focus on agents built on language models. The practical dividing line, in our reading, is whether the system can act. An assistant that answers questions from a document set is probably outside the intended scope. A system that reads an email, decides what to do and updates a record is inside it.
How it frames risk
The framework organises risk around two things: what an agent can reach, and how independently it acts.
The first it calls action-space. It depends on which systems the agent can touch, from sandboxes to internal systems to external ones, and on what it may do there, with read access being a very different matter from write access. Agents that operate a computer directly, clicking and typing as a person would, widen the space considerably.
The second is autonomy. It depends on how detailed the instructions are, from step-by-step procedures to the agent's own judgement, and on how involved a person is. The framework describes four patterns: the agent proposes and a human operates; the agent and human collaborate; the agent operates and a human approves; the agent operates and a human observes. Moving along that list gives the agent more independence and the person less visibility.
It names five kinds of harm to guard against: erroneous actions, unauthorised actions, biased or unfair actions, data breaches, and disruption to connected systems. For systems with several agents it adds cascading effects and unpredictable outcomes arising from unintended coordination.
Dimension one: assess and bound the risks upfront
The first dimension asks you to decide whether a use case is suitable before you build it. Impact is judged by how much error the domain tolerates, what sensitive data and external systems the agent can reach, how wide its actions are and whether they can be reversed. Likelihood is judged by the agent's autonomy, the complexity of the task and its exposure to external systems. The framework also recommends threat modelling to identify the ways an attacker might compromise the system.
It then asks you to bound the risk through design. Give an agent only the minimum tools and data access its task needs. Constrain its autonomy with standard operating procedures. Build a way to take it offline when it malfunctions.
Agent identity gets particular attention. The framework suggests that each agent should have its own unique identity, which may be tied to a supervising agent, a human user or a department, and that the person directing an agent should not be able to grant it permissions beyond their own. It is candid that gaps exist in how identity is handled today, especially for dynamic permissions and for agents acting on behalf of several users. It also accepts that some risk remains after all this work, and that the organisation has to decide whether it is tolerable.
In practice this means an inventory of every agent, including the ones arriving inside purchased software, a written statement of what each is allowed to touch before it is built, and separate credentials for each agent instead of a shared service account.
Dimension two: make humans meaningfully accountable
The second dimension is about people. Inside the organisation the framework distinguishes decision makers who set goals and governance, product teams who design and implement, cybersecurity teams who test and defend, and end users who must use agents properly and report problems. Outside it, it asks you to settle responsibilities by contract and to check that external providers offer strong authentication, such as scoped API keys and per-agent identity tokens, along with usable observability. If they do not, it says you should reconsider whether the deployment stays within your risk tolerance.
On oversight, it asks for defined checkpoints where a human must approve an action: high-stakes decisions, irreversible actions, outlier or atypical behaviour, and boundaries the user has set. Approval requests should be short and clear. The framework is realistic that continuous oversight of every agent workflow becomes impractical at scale, which is why the checkpoints have to be chosen with care.
Its treatment of automation bias is the most useful part of this dimension. A person who approves everything is not providing oversight. The framework suggests training reviewers on the common failure modes of agents, auditing regularly whether human oversight is effective, and supplementing it with automated real-time monitoring and alert thresholds. Our own suggestion, which is not in the framework, is to look at the approval record itself. An approval rate close to total, or approvals that arrive within seconds of the request, are evidence that review has become a formality.
Dimension three: implement technical controls and processes
This is the longest dimension, and the most concrete. During design and development it covers how an agent plans, the tools it uses and the protocols it speaks. For tools it recommends strict input formats, least privilege, avoiding write access to sensitive databases unless necessary, whitelisting MCP servers and sandboxing code execution.
Before deployment it asks for testing across a broad list. That list includes accuracy of task execution, compliance with policy including approval routing, correct use of tools, behaviour under errors and edge cases, and the whole workflow instead of just the final output. Individual agents and multi-agent systems should be tested, in environments that resemble production, repeatedly and across varied data so that low-probability behaviour shows up. Different methods suit different parts: deterministic tests for tool calls, human or model-based evaluation for reasoning.
At deployment it recommends rolling out in stages, graduated by user group, by the tools available and by the systems exposed, beginning with trained users, whitelisted tools and lower-risk internal systems. It then asks for continuous monitoring: log and trace each step, concentrate on high-risk activity such as updating database records or financial transactions, use threshold-based alerts and anomaly detection, and in some cases have agents monitor other agents. Interventions should be proportionate, from scheduled review for low-priority alerts to halting execution for serious ones. Testing continues after launch to catch drift.
For an organisation this adds up to a test harness that checks the trace of what the agent did and not only its final answer, a staged pilot on the least sensitive systems, alert thresholds agreed before launch, and logs from which an event can be reconstructed afterwards.
Dimension four: enable end-user responsibility
The fourth dimension addresses the people who meet agents. For users facing an agent from outside, such as customers, it recommends transparency: declare that they are dealing with an agent, say what it is authorised to do, explain what data is collected and used, give a route to a human, and make clear that users are responsible for verifying information.
For employees who build agents into their work, it adds education. That means what the agent is for, how to instruct it, how it fails (the framework mentions hallucination and loops among the failure modes), and how to keep supervising it.
The unusual part is what it says about skills. As agents take over entry-level tasks, the framework warns that staff may lose the basic operational knowledge they would have gained doing that work. It asks organisations to identify the core capabilities of each job and give people enough training and exposure to retain them. Governance frameworks rarely mention workforce development. This one does, and it is right to.
What the May revision adds
Our information here is second-hand. According to the Baker McKenzie summary and a compliance guide from Modulos, the May 2026 update was released on 20 May, and Modulos labels the current document version 1.5. The summaries say it adds safety and reliability components, including access controls, guardrails, human approvals, logging and monitoring, as core parts of an agent. It widens the coverage of risk to multi-agent systems and third-party agent use, clarifies the responsibilities of platform providers against those of system providers and application developers, adds guidance on guarding against automation bias, and includes case studies from organisations. We have not read the revised text, so we cannot describe its provisions beyond that.
A sequence for an organisation
If we were setting out to take this seriously, we would work in roughly this order. Inventory every agent and every product that contains one. Classify each by what it can reach and how independently it acts. Assign a named person to each, and write down the actions that need that person's approval. Give each agent its own identity and the narrowest access that lets it do the job. Build tests that examine the trace, not just the answer. Roll out to a small group on low-risk systems first, with alerts agreed in advance. Keep logs that can reconstruct an event months later. Tell users what the agent can do and train the staff who will supervise it. Review contracts with every third party that supplies a model, a platform or a tool.
None of that requires waiting for a regulator. All of it is cheaper before an incident than after.
What is unresolved
The framework is straightforward about some gaps. Agent identity is immature. The volume of logs agents produce is hard to turn into insight. Liability is under discussion and has not been settled. Beyond those, a few limits are worth stating. The framework does not say how often a checkpoint should fire, or how to know that oversight is meaningful, which leaves a great deal of room for a compliant-looking programme that does very little. It does not tell you which tasks to automate. And because it is guidance, nobody will mark your work.
That last point is the real risk. A voluntary framework can be satisfied on paper in an afternoon. Its value depends on how specific you make each answer: which agent, which action, which person, which threshold, which log.
One note on products
We deliver on Kyros, powered by Kaman, a production agentic platform in which each class of action carries a gate: act automatically within limits, prepare for a named person's approval, or advise and leave the decision to a person. That resembles the spectrum of human involvement in the framework, but we make no claim of conformance, and the framework offers no certification against which to make one. The useful test is independent of any product. Pick an action your agents took last month and ask who authorised it, on what basis, and whether you can show it.
Sources
IMDA, Singapore launches new Model AI Governance Framework for Agentic AI, 22 January 2026. IMDA, Model AI Governance Framework for Agentic AI, January 2026 text. Baker McKenzie, IMDA updates Model AI Governance Framework for Agentic AI, June 2026. Latham & Watkins, Singapore AI guidance: governance, data protection and legal responsibility. Modulos, Singapore MGF for Agentic AI guide.