IMDA's Agentic AI Governance Framework: Designing Agent Permissions and Human Approval Points

Most enterprise AI projects in 2024 and 2025 were about generating things: drafts, summaries, answers. The projects now reaching procurement committees are different. An AI agent does not just write the reply to a supplier — it updates the purchase order, emails the supplier and logs the change in the ERP. That shift from generating to acting changes the governance question from “is the output accurate?” to “what is this system allowed to do, and who answers for it when it does something wrong?”

Singapore’s Infocomm Media Development Authority (IMDA) addressed that question directly with its Model AI Governance Framework for Agentic AI. This guide explains what the framework asks of organisations and turns its two most practical themes — agent permissions and human approval points — into design decisions you can apply to a real workflow. For the earlier generative AI framework and the AI Verify testing tools, see our companion guide to IMDA’s GenAI framework and AI Verify.

Why Agents Need Their Own Framework

The AI Verify Foundation describes the agentic framework as guidance to organisations on how to deploy AI agents responsibly, “while emphasising that humans are ultimately accountable.” It gives organisations a structured overview of the risks of agentic AI and emerging best practices for managing them, and the Foundation notes it was updated in May 2026 to add real-world case studies on how organisations can operationalise its recommendations (AI Verify Foundation: Resource Library). The framework document itself is published by IMDA (IMDA: Model AI Governance Framework for Agentic AI, PDF).

According to Baker McKenzie’s summary, IMDA launched the framework on 22 January 2026 at the World Economic Forum, and it is non-binding guidance rather than regulation (Baker McKenzie, January 2026). Non-binding does not mean irrelevant: in Singapore, frameworks like this quickly become the reference point that buyers, auditors and sector regulators use when they ask how an AI deployment is governed.

The risks that make agents different are familiar to anyone who has run automation in production, only amplified:

• Actions have consequences outside the model. A wrong summary can be ignored; a wrong refund cannot easily be recalled.
• Agents chain steps. A small error early in a plan can be carried through several tool calls before anyone sees it.
• Agents inherit access. Whatever credentials the agent holds, it can in principle use — including in ways its designers did not intend.
• Agents interact with other agents. Baker McKenzie notes the May 2026 update added risks arising from multi-agent systems and third-party agent use as risk factors (Baker McKenzie, June 2026).

The Four Dimensions

The framework is organised around four dimensions (as summarised by Baker McKenzie):

1. Assessing and bounding the risks upfront – assess each use case, considering factors such as the agent’s level of autonomy, the sensitivity of the data it touches and the scope of its actions, then limit what the agent can do by controlling its tool access, permissions, operational environment and scope of actions.
2. Making humans meaningfully accountable – allocate clear responsibilities across the parties involved, and establish human oversight mechanisms that can override, intercept or review agent actions, particularly where actions have material real-world impact.
3. Implementing technical controls and processes – controls at design, pre-deployment and post-deployment stages, including least-privilege access to tools and data, testing of task execution and policy compliance, progressive rollouts and real-time monitoring.
4. Enabling end-user responsibility – transparency to users about what the agent can do and who to escalate to, and training so people retain the skills to oversee it.

The first two dimensions are where most enterprise deployments succeed or fail, so the rest of this guide focuses on them.

Designing Agent Permissions

“Bound the risks upfront” is, in practice, a permissions design exercise. Before an agent touches production data, write down four things for each workflow.

1. The action inventory

List every action the agent can take, not just the tools it has. “Access to the CRM” is too coarse. “Read contact records”, “update deal stage”, “delete contact” and “export list” are four different risk levels. Remove every action the workflow does not need; least privilege is explicitly part of the framework’s technical controls.

2. Reversibility and blast radius

Classify each action by whether it can be undone and how far its effects spread. Drafting an email is reversible and contained. Sending it to 5 customers is irreversible but limited. Sending it to your whole customer base, changing prices or moving money are irreversible and wide. This classification drives where you need approvals and how much monitoring you need.

3. Data boundaries

Specify which data the agent may read, which it may write, and which it must never see. For Singapore organisations, personal data handled by an agent still falls under the PDPA; our guide to PDPA compliance for AI covers the obligations that carry over.

4. Agent identity

Give each agent its own service identity and credentials rather than letting it act under a human’s account. That makes its actions attributable in logs, lets you revoke its access without locking out a person, and prevents it from silently inheriting everything that person can do.

