Singapore's Model AI Governance Framework for Agentic AI is a 53-page guidance document from the Infocomm Media Development Authority (IMDA). As of 7 October 2026 the current text is version 1.5, published on 20 May 2026 and updated on 5 June 2026. The first version was launched at the World Economic Forum in Davos on 22 January 2026. It is voluntary: it creates no legal obligation, penalty, registration duty or certification.
Read it closely anyway, wherever you operate. It is written for organizations that deploy agents, built or bought, and it is specific. A verifiable identity for every agent, kept in a central catalog. Authority scoped by task and by time. A human in front of irreversible actions. Monitoring with a defined response to each alert, a designed way to take an agent offline, and logs nobody can delete. Each is a control you can build and prove.
Below, we map each part of Singapore's agentic AI governance framework to a control and to the evidence an auditor would accept, alongside two other Singapore texts: the Cyber Security Agency's agentic addendum, which supplies the security detail, and the Personal Data Protection Act, which is the part that is law.
What exactly did Singapore publish, and is it binding?
The exact title is "Model AI Governance Framework for Agentic AI", which IMDA shortens to "MGF for Agentic AI". It extends IMDA's Model AI Governance Framework (second edition, 2020). The Ministry of Digital Development and Information (MDDI) announced the launch and called it "first-of-its-kind". Version 1.5 adds feedback from "60+ companies", a section on systemic and multi-agent risks such as agent sprawl, and new material on change management and automation bias. IMDA calls it "a living document".
Nothing in it binds anyone, and Members of Parliament have pressed on when that might change. A question answered on 6 May 2026 asked what would trigger "transitioning the Framework from a voluntary code to enforceable standards for high-risk sectors". Another, on 5 August 2026, asked about moving "from voluntary to mandatory requirements for high-consequence deployments". MDDI pointed to monitoring with sector regulators and to its answer of 7 July 2026, which says the government "will continue to study the appropriate regulatory stance for AI".
A reply on 6 October 2026 points somewhere more specific. In that reply to Parliament, MDDI said: "For essential services and other higher-risk applications, stronger safeguards are necessary." Those could include "more rigorous testing for risks, independently verifiable evidence that safeguards are effective, tighter deployment controls or tighter regulatory oversight." As of 7 October 2026, no new requirement has been announced. But the second item describes an audit file, and audit files are cheaper to build before a deadline.
Voluntary is not the same as irrelevant when an agent causes harm. IMDA's May 2026 discussion paper on legal responsibility for AI agents records a working group's views, not settled law. Its general view on negligence: "where an actor implemented insufficient safeguards, particularly within its area of control, the actor would fall short of its standard of care". It also admits the reasonable level is hard to pin down. Our view, not the paper's: a government-published list of safeguards is where that argument will start.
What does each of the four dimensions ask for?
The substance is in Section 2, four dimensions that IMDA says "should be viewed as an iterative process".
1. Assess and bound the risks upfront (§2.1). Rate each use case on impact (tolerance for error, access to sensitive data and external systems, read versus write, reversibility) and on likelihood (autonomy, task complexity, exposure to systems others maintain, third-party provision, system complexity). "Not all use cases are suitable for agents, and some may be better served by deterministic workflows." Bound what remains with least privilege, standard operating procedures, a unique identity per agent, scoped authority and mechanisms "to take agents offline". The governing instruction: "prefer deterministic rather than non-deterministic limits, and bound by design."
A case study in the document shows the result. Dayos tiered its IT tickets by severity, reversibility and whether a human could realistically review them. Password resets run automated with biweekly audits, and moderate changes need an engineer's sign-off. For production deployments, security changes and permission modifications: "Agent does not touch these."
2. Make humans meaningfully accountable (§2.2). Assign responsibilities across decision makers, product teams, cybersecurity teams and users, and settle obligations with vendors by contract. Require approval at "significant checkpoints": high-stakes actions, irreversible ones such as "permanently deleting data, sending communications, making payments", atypical behavior, and limits users set for themselves. Audit whether the approvals mean anything, and fall back to "[d]enying action by default when approval infrastructures fail".
3. Implement technical controls and processes (§2.3). Prefer structural, rule-based controls to prompt instructions, add runtime controls such as rate limits, and allowlist trusted MCP servers. Test tool calling before release, meaning "whether an agent calls the right tools, with the right permissions, with the right inputs and in the right order". Roll out in stages; GovTech's own rollout of coding agents began with internal staff, low-risk systems and no MCP servers at all. Then monitor with alert thresholds and a set intervention per alert, keep logs immutable, and force a change review when a model, a tool or the business context changes.
4. Enable end-user responsibility (§2.4). Tell people they are dealing with an agent "at the point of interaction", what it may do, how it uses their data and whom to contact. Train the staff who use and oversee agents, and keep their tradecraft alive, or users "may no longer know how to perform critical processes manually when agents malfunction or become unavailable."
How does the framework map to controls you can evidence?
The framework has no certification scheme, so "auditor" means whoever tests your claims: internal audit, a customer's due-diligence team, or a sector supervisor applying its own rules. Section numbers are IMDA's version 1.5, "CSA" is the Cyber Security Agency of Singapore's addendum, and bracketed numbers are the matching controls in our AI agent governance framework template.
| What Singapore's framework asks | The control | Evidence an auditor would accept |
|---|---|---|
| §2.1.1: rate each use case on impact and likelihood, and decide whether the residual risk is tolerable | A risk-tiering gate: nothing reaches production without a recorded tier and a named owner accepting the residual risk | Per-agent assessment with factor ratings, tier, approver, and a date before go-live |
| §2.1.2: a unique, "cryptographically verifiable identity" per agent, "issued from and tracked by a centralised system"; CSA 2.6: a "trusted registry of agent identities" | Agent inventory and identity registry, reconciled against discovery [1, 9] | Registry export with ID, owner and expiry; a reconciliation report with exceptions closed; records of retired identities |
| §2.1.2: authority "scoped, time- or session-bound, non-transferable", never broader than the authorizing human's, with delegations recorded; CSA 2.7: "Do not allow agents to modify privileges" | Per-tool scopes and short-lived credentials, bounded by the requesting user's entitlements [2] | Scope and token-lifetime records; a delegation log; a quarterly least-privilege review with drift fixed |
| §2.1.2 and §2.3.1: limits enforced at the tool layer rather than by prompt; allowlisted MCP servers; sandboxed code execution | Tool and MCP server allowlists enforced outside the model [3] | Allowlist with change history; blocked-call logs; a test in which a disallowed action was attempted and stopped |
| §2.2.2: approval at "significant checkpoints", written justification for high-risk actions, fail-closed approvals, and audits of override rates and response times | System-enforced approval gates for listed action classes, defaulting to deny, with oversight metrics reviewed monthly [5] | The action-class list; an approval log showing what each approver saw and decided; a fail-closed test; the monthly override report |
| §2.3.2 and §2.3.3: test task execution, policy compliance and tool calling across whole workflows, then roll out in stages | A release gate backed by an agent test suite, and a staged rollout plan | Test results tied to a release; red-team findings and fixes; the criteria used to widen access |
| §2.3.3: monitor the user, tool and reasoning layers, with alert thresholds and a set intervention per alert; CSA: agent logs streamed to a SIEM | Agent telemetry in the SOC, with alert rules mapped to interventions [3, 7] | Alert catalog with thresholds and interventions; proof of SIEM ingestion; sample alerts with dispositions |
| §2.1.2: mechanisms "to take agents offline"; §2.3.3: "termination and fallback solutions"; CSA 4.3: circuit breakers that "freeze propagation" | A kill switch that halts runs and revokes credentials, circuit breakers between agents, and a manual fallback [6] | A runbook naming who can trigger it; timed halt and revocation tests; a record of the fallback being exercised |
| §2.3.3: "Ensure log immutability"; CSA 4.3: "immutable, tamper-evident audit logs that capture prompts, responses, and tool invocations" | An attributed, tamper-evident audit trail with one trace ID across agents and tools [7] | The log schema; the immutability setting; one real decision rebuilt from its trace ID; retention settings |
| §2.3.3: "reporting and failsafe mechanisms for agent failures"; CSA 4.5: a vulnerability disclosure process | An agent incident playbook joined to the PDPA breach assessment | The playbook; a tabletop record; tickets timestamped at detection, containment and breach assessment |
| §2.2.1: contract terms on security and data protection, and "scoped API keys, per-agent identity tokens, and observability such as the logging of tool calls and access history" | Vendor agent due diligence and contract clauses [8] | The completed questionnaire, the executed clauses, and a sample log export from the vendor |
| §2.4: disclosure "at the point of interaction", human contact points, and training | Interface disclosure, a factsheet per agent, and role-based training | Screenshots, factsheets, published escalation contacts, training records |
Rows without a bracketed number have no direct match among the template's nine controls, so add them as rows of your own.
What does it ask for that most agent programs skip?
Much of that table will look familiar from OWASP's agentic list or our consolidated agent governance framework. Four asks are rarer, and we would start with them.
Measure the approvers. An approval log proves a button was clicked. The framework wants the override rate, "the frequency at which humans reject or modify agent actions", and warns that a low rate "may signal rubber-stamping". It wants reviewer response times as well. Both numbers can be computed from the approval log itself.
Cap the agent at the human's permissions. The framework's rule of thumb is that the human user "should not be able to set permissions for the agent greater than what the human user is himself authorised to do". An agent on a broad shared service account breaks that rule by design. Our piece on agent scope creep covers how access outgrows what anyone approved.
Design the stop before launch. The framework first raises taking an agent offline in dimension one, as a design-time limit, long before monitoring and termination come up in §2.3.3. That ordering is right. Our incident response playbook for agents shows why revoking one token rarely halts an agent with calls already in flight.
Stop counting prompts as controls. IMDA's OpenClaw case study says to enforce human approval "through system-level controls where possible, vs prompt-layer guardrails, which may be bypassed or 'forgotten'". MDDI's reply of 6 October 2026 was blunter: "We cannot rely on simply telling AI agents what to do."
One more is easy to miss. The tradecraft warning in dimension four is business continuity in disguise: if nobody remembers the manual process, your kill switch also stops the business.
Where does the CSA's agentic addendum fit?
The Cyber Security Agency of Singapore (CSA, not the Cloud Security Alliance) publishes Securing Agentic AI, an addendum to its Guidelines and Companion Guide on Securing AI Systems from October 2024. Version 0.1 went to public consultation from 22 October to 31 December 2025. Version 1.0, the official publication, is dated 17 June 2026, which is why IMDA's text, updated on 5 June 2026, still cites a draft.
It is voluntary as well: "not mandatory, prescriptive nor exhaustive", in its own words. Where IMDA says what to govern, CSA says how to secure it, in controls numbered by lifecycle stage from 1.1 (risk assessment) to 4.5 (vulnerability disclosure). Several lines convert straight into requirements: "Treat agents as non-human identities"; use "time-bound (just-in-time) or one-time-use credentials where possible"; "Validate permissions on every request to each agent in the workflow." Our agentic identity piece argues that agents need more than that, including action-level scoping and a provable chain of delegation.
What actually binds a company running agents in Singapore?
The Personal Data Protection Act 2012 does, once an agent touches personal data, whether or not you adopt the framework. Section 24 requires "reasonable security arrangements" against "unauthorised access, collection, use, disclosure, copying, modification or disposal, or similar risks", and the framework notes that agents can wrongly modify data as well as leak it. Section 26C requires a suspected breach to be assessed "in a reasonable and expeditious manner". If it is notifiable under section 26B (significant harm or significant scale), section 26D requires notice to the Personal Data Protection Commission (PDPC) "as soon as is practicable" and no later than three calendar days after the day of that assessment.
One wrinkle matters for agents. Section 26B(4) deems a breach confined to unauthorized access or use inside the organization not notifiable. An agent that shows payroll records to the wrong employee can still raise a section 24 question without triggering notice, so the playbook should make that call explicitly and record why.
Two more texts sit around the Act. The PDPC's Advisory Guidelines on Use of Personal Data in AI Recommendation and Decision Systems, issued on 1 March 2024, explain how consent, notification and accountability apply to AI systems, and say they "are advisory in nature, are not legally binding". For financial institutions, the Monetary Authority of Singapore issued Guidelines on AI Risk Management on 7 October 2026: supervisory expectations, effective 7 October 2027, with Sections 5 and 6 due by 7 October 2028. They ask institutions to "maintain inventories at an appropriate level of granularity", and MAS plans to consult in 2027 "on what additional guidance on agentic AI would be useful".
How do you start, and where does the template fit?
Start with the inventory, because every row above assumes you know which agents exist, who owns them and what they can touch. Tier them with the §2.1.1 factors. For the top tier, build four things first: approval gates that fail closed, a tested stop, tamper-evident logs, and a playbook that includes the PDPA assessment.
Our AI agent governance framework template is an XLSX with nine controls, an owner and an evidence field for each, and a 27-item checklist. It was built from seventeen other frameworks and does not cite Singapore's, so add a column for the IMDA and CSA references above. Our agentic AI governance hub collects the rest of our agent work, including what an agent audit log should capture.
For the runtime rows, AccuroAI's AI Agent Security inspects tool calls inline at under 38ms p99 and can quarantine an agent session. No product makes you compliant with a voluntary framework; it can only generate the evidence in that right-hand column.
Last verified: 8 October 2026, against IMDA's version 1.5 PDF, CSA's addendum version 1.0, the PDPA on Singapore Statutes Online, the PDPC guidelines, MAS's 7 October 2026 release and MDDI's parliamentary replies of 6 May, 7 July, 5 August and 6 October 2026.
The Model AI Governance Framework for Agentic AI is voluntary guidance, and nothing in this article is legal advice.