On May 20, 2026, Singapore updated its guidance for organizations deploying AI agents. One published example concerned an IT-support agent that could handle some requests automatically, propose other changes for human approval, and take no action on a third category.
The distinction depended on the consequences of the action: how serious a mistake would be, whether it could be reversed, and whether a person could oversee it effectively.
The same agent received different permissions for different work. Its ability to perform a task did not determine whether it was allowed to perform it.
That is the question at the center of Singapore’s approach: when an organization gives software the ability to act, how does it decide where that ability must stop?
Singapore Began With What Agents Can Do
The Infocomm Media Development Authority launched its Model AI Governance Framework for Agentic AI on January 22, 2026. It addresses organizations building agents themselves and those using third-party products.
The framework connects four activities: bounding risks and powers, making people meaningfully accountable, applying technical controls and lifecycle processes, and helping users understand their responsibilities.
Its examples include limits on tools and data, human-approval checkpoints, baseline testing, and access restricted to approved services. These recommendations address software that can change its environment, including making payments or updating records.
An answer that contains an error can mislead its reader. An agent with permission to act can also change the record, send the instruction, or complete the transaction before anyone reads an explanation. The organization must decide which of those operations it will permit.
The May Update Made the Distinction Concrete
The May 20 update added case studies and further practices on multi-agent systems, third-party agents, and automation bias, topics the January framework already addressed.
In the IT-support example, contributed by Dayos, low-severity, fully reversible actions such as password resets could run automatically subject to biweekly audits. Actions of moderate severity and partial reversibility required human approval. The agent was barred from high-severity actions with limited reversibility, including permissions modifications.
That example illustrates a useful method. It does not establish that the same classification would be appropriate for every organization. A seemingly routine action can have different consequences depending on the account, connected systems, and information involved.
Consider a hypothetical payment agent. Drafting an instruction, changing a payee, and releasing funds are separate operations. An organization could permit the first, require independent approval for the second, and prohibit the third.
Calling the product a payment assistant would reveal little about those differences. Reviewing its actual permissions would reveal much more.
A Rule Needs a Way to Hold
Singapore’s combination of limits and testing supports two connected questions: what is the agent permitted to do, and what evidence shows that the restriction works?
Those questions need separate answers. A written instruction can describe a prohibition. An access control can deny the operation. Testing can establish whether the intended denial occurs under the conditions examined.
In the payment example, an instruction telling the agent to obtain approval would need to be evaluated differently from a payment service that rejects every request lacking a valid approval. An organization should establish which mechanism it actually has.
It should also examine alternate routes. If one tool prevents an unauthorized change but another connected service permits it, the first control has not established an effective boundary across the deployment.
This is an implementation lesson drawn from the framework’s approach. Singapore has not prescribed one universal technical architecture, and adopting its recommendations does not prove that a particular system is safe.
Approval Must Occur While Intervention Still Matters
The January framework places human approval at significant checkpoints and identifies the danger of automation bias: people can become too willing to trust a system that has previously performed reliably.
For an organization implementing that recommendation, the next questions are practical. What will the reviewer see? Can the reviewer identify the proposed change and its consequences? Can the operation be stopped before it takes effect?
Returning to the hypothetical payment agent, a notice that funds have already been released is different from a request to approve their release. Both involve a person. Only one supplies an opportunity to prevent the transaction.
Approval also needs an accountable reviewer. An organization should establish who can authorize the operation, what information supports that judgment, and what happens when the reviewer declines or does not respond. Counting approvals alone would not establish that the review was effective.
Guidance Leaves Legal Questions Open
The framework supplies recommendations for responsible deployment. It says nothing about liability: it does not create a statutory regime or determine which party must compensate someone harmed by an agent.
Those limits matter when assessing its significance. A supplier’s testing, a customer’s configuration, and a user’s instructions can each affect what an agent does. Allocating legal responsibility requires examining the applicable law and the conduct of the relevant parties.
Operational records can help establish that conduct. Permissions, approval records, tool activity, and changes to the deployment can show what the organization allowed and what happened. Their legal significance will depend on the claim and the governing law.
IMDA describes the framework as a living document that will need continuous updating. That makes it a useful model for future oversight without making it a substitute for legal analysis. It gives organizations concrete decisions to document and examine before a dispute occurs.
