Singapore’s Agentic AI Framework: Design the Approval Before the Action

An AI assistant that writes a recommendation leaves a person to act. An agent that changes a record, submits a request or initiates a payment crosses a different boundary. For a business or public institution, the important design question is not simply whether the model gives good answers. It is which actions the organisation has authorised, and how that authority is kept within bounds.

What the official guidance says

Singapore’s Ministry of Digital Development and Information announced the Model AI Governance Framework for Agentic AI on 22 January 2026. The launch describes guidance for organisations developing their own agents or using third-party solutions. Its four dimensions cover limits on autonomy and access, meaningful human approval points, technical controls across the lifecycle, and transparency and user education. This is a governance framework, not a certification that a particular product is safe.

In its parliamentary response of 6 May 2026, the Ministry made the approval boundary concrete: high-stakes or irreversible actions should not proceed without human review. It also emphasised telling users that they are interacting with an agent and explaining its capabilities and access to data. A later response on 5 August reinforced designated oversight roles and controls proportionate to the system’s risks and autonomy.

These sources explain the government’s guidance and accountability expectations. They do not establish a general statutory licence for agents to act, nor demonstrate that a particular deployment complies with all applicable law. This article is an implementation explainer, not an announcement of new rules taking effect today. Sector-specific duties and the authority for an underlying transaction still require their own assessment.

Turn oversight into testable permissions

For implementation, begin with an action register rather than a list of model features. For each proposed action, record the affected system, permitted data, maximum scope, responsible owner and approval trigger. Reading a customer record, proposing a correction and writing the correction should be separate permissions. A successful test of the first does not justify enabling the third.

Approval must also attach to the action actually carried out. Suppose an employee authorises a draft purchase request for one supplier and amount. If the agent later changes either, the earlier approval should not silently travel with the altered request. A useful acceptance test checks whether the system pauses when material terms change, whether the reviewer sees those terms, and whether the resulting record identifies what was approved.

Test failure as carefully as completion. Can an operator stop an action before it reaches another system? If a connection fails after submission, can the agent check whether the request succeeded before retrying? Who corrects a record when reversal is impossible? These are proposed operational tests, not claims that the Singapore framework prescribes this exact checklist. Their purpose is to make an institution’s chosen boundaries observable.

Start with one workflow

The immediate deliverable is a one-page action-and-approval map for one real workflow, accompanied by evidence from normal, changed-instruction and interrupted runs. Procurement teams can ask vendors to demonstrate that map rather than merely promise human oversight. The JUSNREM legal intelligence programme offers a context for examining how authority, evidence and correction fit together; an initial discussion should use a non-confidential description of the workflow.