Introduction: Singapore's agentic-AI guidance meets production reality
In May 2026, Singapore's Infocomm Media Development Authority (IMDA) published version 1.5 of its Model AI Governance Framework for Agentic AI. The update adds depth on multi-agent systems, third-party agent risk, automation bias and operational case studies — without changing the framework's four core dimensions: assess and bound risks; make humans meaningfully accountable; implement technical controls; and enable end-user responsibility.
For APAC enterprises deploying agents in customer service, finance, security operations and procurement, the question is not whether the framework is binding law. It is how to translate voluntary guidance into controls that survive audit, incident review and board scrutiny. Singapore's posture — voluntary framework, legal accountability for outcomes — mirrors what most enterprises already face: regulators and customers expect evidence, not slide decks.
This article translates IMDA's agentic-AI guidance into a production control model centred on decision rights, not model labels.
Last verified: 3 August 2026
Direct answer: Singapore's agentic-AI framework is voluntary guidance, not legislation, but the deploying organisation stays accountable for what its agents do. Bound autonomy by delegated capability, not by model name: define what each agent may observe, recommend, prepare or execute on a decision-rights matrix, require evidence and human approval as impact rises, and enforce monitoring, rollback and named ownership at every tier. Multi-agent and third-party agents need delegation controls enforced at runtime — a prompt instructing an agent to "stay in scope" is not a control.
What Singapore updated in 2026
IMDA first launched the Model AI Governance Framework for Agentic AI in January 2026. Version 1.5, published on 20 May 2026 and updated on 5 June 2026, incorporates feedback from industry and government deployments.
Notable additions in v1.5 include:
- Multi-agent systems module — inter-agent delegation, authentication between agents, and cascading failure modes when chains cross organisational boundaries.
- Third-party agent risk — procurement and operational controls when agents are supplied by vendors rather than built in-house.
- Automation bias — governance for over-reliance on agent recommendations, particularly where humans rubber-stamp outputs.
- Case studies — practical illustrations from Singapore enterprises and government agencies applying the four framework dimensions.
The framework remains voluntary best-practice guidance. It does not create new statutory obligations. However, IMDA is explicit that organisations deploying agentic AI remain accountable for outcomes — a posture consistent with existing product liability, data protection and sector-specific duties across APAC.
Why agentic systems require a different governance model
Traditional AI governance often treats the model as the unit of control: which version is deployed, who validated it, what data it was trained on. Agentic systems break that model because the risk surface is behavioural and dynamic.
An agent can plan multi-step workflows, invoke tools and other agents with compounding scope, and produce irreversible outcomes from probabilistic reasoning. Governance must answer: what decision class applies, what evidence is required, who approves, and how rollback works.
For a broader enterprise control-plane architecture, see Agentic AI governance and identity and AI agent security controls for production.
The AiRAT Agent Decision-Rights Matrix
The AiRAT Agent Decision-Rights Matrix is an implementation framework that maps agent capabilities to required controls. Rows represent decision classes (the ladder from observe to delegate). Columns represent control dimensions every production agent must satisfy at its assigned tier.
Decision-rights ladder
- Observe — read data, logs, tickets, no mutation. Fully automated.
- Summarise — produce internal summaries and briefings. Fully automated, with logging.
- Recommend — suggest actions, no execution. Automated; a human consumes the output.
- Prepare action — draft emails, tickets, change requests, API payloads. Automated draft; a human submits it.
- Execute reversible action — mutate state that can be undone (tag, quarantine a sandbox, revert a config). Policy-bounded automation.
- Execute customer-visible action — send customer communications, update portals. Human approval required.
- Execute financial / security / destructive action — payments, privilege changes, data deletion, endpoint isolation. Explicit approval plus a rollback plan.
- Delegate to another agent — hand off sub-tasks to a peer or sub-agent. Scoped delegation with trust verification.
Control dimensions (matrix columns)
| Control dimension | What it requires |
|---|---|
| Allowed autonomy | Whether the agent may act without human initiation at this tier |
| Required evidence | Inputs, reasoning trace, tool calls, policy version, outcome hash |
| Human approval | None, async review, or synchronous gate before execution |
| Monitoring | Real-time policy checks, anomaly detection, cost and rate limits |
| Rollback | Documented undo path, owner, and tested procedure |
| Accountable owner | Named business and technical owner with escalation path |
Matrix excerpt (illustrative assignments)
Every tier is monitored continuously — rate limits and drift checks at the automated end, real-time policy enforcement and fraud/SOX controls at the high-impact end — but the columns below are the ones that actually change enterprise to enterprise.
| Decision class | Required evidence | Human approval | Rollback | Accountable owner |
|---|---|---|---|---|
| Observe | Query log, data scope | None | N/A | Data owner |
| Recommend | Full reasoning chain | Optional review | N/A | Product owner |
| Prepare action | Draft + source context | Before send/submit | Discard draft | Workflow owner |
| Execute reversible | Pre/post state snapshot | For high-risk scopes | Automated or scripted | Ops lead |
| Customer-visible | Draft + approval record | Required | Recall procedure | Comms lead |
| Financial / destructive | Dual control record | Required + segregation | Compensating transaction | CFO delegate |
| Delegate | Delegation token, scope hash | Parent agent policy | Revoke delegation | Platform owner |
Enterprises should maintain one matrix row per deployed agent capability, not per agent brand name. A single "customer service agent" may span summarise through prepare action across different workflows.
Five hypothetical examples (labelled)
The following are illustrative scenarios, not client deployments.
1. Read-only compliance assistant (Observe / Summarise)
Autonomy: fully automated for internal policy document retrieval and obligation summaries. Controls: read-only IAM, query logging, no write tools. Owner: compliance officer.
2. Customer-support refund recommender (Recommend)
Autonomy: suggests refund eligibility and amount; cannot execute. Controls: reasoning trace, link to policy version, analyst accepts or overrides. Owner: customer operations lead.
3. Finance reconciliation agent (Prepare action)
Autonomy: drafts journal entries and exception tickets. Controls: ERP write access disabled; human posts entries. Owner: finance controller.
4. Endpoint-isolation security agent (Execute reversible / destructive)
Autonomy: may isolate non-production hosts automatically; production isolation requires approval. Controls: pre-action snapshot, integration with ADR, rollback runbook. Owner: CISO delegate.
5. Procurement agent with delegated subagents (Delegate)
Autonomy: parent agent scopes vendor comparison; sub-agent may summarise public pricing only — not sign contracts. Controls: delegation depth limit, per-sub-agent permission envelope, third-party agent risk assessment per IMDA v1.5. Owner: chief procurement officer.
Human accountability and ownership
IMDA's second dimension requires named business, technical and risk owners per capability — with evidence tracing who approved deployment, which policy version governed each action, and who was notified on failure. This aligns with AiRAT methodology for production systems where failure has a measurable cost.
Identity, access, delegation and third-party agents
Version 1.5's multi-agent and third-party modules reinforce what production teams already discover: prompt instructions are not access controls.
Minimum technical controls: scoped agent identities with TTL permissions; runtime tool gates enforcing decision-class limits; delegation tokens with scope, expiry and parent accountability; third-party agent due diligence on data flows, subprocessors and kill-switch rights.
For permission envelope design, see AI agent security controls for production.
Testing, monitoring and incident management
IMDA v1.5 stresses structural controls over prompt-layer safeguards: pre-deployment testing per decision class, continuous policy and bias monitoring, incident playbooks for agent disable and delegation revocation, and post-incident reasoning-chain replay.
APAC Governance Crosswalk (conceptual alignment)
This crosswalk maps themes, not legal equivalence. No row implies certification or statutory alignment.
| Theme | IMDA Agentic AI v1.5 | NIST AI RMF | ISO/IEC 42001 | AiRAT implementation control |
|---|---|---|---|---|
| Risk bounding | Assess and bound upfront | Map / Measure | AI risk assessment | Decision-Rights Matrix tier assignment |
| Human accountability | Meaningful human accountability | Govern | Roles and responsibilities | Named owners + approval gates |
| Technical controls | Implement controls and processes | Manage | Operational controls | Permission envelope + policy engine |
| End-user responsibility | Enable end-user responsibility | Govern | Communication and transparency | Customer-visible action tier |
| Multi-agent risk | Multi-agent module | Govern (emerging practice) | Supply chain / lifecycle | Delegation tokens + chain limits |
| Third-party agents | Third-party agent section | Govern (third-party) | Supplier controls | Vendor due diligence + kill switch |
The OWASP Agentic Applications project covers the same six themes with its own risk-tier language (agent risk tiers, human-in-the-loop patterns, tool permission boundaries, user disclosure, agent-to-agent trust, third-party tool risk) — omitted from the table above only to keep it scannable, not because it's less relevant.
Metrics to track
| Metric | Purpose |
|---|---|
| % capabilities with assigned decision class | Governance coverage |
| Approval latency by tier | Operational friction vs risk |
| Policy violation rate | Control effectiveness |
| Rollback success rate | Reversible-action readiness |
| Delegation chain depth (p95) | Multi-agent risk indicator |
| Third-party agent review currency | Vendor governance hygiene |
| Override rate on recommendations | Automation bias signal |
Do not treat these as industry benchmarks — measure against your own baselines and risk appetite.
45-day implementation roadmap
| Phase | Days | Activities |
|---|---|---|
| Discover | 1–10 | Inventory agents and capabilities; draft decision-class assignments |
| Design | 11–20 | Build Decision-Rights Matrix; define owners and approval paths |
| Implement | 21–35 | Encode policy engine rules; enable evidence logging; test kill switch |
| Validate | 36–45 | Run tabletop per decision class; review third-party agents; board briefing |
Failure modes
- Global trust level — symptom: high-risk and read-only agents share the same permissions. Mitigation: one matrix row per capability, not per agent brand.
- Rubber-stamp approval — symptom: 99% auto-approval on a "human" gate that exists on paper only. Mitigation: sample review plus approval-SLA analytics that would actually surface this.
- Shadow delegation — symptom: sub-agents get spawned outside the registry. Mitigation: delegation tokens with registry enforcement, not an honour system.
- Prompt-only governance — symptom: the policies exist in documentation, not in anything that runs. Mitigation: a runtime policy engine, not a PDF.
- Missing rollback — symptom: reversible actions whose undo path has never actually been tested. Mitigation: rollback drills per tier, on a schedule.
- Third-party blind spot — symptom: vendor-supplied agents aren't in the inventory at all. Mitigation: joint procurement and security review before any third-party agent goes live.
Key takeaways
- Singapore's IMDA agentic-AI framework (v1.5) is voluntary guidance; legal accountability for agent outcomes remains with the deploying organisation.
- Govern by delegated capability, not model name: assign each capability to a decision class on the observe-to-delegate ladder.
- The AiRAT Agent Decision-Rights Matrix maps decision classes to evidence, approval, monitoring, rollback and ownership requirements.
- Multi-agent and third-party agent risks need structural controls — scoped identities, delegation limits and vendor due diligence — not prompt-layer instructions alone.
- Use the APAC Governance Crosswalk for thematic alignment with NIST AI RMF, ISO/IEC 42001 and OWASP Agentic Applications; it does not establish legal equivalence.
- A 45-day roadmap — discover, design, implement, validate — is sufficient to operationalise decision rights for most enterprise agent portfolios.
Frequently asked questions
What is Singapore's agentic AI governance framework?
It is IMDA's Model AI Governance Framework for Agentic AI — currently version 1.5 (May 2026). It provides voluntary best-practice guidance on assessing risk, human accountability, technical controls and end-user responsibility for systems that plan, reason and act with varying degrees of autonomy.
Does the framework apply outside Singapore?
It is published by Singapore's IMDA and reflects Singapore's policy posture. It is not binding law in other jurisdictions. However, APAC enterprises and multinationals often use it as a reference architecture because it addresses multi-agent and third-party agent risks in operational detail.
How should enterprises bound AI-agent autonomy?
Assign each agent capability to a decision class (observe through delegate). Encode approval thresholds, evidence requirements and rollback procedures in a runtime policy engine. Do not rely on a single "trust score" for all agent behaviours.
Who is accountable for an AI-agent decision?
The deploying organisation remains accountable under applicable law and contracts. Operationally, name a business owner, technical owner and risk owner per capability, with evidence linking actions to policy versions and approvers.
What controls are needed for multi-agent systems?
Scoped delegation tokens, maximum chain depth, agent-to-agent authentication, per-hop evidence logging, third-party agent risk assessment, and kill switches that revoke delegation across the chain.
How does IMDA compare with NIST AI RMF or ISO 42001?
All address governance, risk and operational controls, but IMDA v1.5 is specifically tailored to agentic AI — including multi-agent delegation and automation bias. NIST AI RMF and ISO/IEC 42001 provide broader AI management system structures. They are complementary; none substitutes for the others.
What is a decision-rights matrix for AI agents?
A table mapping each agent capability to its allowed decision class and required controls: autonomy level, evidence, human approval, monitoring, rollback and accountable owner. The AiRAT Agent Decision-Rights Matrix is one implementation model.
Sources
- IMDA, Model AI Governance Framework for Agentic AI, v1.5 (20 May 2026, updated 5 June 2026): https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf
- IMDA, Model AI Governance Framework (2nd Edition, 2020): https://www.imda.gov.sg/how-we-can-help/ai-assure/ai-governance
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0): https://www.nist.gov/itl/ai-risk-management-framework
- ISO/IEC 42001:2023 — AI management systems: https://www.iso.org/standard/81230.html
- OWASP, Agentic Applications Top 10: https://owasp.org/www-project-agentic-applications-top-10/
This article provides technical guidance only. It is not legal advice. Consult qualified counsel on regulatory obligations in your jurisdiction.
Related: Agentic AI governance and identity · AI agent security controls for production · ADR product · Resources · Methodology · Services
