Guide · Singapore
Singapore's Model AI Governance Framework for Agentic AI, explained
The Model AI Governance Framework for Agentic AI is IMDA's guidance for organisations in Singapore that deploy AI agents. Launched on 22 January 2026 and updated to version 1.5 on 20 May 2026, it rests on four dimensions: assess and bound the risks upfront, make humans meaningfully accountable, implement technical controls and processes, and enable end-user responsibility. It is voluntary guidance, not law, and it certifies nothing.
In this guide
- What the framework is, and who it is for
- Is it mandatory?
- The four dimensions
- Agents working with other agents and systems
- What the framework asks, in practice
- Common mistakes
- How Olano helps
What is the Model AI Governance Framework for Agentic AI?
It is IMDA's set of risks and recommended practices for deploying AI agents: systems that plan and act over several steps, such as updating a customer record or making a payment. It is "targeted at organisations looking to deploy agentic AI, whether by developing AI agents in-house or using third-party agentic solutions", so it covers an agent you buy as much as one you build.
Minister Josephine Teo announced it at the World Economic Forum in Davos on 22 January 2026 (IMDA press release). Version 1.5 followed on 20 May 2026 (IMDA factsheet), drawing on feedback from more than 60 organisations and adding more than ten case studies. The framework document is marked "Published 20 May 2026 (Updated 5 June 2026)".
Its core message: "Humans must remain accountable and properly manage these risks." It does not ask for constant supervision, since "continuous human oversight over all agent workflows becomes impractical at scale".
How it fits with IMDA's earlier AI governance frameworks
| Document | Published | What it covers |
|---|---|---|
| Model AI Governance Framework | 2019; second edition 21 January 2020 | Traditional AI: internal governance, human involvement in AI-assisted decisions, operations, stakeholder communication |
| Model AI Governance Framework for Generative AI | 2024, with the AI Verify Foundation | Extends the 2020 edition to generative AI |
| AI Verify | Piloted 2022; open-sourced 2023 | A testing framework and open-source toolkit for testing your own AI systems |
| Model AI Governance Framework for Agentic AI | January 2026; version 1.5 May 2026 | AI agents, including multi-agent systems |
Sources: the PDPC's Model AI Governance Framework page and IMDA's artificial intelligence page, checked 16 October 2026.
Is the Model AI Governance Framework for Agentic AI mandatory?
No. It is voluntary guidance: in IMDA's words it "provides guidance to organisations on how to deploy agents responsibly", and no registration, licence or certificate is attached. IMDA calls it "a living document" and invites feedback and case studies, which is how version 1.5 arrived four months after launch.
Two things are not optional. The PDPA applies to any agent that handles personal data; our PDPA guide for AI agents covers the practical side. And the accountability point holds regardless: if an agent you deployed causes harm, a person in your organisation is accountable, and "the vendor's agent did it" does not change that.
What are the four dimensions of the framework?
Assess and bound the risks upfront, make humans meaningfully accountable, implement technical controls and processes, and enable end-user responsibility.
1. Assess and bound the risks upfront
An agent's risk depends on "the scope of actions the agent can take, the reversibility of those actions, and the agent's level of autonomy"; version 1.5 adds system complexity and the use of third-party solutions. The framework then asks you to bound it by design: "least-privilege policies that give agents only the minimum tools and data access needed", standard procedures the agent must follow, the ability to "take agents offline", and sandboxes for high-risk work such as code execution. Each agent should have its own identity, and a person "should not be able to set permissions for the agent greater than what the human user is himself authorised to do".
On enforcement it is blunt: "prefer deterministic rather than non-deterministic limits". Rather than telling an agent not to use a tool, block the tool. In one case study, Dayos, a Singapore company, tiered its IT agent's tasks by severity and reversibility: password resets are automated and audited every two weeks, moderate fixes need an engineer's approval, and permission changes are out of the agent's reach.
2. Make humans meaningfully accountable
Responsibility has to be allocated inside the organisation and outside it. For vendors, settle security and data protection in the contract and ask for "scoped API keys, per-agent identity tokens" and logging of tool calls. For oversight, "define significant checkpoints or action boundaries that require human approval", such as irreversible actions, "e.g. permanently deleting data, sending communications, making payments".
Version 1.5 also asks you to audit the oversight itself. A low "human override rate" "may signal rubber-stamping", reviewer response times are worth tracking, and the system should be "denying action by default when approval infrastructures fail".
3. Implement technical controls and processes
During development, prefer "deterministic safeguards that operate at a system-level" to prompt-layer ones, and add runtime controls "such as rate limits to prevent excessive tool use". Before deployment, test the agent's accuracy, policy adherence and tool use. After deployment, roll out gradually, monitor with alert thresholds, and "ensure log immutability". Version 1.5 adds change management: a model update or a change in autonomy gets a proper review.
4. Enable end-user responsibility
Customers and other people who deal with an agent need transparency: "Declare upfront in the user interface that the users are interacting with agents at the point of interaction", explain what the agent can do and how their data is used, and give them a human contact. Staff who use agents also need training, including on failure modes and on keeping the core skills ("tradecraft") agents could erode.
What does the framework say about agents interacting with other agents and external systems?
It treats this as a main source of new risk: as organisations deploy "multiple agents with complex interactions, outcomes also become more unpredictable". Version 1.5 names agent sprawl (agents multiplying "without centralised management"), collaborative failures (miscoordination, conflict between agents with different goals, and collusion) and data leakage, where shared context ends up "passed to less secure agents".
It names the Model Context Protocol for agent-to-tool connections and the Agent2Agent protocol for agent-to-agent communication, and warns that protocols "can be poorly deployed or compromised e.g. deploying an untrusted MCP server". The suggested controls: whitelist trusted MCP servers, sandbox code execution, use structured messages between agents, limit shared memory, and log agent-to-agent interactions. Our explainer on the A2A protocol covers the agent-to-agent side.
IMDA's case study on OpenClaw, the open-source personal agent, generalises well: avoid a single "all-powerful" agent and "attempt disallowed actions to ensure restrictions work" before going live. If you are weighing OpenClaw itself, see OpenClaw alternatives.
What the framework asks, and what it looks like in practice
The framework never says which settings to turn on. This table is our translation: each recommendation, what it means in practice, and the control that does the job on Olano. It describes controls, not compliance.
| What the framework asks | What that looks like in practice | How Olano implements it |
|---|---|---|
| Least-privilege access to tools and data | Each agent gets only the connectors and keys its job needs; several narrow agents, not one that does everything | Tools are granted per agent, and credentials sit in a vault resolved per agent, so each agent sees only what it was given. |
| Bound the area of impact; be able to take agents offline | Sandboxed execution, limited network reach, a quick way to stop an agent | Each deployment is its own isolated environment, and on a managed deployment each agent's file and shell tools run in their own container. Outbound access can be held to an allow list. Every agent has a Stop button on the roster. |
| System-level limits, not prompt instructions | Approval rules enforced by the platform | Trust levels 0 to 4, approval profiles (Trusted, Supervised, Locked down), category toggles and per-tool "always" or "never" overrides, all enforced by the runtime. |
| Human checkpoints for irreversible actions | Anything that leaves the business or cannot be undone waits for a person | Browser actions that submit, buy, pay, send, post or delete ask a person every time, whatever mode is on. In Cortex background work, outbound sends, irreversible actions and rewrites of the agent's own instructions wait for a human by default. |
| Deny by default when approval fails | No answer means no action | An unanswered approval times out (300 seconds by default) and the action does not run. |
| Audit the oversight itself | A reviewable record of approval decisions | Approval history records each request, its outcome, who decided and through which surface. Reviewing it for rubber-stamping is a job you schedule. |
| Immutable, attributable logs; change management | Reconstruct who did what, and who changed the agent | An append-only audit trail attributes every action to a person or agent. Revisions keep a history of configuration and workspace files, attributed to whoever made each change, with secrets redacted. |
| Manage multi-agent interactions and sprawl | Decide which agents may message which; one register of agents | An org chart and allow-lists decide who may message whom (until you set them, agents on one deployment may message each other); the Agent to Agent tab shows every exchange. |
| Whitelist trusted external tools and agents | Only approved MCP servers and remote agents, each with its own credential | An agent reaches a remote A2A agent only by a name in its configuration, which it cannot add to; replies count as input, not instructions. MCP servers come from a curated directory; anything else is added as external, at the owner's risk. |
| Control inbound access | External doors stay shut until someone opens them | MCP and A2A external access is off by default at deployment and agent level, and needs an administrator's token or consent. Outside callers run as non-owners, so risky actions wait in Approvals. |
| Runtime controls such as rate limits | Spending and volume have a ceiling | Per-agent budgets with an alert, a cheaper fallback model or a hard stop. A message policy for public-facing agents caps message length and drops spam before any model call. |
| Tell users they are dealing with an agent | The first reply says it is an AI and how to reach a person | Your wording, not a setting: it goes in the agent's instructions. For outside callers over MCP or A2A, a public description of the agent is compulsory. |
Olano controls as documented in the Olano user guide and on olano.ai/security, checked 16 October 2026.
Common mistakes when applying the framework
- Treating it as a badge. IMDA does not certify conformance, so "IMDA-compliant" on a vendor's page means little. Ask which controls exist and where you can see them.
- Writing limits into the prompt. IMDA's OpenClaw case study says prompt-layer guardrails "may be bypassed or 'forgotten'". The limit has to live in the platform.
- Approving everything. A queue cleared in bulk is the automation bias version 1.5 warns about. Gate fewer, more meaningful actions.
- Skipping the test of what should fail. Try what the agent must not do, and confirm it stops.
- Forgetting the PDPA. The framework does not replace it.
How Olano helps
Olano Studio designs and deploys agent systems for Singapore businesses on the Olano platform, and most of what the framework asks for is how we set them up: one workflow at a time, narrow agents, approvals on what leaves the business, budgets with a hard ceiling, and an audit trail someone on your side reads. In scoping we walk through the four dimensions with you, because the organisational parts (who owns each agent, who approves what, what customers are told) are your decisions.
What we do not do: certify your deployment, give legal advice, or declare the framework "met". The residual risk is yours to accept, and approval settings are configuration an owner can loosen, so the controls are only as strong as the settings you keep. What we can do is show each control in the table running on your own system before anything goes live. See our services for how an engagement runs, and our map of Singapore's AI programmes for where the framework sits.
FAQ
Is the Model AI Governance Framework for Agentic AI mandatory?
No. It is voluntary guidance from IMDA, with no registration, licence or certificate attached, and IMDA updates it as a living document. Binding law still applies alongside it, most relevantly the PDPA for any agent that handles personal data.
When was the framework launched, and what is the current version?
It was announced at the World Economic Forum in Davos on 22 January 2026. IMDA published version 1.5 on 20 May 2026, with feedback from more than 60 organisations and more than ten case studies; the document is marked as updated on 5 June 2026.
What are the four dimensions of the framework?
Assess and bound the risks upfront; make humans meaningfully accountable; implement technical controls and processes; and enable end-user responsibility. In short: limit each agent, put people at the checkpoints that matter, enforce controls in the system, and tell users what they are dealing with.
Does the framework apply to AI agents we buy rather than build?
Yes. IMDA aims it at organisations deploying agents in-house or through third-party solutions. For bought agents it suggests settling security and data protection in the contract and asking for scoped credentials, per-agent identities and logging.
Does following the framework make our AI agents certified?
No. IMDA does not certify conformance with it, and AI Verify is a testing toolkit rather than an approval. Following it is good evidence of responsible deployment, but it does not replace the PDPA or sector rules. This is general information, not legal advice.
Related reading
PDPA and AI agents
The binding law alongside the framework, and questions for any vendor.
Singapore's AI programmes for business
Where the governance frameworks sit among NAIIP, the GenAI Sandbox and EDGE.
Human in the loop
What approval checkpoints are, and where they belong in an agent's work.
The A2A protocol
How agents talk to agents across organisations, and what to lock down.
Olano Studio services
How we scope, build and run agent systems, with approvals designed in.
Checked 16 October 2026 against IMDA's framework document (version 1.5, published 20 May 2026, updated 5 June 2026), IMDA's January 2026 press release and May 2026 factsheet, IMDA's artificial intelligence page and the PDPC's Model AI Governance Framework page. This article is general information, not legal advice. The framework is voluntary guidance and certifies nothing, and the PDPA applies separately. Describing an Olano control is not a claim that any deployment complies with the framework or any law.
Want to see the four dimensions on your own workflow?
Book a consultation. We will map one workflow against the framework, show the controls that bound it, and quote the build as a fixed proposal.