The Model AI Governance Framework for Agentic AI is guidance from Singapore’s Infocomm Media Development Authority (IMDA) on deploying AI agents responsibly. It asks organizations to assess and bound the risks upfront, make humans meaningfully accountable, implement technical controls and processes, and enable end-user responsibility. For support, that means scoped permissions, approval checkpoints, testing, monitoring and disclosure.
In short
- IMDA launched the framework on January 22, 2026; the current text is version 1.5, published May 20, 2026 and updated June 5, 2026.
- It is guidance, not law: it describes “emerging best practices,” calls itself a living document and sets no penalties.
- It names customer service agents as agents that interact with users, and asks for AI disclosure in the interface at the point of interaction.
- The mapping table below turns each section into a step for a support AI agent and the evidence to keep.
- If you serve EU customers, the EU AI Act is the binding layer on top; the two overlap most on disclosure.
This explainer is written from the primary source and is not legal advice. It sits under our guide to AI agent governance.
What is the Model AI Governance Framework for Agentic AI?
The Model AI Governance Framework for Agentic AI is a 53-page IMDA document that gives organizations “a structured overview of the risks of agentic AI and emerging best practices in managing these risks.” It is written for organizations deploying AI agents, whether they build them in-house or use third-party agentic solutions.
| Item | What the source says |
|---|---|
| Exact title | Model AI Governance Framework for Agentic AI |
| Publisher | Infocomm Media Development Authority of Singapore (IMDA) |
| Launch | Announced by Minister Josephine Teo at the World Economic Forum in Davos, January 22, 2026 (MDDI release) |
| Current version | Version 1.5, published May 20, 2026, updated June 5, 2026 (IMDA PDF) |
| What 1.5 changed | Feedback from 60+ companies, new risk factors, multi-agent risks, override-rate monitoring, change management, case studies |
| Builds on | IMDA’s Model AI Governance Framework (2020) |
Part 1 explains what an agent is and what can go wrong. Part 2 is the framework itself, in four dimensions:
- 2.1 Assess and bound the risks upfront: suitable use cases (2.1.1); agent limits, identity and permissions (2.1.2).
- 2.2 Make humans meaningfully accountable: responsibilities inside and outside the organization (2.2.1); meaningful human oversight (2.2.2).
- 2.3 Implement technical controls and processes: controls in design (2.3.1), testing before deployment (2.3.2), rollout, monitoring and change management after (2.3.3).
- 2.4 Enable end-user responsibility: transparency for users who interact with agents (2.4.2); training for users who work with them (2.4.3).
Is Singapore’s agentic AI framework mandatory?
No. The framework presents itself as guidance: it offers “emerging best practices,” most recommendations read “organisations should consider,” and it calls itself “a living document.” The launch release says it “provides guidance to organisations on how to deploy agents responsibly.” It sets no penalties and no enforcement mechanism of its own.
The document does not use the word “voluntary,” so describe it precisely internally: non-statutory guidance from a regulator. Your legal duties under data protection, consumer and sector rules apply either way, and the framework is clear that “the organisations that deploy agents and the humans who oversee them remain accountable for the agents’ actions.”
What risks does the framework say AI agents create?
The framework lists five types of harm from agents: erroneous actions, unauthorized actions, biased or unfair actions, data breaches, and disruption to connected systems. It adds systemic risks from speed and volume, cascading errors and multi-agent setups. Each one has a plain support example.
| Risk in the framework | In customer service |
|---|---|
| Erroneous actions | The agent refunds the wrong order |
| Unauthorized actions | The agent grants a fee waiver that policy says needs a supervisor |
| Biased or unfair actions | Goodwill credits offered more often to one customer group |
| Data breaches | The agent reveals another customer’s address or overwrites a record |
| Disruption to connected systems | The agent floods the order system with repeated lookups |
| Speed and volume | One flawed instruction repeats across thousands of conversations |
IMDA’s own example of multi-agent conflict is a support case: “a customer support agent may offer refunds to resolve complaints quickly, while a revenue protection agent may block refunds above a certain threshold.” If you are moving toward agentic customer service with agents handing off to each other, that conflict is a design question.
How does each part of the framework apply to a customer service AI agent?
Each dimension becomes a few decisions for the support team: which intents the agent may handle and with which permissions, who owns it and approves what, how it is tested and watched, and what customers and staff are told. The steps follow the framework’s own section order.
2.1 Assess and bound the risks upfront
The framework assesses risk on impact (domain and use case, sensitive data, external systems, read or write, reversibility) and likelihood (autonomy, task complexity, exposure to external systems, third-party provision, system complexity). Apply it per intent, not per bot:
- Tier your intents. Order status is read-only. A refund is a write action with money attached. Closing an account is hard to reverse.
- Use least privilege: “the minimum tools and data access needed.” Read access for order status, not admin rights in the helpdesk.
- Constrain process tasks with an SOP rather than free judgment. Refund and cancellation flows are exactly that.
- Plan how to take the agent offline for one intent or channel, name who can do it, and test it.
- Give the agent its own identity, tied to a human owner, with permissions never greater than those of the person who authorizes it.
2.2 Make humans meaningfully accountable
Name an owner for use cases and limits, a team for design, testing and monitoring, and a security owner for guardrails and red teaming. If the agent comes from a vendor, the framework asks you to settle security, performance and data protection in the contract, and to request disclosures and logging of tool use and access history. Our AI QA security checklist has procurement questions to reuse.
Require approval at “significant checkpoints”: high-stakes actions, irreversible actions (the framework names sending communications and making payments), outlier behavior and user-defined limits. Then audit the approvers with two indicators: the human override rate, where “a low rate may signal rubber-stamping,” and response time, where a short time “may signal automation bias or review fatigue.”
2.3 Implement technical controls and processes
Prefer controls enforced by the system over controls in the prompt. The framework’s example: “rather than instructing an agent not to use specific tools, access controls can be implemented at the tool layer.” Put the refund cap in the refund API, not in the system prompt.
Before launch, test task execution, policy compliance (including routing to human approval), tool calling and robustness, across the whole workflow, repeatedly and on varied data. Our guide to AI agent testing turns this into a test plan. After launch, roll out gradually, monitor continuously, set alert thresholds with a defined intervention for each, keep logs that cannot be deleted, and review changes to models, tools and policies by risk. The AI agent monitoring guide covers alert design.
2.4 Enable end-user responsibility
This section names customer service directly. The framework asks you to “declare upfront in the user interface that the users are interacting with agents at the point of interaction, rather than writing it only in separate documentation,” and to tell users what the agent may do, how their data is used and which human to contact. For staff, it adds training on failure modes and a warning about “loss of tradecraft”: keep enough people able to run the process when the agent is down.
What evidence should a support team keep for each part of the framework?
Keep evidence someone could check without asking you: a register, a signed decision, a test result, a log, a screenshot. The framework does not prescribe documents, so this table is our translation of each section into the record a support team could show an auditor, a regulator or its own board.
| Framework section | What it means for a support AI agent | Evidence to keep |
|---|---|---|
| 2.1.1 Suitable use cases | Each intent tiered by impact and likelihood before the agent handles it | Use-case register: intent, tier, risk factors, approver, date |
| 2.1.2 Agent limits and residual risk | Read or write per tool, money caps, SOPs, a tested switch-off, accepted residual risk | Permission matrix, SOP version, last switch-off test, signed risk acceptance |
| 2.1.2 Identity and authorization | Own credentials, a named owner, no more rights than the authorizing person | Agent identity register with owner and credential scopes |
| 2.2.1 Responsibilities inside | Owners for use cases, design and testing, security, daily review | RACI, reviewed at each change |
| 2.2.1 Responsibilities outside | Vendor duties on security, performance and data; visibility into tool use | Contract clauses, vendor disclosures, proof you can export logs |
| 2.2.2 Human oversight | Approvals for high-stakes and irreversible actions, each showing risk and confidence | Approval log; monthly override rate and median response time per approver |
| 2.3.1 Technical controls | Limits enforced in the system; sensitive data such as passwords entered by the customer, not handled by the agent | Control list with where each control is enforced |
| 2.3.2 Pre-deployment testing | Task execution, policy compliance, tool calling, robustness; full workflow; repeated runs | Test set, pass thresholds, results per run, sign-off |
| 2.3.3 Rollout, monitoring, change | Staged rollout; every conversation checked against policy; alerts; changes reviewed by risk | Rollout gates, QA scores and alert history, incident log, change log |
| 2.4.2 Users who interact | AI disclosure in the chat, what the agent can do, data use, a human contact | Disclosure screenshot per channel and language; help-center page; escalation path |
| 2.4.3 Users who work with agents | Supervisors trained on failure modes; manual fallback kept | Training records; a manual fallback drill |
Most of this evidence goes stale, because the framework treats monitoring as ongoing. And a small sample is weak evidence for an agent that repeats one behavior thousands of times, which argues for checking every conversation against policy with an AI agent scorecard.
How do you set approval checkpoints without causing alert fatigue?
Set approvals by risk tier, not by action count, then check whether approvers still think. The framework warns that continuous human approval “can also lead to automation bias and alert fatigue,” and names two signals, a low override rate and short response times. It gives no thresholds, so you set your own.
An illustration, with numbers we chose to show the arithmetic (not data from any company). A retailer’s AI agent handles 40,000 conversations a month:
| Tier | Example intents | Share | A month | Human role |
|---|---|---|---|---|
| 1 | Order status, delivery, address change before shipping | 70% | 28,000 | None at the time; scored afterwards |
| 2 | Refunds and fee waivers | 25% | 10,000 | Approval only above a $50 refund |
| 3 | Account closure, legal complaints, chargebacks | 5% | 2,000 | Agent hands off; a person acts |
Approving every Tier 2 refund means 10,000 requests a month, about 455 a working day over 22 days. Nobody reviews that many with care. If 20% of refunds are above $50, approvals drop to 2,000 a month, about 91 a day.
Now audit them. Say approvers rejected or edited 14 of 2,000 requests, an override rate of 0.7%, with a median decision time of 3 seconds. Together those match the framework’s description of rubber-stamping. A decision rule we suggest: when the override rate is below 2% and the median decision time below 10 seconds, re-review a blind sample of 50 approved requests. If reviewers would change several, shorten the requests, add the risk and confidence the framework asks for, or move the cap.
Tier 1 has no approver at all, so after-the-fact scoring of every conversation is the only check on 70% of the volume. The AI agent evaluation guide covers how to score those outcomes.
How does the framework compare with the EU AI Act for customer service?
The EU AI Act is binding law; Singapore’s framework is guidance. For a support AI agent they overlap most on disclosure: Article 50(1) of the AI Act has required since August 2, 2026 that people are told they are interacting with an AI, and the framework asks for the same at the point of interaction.
| Topic | Singapore MGF for Agentic AI | EU AI Act |
|---|---|---|
| Legal status | Guidance, a living document | Regulation (EU) 2024/1689, binding in the EU |
| Telling customers it is an AI | Declare it in the interface at the point of interaction | A provider duty, from the first interaction, unless obvious (Commission FAQ) |
| Risk approach | Your own assessment per use case | Fixed tiers; a customer-facing support agent is usually in the transparency tier |
| Human oversight, testing, monitoring | Spelled out for any agent that takes actions | Detailed duties mainly for high-risk systems; Annex III rules apply from December 2, 2027 (Commission AI Act page) |
In practice, the AI Act sets the EU minimum, mostly disclosure for a customer-facing agent, while the Singapore framework tells you how to run an agent that takes actions. In both markets, build one control set that meets the AI Act and use the framework’s structure for the rest. Our article on the EU AI Act in customer service covers the dates, tiers and fines.
When this framework is not the right fit
If your bot only answers from your own help center and takes no actions, most of the framework is light work. Its risk factors rate read-only access and an internally maintained knowledge base as lower risk, so you mainly need the disclosure, a human contact and quality checks on the answers.
It also describes no certification, so “compliant with the MGF” is not a claim anyone can verify for you; the evidence in the table above is what you can show.
Where does QA fit in the framework?
QA covers the parts that need proof from real conversations: policy compliance after launch, regular audits, the disclosure, and the feedback loop the framework asks for, “to feed monitoring insights back into training datasets and evaluation frameworks.” Logs show what the agent did; a quality score shows whether it was right.
Kaizo is one way to run that part. It scores 100% of your AI agent conversations against your own scorecard, the same one your team is scored on, and links every score to the evidence in the conversation; see QA for AI agents. Book a demo to see it on your own conversations.
How to start this week
You can cover the first dimension and part of the fourth in five working days without new tools: what the agent can touch, who owns it, what customers see, and a first audit of your approvers.
- Day 1: List every intent the agent handles and every tool it can use; mark each tool read or write.
- Day 2: Tier each intent on impact and reversibility; flag any write action involving money or accounts.
- Day 3: Name an owner for the agent and each tier; write down who can switch it off, and test it.
- Day 4: Open a conversation in every channel and language; screenshot the AI disclosure and the route to a person.
- Day 5: Compute last month’s override rate and median response time per approver.
Frequently asked questions
Is there a PDF of the framework?
Yes. IMDA publishes it as a PDF on imda.gov.sg, titled “Model AI Governance Framework for Agentic AI,” version 1.5. It runs to 53 pages, including case studies, further resources in Annex A and a call for feedback in Annex B.
Does the framework apply to companies outside Singapore?
The framework does not define a territorial scope. It is written for any organization looking to deploy agentic AI, built in-house or bought. Companies elsewhere can use its structure, but their own laws decide what is required.
Does the framework require a human to approve every AI agent reply?
No. It asks for approval at significant checkpoints, such as high-stakes, irreversible or unusual actions, and notes that continuous oversight of every workflow becomes impractical at scale. Approvals are paired with automated monitoring and alert thresholds.
What is new in version 1.5?
Version 1.5 reflects feedback from more than 60 companies since version 1.0. It adds risk factors such as system complexity and third-party solutions, multi-agent risks, practices against automation bias such as tracking override rates, change management guidance, and case studies.
Can a company be certified against the framework?
The document describes no certification or audit scheme. It is a set of recommended practices, so the strongest thing a company can show is its own evidence: risk tiers, approval logs, test results, monitoring records and disclosure screenshots.