Placing Human Approval Points

The framework’s accountability dimension calls for oversight that can override, intercept or review agent actions, especially where they have material real-world impact. Baker McKenzie’s summary of the May 2026 update also lists human approvals alongside access controls, guardrails, logging and monitoring as safety and reliability components of an agent. The design challenge is putting approvals where they matter without turning the agent into a slower form of manual work.

A practical way to decide is to map the action classification above onto three oversight modes:

• Autonomous with logging – reversible, contained actions (drafting, classifying, internal notes). The agent acts; every action is logged and sampled for review.
• Approve before execution – irreversible or external actions with limited reach (sending a customer email, updating a contract record, issuing a small credit). The agent prepares the action; a named role approves it.
• Human-only – irreversible, wide-reaching or high-value actions (bulk communications, pricing changes, payments above a threshold, deleting records). The agent may recommend but cannot execute.

Three details make approval points meaningful rather than ceremonial:

1. Show the approver what will actually happen. The exact email, the exact field changes, the exact amount — not the agent’s description of its intention.
2. Name the role, not just “a human”. Accountability requires a specific role with authority over that decision, consistent with your existing delegation of authority.
3. Watch for rubber-stamping. The update’s guidance on automation bias recommends monitoring human override rates and response times. If approvers accept 100% of proposals within seconds, the approval point is not providing oversight.

These modes should be enforced by the platform, not left to the agent’s instructions. A prompt that says “ask before sending” is a request; a workflow engine that will not execute the send without an approval record is a control. This is the thinking behind our governed AI workflows approach.

Controls Across the Lifecycle

The technical controls dimension spans the full lifecycle. Mapped to a typical enterprise rollout:

• Design: tool guardrails, least-privilege access and a clear definition of the agent’s task and boundaries.
• Pre-deployment testing: test task execution, policy compliance and tool-use accuracy across varied data — including cases where the agent should refuse or escalate.
• Deployment: progressive rollout (a small user group or low-risk subset first) and real-time monitoring of actions, errors and escalations.
• Change management: Baker McKenzie notes the update emphasises robust change management so that small modifications do not cascade into larger impacts. A new tool, a model upgrade or a changed prompt should trigger re-testing proportionate to the risk.

Keep an audit trail that links each action to the agent identity, the input that triggered it, the approval (if any) and the outcome. Without it, neither accountability nor incident review is possible.

End Users and Automation Bias

The fourth dimension is about the people who work alongside agents. Users should know what the agent can and cannot do, when they are dealing with it, and who to contact when something looks wrong. The May 2026 update also addresses a quieter risk: when agents take over entry-level tasks, organisations can suffer skill degradation and loss of basic operational knowledge. If an agent handles all first-line invoice matching, make sure someone can still do it by hand when the agent is switched off.

A Deployment Checklist

• Use-case assessment recorded: autonomy level, data sensitivity, action scope.
• Action inventory with unnecessary actions removed.
• Each action classified by reversibility and blast radius, mapped to an oversight mode.
• Dedicated agent identity with least-privilege credentials.
• Approval points enforced by the workflow engine, with named approver roles.
• Override rates and approval response times monitored.
• Pre-deployment tests covering refusals and escalations, not just the happy path.
• Progressive rollout plan and a tested way to pause or switch off the agent.
• Change-management trigger list for model, prompt and tool changes.
• User guidance and escalation contacts published; manual fallback skills maintained.

Many of these items are also what enterprise buyers now ask vendors to evidence during AI procurement; see AI procurement for how we support that process.

Frequently Asked Questions

Is IMDA’s agentic AI framework mandatory?

No. It is voluntary guidance. It is nevertheless likely to shape what customers, auditors and sector regulators in Singapore expect to see when an organisation deploys AI agents.

How is it different from the GenAI framework?

The GenAI framework addresses generative AI broadly. The agentic framework focuses on systems that plan and take actions, so it puts more weight on bounding what agents can do, human accountability for their actions and controls across the deployment lifecycle.

Which agent actions need human approval?

The framework calls for oversight that can override, intercept or review actions, particularly where they have material real-world impact. A practical rule is to require approval for irreversible or external actions and keep irreversible, wide-reaching actions human-only.

What changed in the May 2026 update?

According to the AI Verify Foundation, the update added real-world case studies. Legal commentary also highlights new material on multi-agent risks, provider roles, automation bias and change management.