Singapore IMDA Model AI Governance Framework for Agentic AI (version 1.5, 20 May 2026)
Voluntary guidance for organisations deploying AI agents in four dimensions: assess and bound risks upfront, make humans meaningfully accountable, implement technical controls, and enable end-user responsibility. It recommends least-privilege tool and data access with deterministic limits, issued agent identities, sandboxed execution, a way to take agents offline, human approval at defined checkpoints such as irreversible actions, monitoring with alert thresholds, logging, and testing before deployment.
Scope. Voluntary official guidance; listed as a widely used governance framework that US buyers and auditors reference, not as a binding rule.
Draft mapping. Drafted by the Register's agents from the rule's text and not yet confirmed by a person. It is the Register's reading, not legal advice: whether and how the rule applies to you is a question for counsel.
Controls this rule maps to
Required by the text The rule's text requires a measure that is this control, or plainly includes it. Implied A binding rule whose purpose needs this control, but whose text does not name it. The Register's reading. Recommended A voluntary standard or guidance recommends it; nothing binds you to it. Proposed Appears in a proposed rule or proposed provision that is not yet in force.
| Control | Strength | Where in the rule, and why | Confidence | Missing or failed in |
|---|---|---|---|---|
| Least-privilege credential scoped to task C-E1 | Recommended | Section 2.1.2 (p. 19): 'Define least-privilege policies that give agents only the minimum tools and data access needed'. [Checker: Section 2.1.2, p. 19 (verified).] | high | 5 cases |
| Machine-enforceable scope C-M2 | Recommended | Section 2.1.2 (p. 19): 'prefer deterministic rather than non-deterministic limits, and bound by design'. [Checker: Section 2.1.2, p. 19 (verified).] | medium | 9 cases |
| Destructive-action gate C-E3 | Recommended | Section 2.2.2 (p. 29): 'define significant checkpoints or action boundaries that require human approval', listing 'Irreversible actions e.g. permanently deleting data, sending communications, making payments'. [Checker: Section 2.2.2, p. 29 (verified).] | high | 12 cases |
| Containment and isolation C-E5 | Recommended | Section 2.1.2 (p. 19): 'running agents in self-contained environments with limited network and data access'; section 2.3.1 (p. 34): 'Sandbox any code execution'. [Checker: Section 2.1.2, p. 19 and section 2.3.1, p. 34 (verified).] | high | 7 cases |
| Kill switch faster than the actor C-X2 | Recommended | Section 2.1.2 (p. 19): 'Design mechanisms and procedures to take agents offline and limit their potential scope of impact'. Speed of the stop is not addressed. [Checker: Section 2.1.2, p. 19 (verified).] | medium | 2 cases |
| Actor identity verification C-A1 | Recommended | Section 2.1.2 (p. 23): 'all agent identities (and their attendant permissions) should be issued' through a managed process to prevent agent sprawl. [Checker: Section 2.1.2, p. 23 (verified).] | medium | 8 cases |
| Warnings designed as alerts C-I4 | Recommended | Section 2.2.2 (p. 29): 'Complement this with automated monitoring mechanisms and predefined alert thresholds'; (p. 30) 'Implementing alerts for certain logged events'. [Checker: p. 29 (the phrase 'Complement this with automated monitoring mechanisms and predefined alert thresholds' is a figure caption) and p. 30 (verified).] | medium | 4 cases |
| Independent audit log C-V1 | Recommended | IMDA case study within the framework (p. 14): 'After deployment, ensure all agent actions are logged and attributable'; section 1.1.1 (p. 7) describes logging of agent actions, decisions and interactions. The framework text read does not say the log must be beyond the agent's reach. [Checker: p. 14 IMDA case study (verified).] | medium | 1 case |
| Mandate disclosed to supervisor C-M1 | Recommended | Executive Summary (p. 3): 'as a baseline, users should be informed of the agent's range of actions'. [Checker: Executive Summary, p. 4 of the PDF (the draft says p. 3; the quotation is on PDF page 4).] | medium | 1 case |
| Retrieved content as data C-I1 | Recommended | Section 2.3.1 (p. 34): 'input validation to catch harmful responses before they are acted upon'; section 1.2.1 (p. 10) names prompt and code injection through tools as a risk. Does not say retrieved content is to be treated as data only. [Checker: Section 2.3.1, p. 34 (verified).] | low | 10 cases |