Picture a distributor of industrial consumables in Singapore, with about forty staff and a warehouse in Jurong. The operations director wants an AI agent to handle the dull half of procurement: read stock levels from the ERP, draft purchase orders, email suppliers for quotes and match the invoices that come back. Then someone in the meeting asks: "Is there a Singapore rule for this?"
The company is invented. The meeting is one we have often in Singapore and Kuala Lumpur.
The short answer: Singapore's Model AI Governance Framework for Agentic AI, published by IMDA (v1.5, 20 May 2026), is voluntary guidance, not law. It asks a company deploying an agent to do four things: assess and bound the risks upfront, make humans meaningfully accountable, put technical controls and processes in place across the lifecycle, and enable end-users to act responsibly. Your obligations under existing law, such as data protection and contract law, apply either way.
What follows turns those four dimensions into a checklist, with the evidence to keep at each step. I am an engineer, not a lawyer, so read the source documents before relying on any of it.
Key takeaways
- The framework is voluntary, but IMDA states plainly that the organisation deploying an agent stays accountable for what it does. Being voluntary changes who checks your work, not who answers for it.
- The most useful page is the list of risk factors in section 2.1.1. Score your agent against it before you write any code.
- IMDA's most repeated rule is to prefer deterministic limits to prompt instructions. Block the tool call; do not ask the model to avoid it.
- CSA's Securing Agentic AI addendum supplies the security controls. MAS's SAFR describes a runtime checkpoint for finance. Together they read like one stack.
- Keep evidence as you build. A risk assessment written after launch is worth very little.
What is the Model AI Governance Framework for Agentic AI?
IMDA first published the framework in January 2026. Version 1.5 followed on 20 May 2026 (updated 5 June). It adds case studies from OCBC, MSD, GovTech, PwC, Tencent and others, and new guidance on multi-agent systems, third-party agents and automation bias. It applies to agents you build and to agents you buy (IMDA).
It carries no penalties, but it leaves one point beyond doubt: "As deployers, organisations and humans remain accountable for the decisions and actions of agents." A purchase order your agent sends is a purchase order your company sent. If the agent leaks personal data, the PDPA still applies. IMDA's discussion paper on legal responsibility for AI agents sketches where liability may head.
Dimension 1: How do you assess and bound the risks upfront?
The framework treats risk as likelihood times impact, and lists the factors behind each. Impact depends on how much error the domain can tolerate, the agent's access to sensitive data and external systems, the scope of its actions, and how reversible those actions are. Likelihood depends on its autonomy, how complex the task is, its exposure to untrusted systems, whether a third party provides or runs it, and how complex the overall system is.
Here is an honest scoring of our procurement agent:
The scores are my own judgement; IMDA gives no numeric scale. What matters is which factors come out high. Here they are external systems, because the agent reads supplier emails and PDFs that anyone can write, and reversibility, because a sent PO can create an obligation to pay. The framework uses this very case: an action is hard to undo when it can "trigger downstream obligations e.g. entering into a contract or sale."
Then you bound the risk. IMDA's advice is concrete:
- Least privilege. The agent can read stock and supplier records and create a PO in draft. It cannot edit supplier bank details, and it has no general web or file access.
- Constrain autonomy with an SOP. Make reordering a fixed workflow, not a matter of the model's "judgment".
- Limit the area of impact. Make sure you can take the agent offline without stopping the business, and parse attachments in a sandbox.
- Give the agent its own identity. It should be unique, tied to a named owner and recorded in a central registry. Its authority is "bounded by authorising human's permissions", so the agent can never approve a PO its owner could not.
Then comes the line I would put on every agent team's wall: "prefer deterministic rather than non-deterministic limits, and bound by design." The framework's OpenClaw case study says the same about approvals: enforce them through system-level controls, because prompt-layer guardrails "may be bypassed or 'forgotten'". We made the same case in System Prompts Are Not Security Controls.
Evidence to keep: the scored risk assessment, a signed authority map and a written residual-risk decision. IMDA expects you to name the risk you have accepted, not claim there is none. Here is a sketch of an authority map for this agent. It is illustrative, not taken from a real deployment:
agent: procurement-agent-01
owner: head-of-purchasing # a named person, not a team alias
operations:
stock.read: allow
supplier.read: allow
po.create_draft: allow
po.submit: { approval: buyer, when: 'total_sgd > 5000 or new_supplier' }
po.submit_auto: { allow_if: 'total_sgd <= 5000 and supplier.approved and qty <= 2x_avg' }
supplier.update_bank_details: deny
email.send_external: { approval: buyer }
default: deny
Dimension 2: How do you make humans meaningfully accountable?
The word that matters is meaningfully. Most agent projects have a human in the loop on paper. Few check whether that human is actually reading.
The framework asks for a clear allocation of responsibility across decision makers, product teams, cybersecurity and users, and in vendor contracts too. It also asks for significant checkpoints where a human must approve: high-stakes actions, irreversible actions, outlier behaviour, and limits users set for themselves.
For the distributor, a buyer approves any PO over the threshold, any order to a new supplier and every external email. The agent also stops when a quantity falls far outside the usual pattern. IMDA's own example is a delivery route "twice as long as the median distance". A reorder of 4,800 cartons when you normally order 4,800 units is the same kind of signal.
Then comes the part most teams skip: IMDA asks you to audit the approvers. It names two signals, the override rate ("a low rate may signal rubber-stamping") and response time ("a shorter time may signal automation bias or review fatigue"). If a buyer approves 300 POs a week at four seconds each, you do not have oversight. You have a slow rubber stamp.
Approval requests should be short and state the risk. And if the approval system fails, for example when supervisors are unreachable, the framework says to deny by default. We wrote about that design in human-in-the-loop AI agents.
Evidence to keep: a RACI for the agent, the vendor contract clauses, the checkpoint list, an approval log (who approved, what, when, and how long it took) and a monthly review of override rates and response times.
Dimension 3: What technical controls, testing and monitoring does it expect?
Design and development. Use strict input formats on tools, give no write access to sensitive tables unless it is strictly needed, whitelist MCP servers, sandbox code execution, and make agents talk to each other through typed messages rather than free text. For anything high-risk, the framework prefers structural, rule-based controls to prompt-layer ones.
Before deployment. Test behaviour, not just answers: task execution, policy compliance (does it route for approval when it should?), and tool calling, meaning "the right tools, with the right permissions, with the right inputs and in the right order". Run the tests repeatedly, because agents are stochastic. In the case study of CDL and Knovel, testers used seven accounts across four data domains to check whether a restricted user could talk the agent into revealing another domain's data. Our equivalent is a supplier PDF with a hidden instruction: does the agent try to change the bank account? IMDA's Agentic Testing Starter Kit gives a four-step method.
During deployment. Roll out gradually. GovTech's first phase of agentic coding assistants went to its own staff only, with no MCP servers, on low-risk systems. Monitor on several layers, set alert thresholds and define an intervention for each alert. Keep "log immutability": if anyone can edit the log, you have no audit trail.
Throughout the lifecycle: change management. This is new in v1.5. A model update, a tool change, a business shift or a new regulation should each trigger a review, scaled to the risk. A prompt tweak gets a light review. A model swap or more autonomy gets a full governance review.
The security detail sits in the Cyber Security Agency's Securing Agentic AI addendum, published as v1.0 on 17 June 2026 after public consultation. It covers supply-chain checks on MCP packages, least privilege, network segmentation, input and output validation, and logging of every tool and MCP call. It also recommends taint tracing: once untrusted data enters a workflow, everything downstream is treated as untrusted. In our example, that means every action that follows from a supplier's email takes the stricter path. CSA says plainly that "these measures and controls are voluntary". For the threats themselves, see our guide to the OWASP Top 10 for Agentic Applications, which CSA also points to.
Evidence to keep: a threat model with the tainted paths marked, test results that include attempted disallowed actions, the rollout plan, alert definitions, an append-only action log and change-review records.
Dimension 4: What does "end-user responsibility" mean in practice?
People who interact with an agent should be told, at the point of interaction, that it is an agent. They should also know what it can do, how their data is used, and which named person to contact when it goes wrong. For the distributor, that means suppliers receiving agent-drafted emails can tell, and have a buyer's name to reply to.
People who use an agent in their own work, such as the buyers, need training on its failure modes and an easy way to flag a bad action. They also need something new in v1.5: protection against losing their own skills. If the agent drafts every PO for a year, will anyone remember how to reorder by hand when the ERP connector breaks the week before Chinese New Year? IMDA calls this a business continuity risk, and it is right.
Evidence to keep: the disclosure text, training records, an escalation contact list and a manual fallback someone has actually rehearsed.
How do the MGF, the CSA addendum, SAFR and the MAS guidelines fit together?
The MGF is the governance approach for every sector. CSA's addendum covers how to secure the agent. For financial institutions only, MAS issued its Guidelines on AI Risk Management on 7 October 2026. Unlike the MGF, these are supervisory expectations: AI inventories, human oversight, and accountability for third-party AI. According to Allen & Gledhill, they take effect from 7 October 2027, with some sections due by 7 October 2028.
SAFR (Safeguards for Agentic Finance at Runtime, v1.1, 9 October 2026) is an industry reference architecture from MAS's BuildFin.ai initiative. It says it "does not constitute regulatory guidance or supervisory expectations". It is still the most concrete engineering document of the four, and worth reading even if you are not a bank.
SAFR puts a checkpoint between every consequential action and its execution. The agent submits a "governance envelope" containing the action, the trace of steps behind it and the context. That envelope passes through four components: Agent Identity, a Controls Repository, a Disposition Engine and an append-only Audit Log. Every action ends in one of four outcomes:
Two lines from SAFR deserve a wider audience: "An agent cannot extend the scope of a mandate through its own reasoning or inference." And an approval at one step "carries no authority into the next". Escalations need a timeout too, after which the action "should default to block".
Apply that to the distributor and the PO flow writes itself. Deny changes to supplier bank details. Escalate POs over S$5,000 and orders to new suppliers. Auto-execute small reorders from approved suppliers. Observe anything unusual but within limits. Devs Core builds to this framework, and our AI governance approach follows the same principle: the model proposes and deterministic code decides. Autonomy is earned one operation at a time on the Autonomy Ladder.
What should Malaysian companies take from this?
The National Guidelines on AI Governance and Ethics (AIGE), launched by MOSTI in September 2024, are voluntary principles and are not specific to agents. The bigger change is the proposed AI Governance Bill. The National AI Office ran a public consultation on it from 10 to 31 July 2026. According to The Star, Digital Minister Gobind Singh Deo expects it in Parliament by the first quarter of 2027 at the latest. Law-firm summaries describe a risk-based approach, a central AI authority and incident reporting. I have not read the consultation paper itself, so treat those details as provisional.
My advice for a KL company: build to the four dimensions now. Scoped permissions, real approvals and immutable logs are what any risk-based law is likely to ask for.
Where should you start on Monday?
Score your agent against section 2.1.1. Write the authority map, and get the owner to sign it before anything is built. Make every approval a system-level control. Test the agent by having it attempt things it should not do. If you want a second pair of eyes on the risk assessment, our AI readiness audit starts there, and our AI agent development work follows this framework.
Frequently asked questions
Is Singapore's Model AI Governance Framework for Agentic AI mandatory?
No. It is voluntary guidance from IMDA with no penalties. Existing law still applies to what your agent does, and IMDA is explicit that the deploying organisation remains accountable.
What are the four dimensions of the MGF for Agentic AI?
Assess and bound the risks upfront. Make humans meaningfully accountable. Implement technical controls and processes: design controls, testing before deployment, monitoring during it, and change management. Enable end-user responsibility through transparency and training.
What is MAS SAFR?
Safeguards for Agentic Finance at Runtime is an industry reference architecture from MAS's BuildFin.ai initiative (v1.1, October 2026). It checks each consequential agent action before execution and returns Deny, Escalate, Auto-execute or Observe, recording every outcome in an append-only log. It is not regulatory guidance.
Does a Malaysian company need to follow it?
It does not have to. Malaysia has the voluntary AIGE guidelines and an AI Governance Bill expected in Parliament by early 2027. Many KL teams can use the Singapore framework as a working checklist in the meantime, especially if they sell into Singapore.