Singapore Agentic AI Governance: A Four-Part Deployment Record

Singapore launched its Model AI Governance Framework for Agentic AI on 22 January 2026. The framework gives deployers four connected jobs: bound an agent's powers, keep humans accountable at significant checkpoints, operate controls across the lifecycle, and prepare users to supervise the agent. Each job needs a deployment record that names the decision and owner. The same record needs the test and evidence.

I would reject an agent register that ends with a risk rating and a green status cell. The useful record shows exactly which data and tools the agent can reach. It lists the available services and actions. It also shows where a human can stop the agent before an irreversible action occurs.

TL;DR

• IMDA launched the framework on 22 January 2026 and now publishes a May 2026 revision covering in-house deployments and third-party agent deployments.
• Bound each agent's action-space and autonomy before approval. Define its data and tool access, then document identity and permissions. Record its effect on connected systems.
• Define human checkpoints for significant actions, then test approval quality and failure handling. Retain the evidence for each decision.
• Run technical controls through design and pre-deployment testing. Continue them through phased rollout and continuous monitoring, followed by change review and user training.

The current framework has four dimensions

The Infocomm Media Development Authority announced the new agentic AI framework on 22 January 2026. IMDA targets organizations developing agents in-house and those using third-party agentic products. Its four dimensions cover risk boundaries, human accountability, lifecycle controls, and end-user responsibility.

The current Model AI Governance Framework for Agentic AI PDF was published on 20 May 2026 and updated on 5 June. IMDA describes it as a living document. The revision adds real deployment cases and expands the material on multi-agent risk and identity. It also expands the guidance on human oversight and technical controls, along with testing and monitoring. Change management receives additional coverage.

Treat the document as governance guidance that must be translated into your own policy and architecture, with supporting evidence. Keep applicable Singapore law and sector rules in separate rows. Do the same for contractual duties. The Singapore AI Verify guide owns the adjacent testing-framework question; this article stays with the agentic deployment crosswalk.

Bound the agent's powers before approval

IMDA separates an agent's action-space from its autonomy. Action-space covers the systems, tools, data, and operations available to the agent. Autonomy describes how much freedom the agent has to choose its plan and proceed without human involvement. The framework asks deployers to assess both before selecting a use case. The assessment also covers reversibility and task complexity, plus third-party dependence and system complexity.

Create one boundary record for every approved agent or materially different deployment. Give it an agent ID and named owner. Record its business purpose and triggering identities. Add model routes and data classes. List permitted tools and trusted external services, then specify read or write authority. Set transaction limits and prohibited actions. Add the approval state and expiry date for each expanded permission. The AI agent identity governance guide covers the wider process for issuing and reviewing those identities, as well as removing them.

Draw the action boundary on one page. A reviewer should see that a support agent can read an approved knowledge base and draft a response, while customer-record changes require a separate authorized path. For MCP, name the trusted servers on an allowlist and reject unlisted destinations at the tool layer. A sentence in the system prompt provides weak evidence because the agent interprets it. An access rule creates a testable limit.

Human approval checkpoints need operating tests

IMDA recommends human approval at significant checkpoints, especially before high-stakes, irreversible, atypical, or user-defined actions. The May revision names editing sensitive data, making payments, sending communications, and permanently deleting records. The framework also asks organizations to make approval requests contextual and digestible. Organizations should train reviewers and audit the effectiveness of oversight.

For each checkpoint, record the triggering action and risk condition. Name the authorized reviewer and the information shown on the approval screen. Record the available choices and validity period separately. Define the result when approval infrastructure fails. The framework recommends denying action by default when supervisors are unreachable or an action lacks an established approval policy. Preserve the proposed action and relevant data class. Keep the agent identity and initiating user, followed by the policy version and reviewer identity. Record the decision and timestamp. Add written justification where required.

A bright green Approve button can still be an empty control. The reviewer needs enough context to see the affected system and irreversible consequence without reading a raw execution trace. I would test approval quality with seeded cases. Include one request that should be rejected and one expired approval. Track overrides and response times for signs of rubber-stamping or fatigue, then change the checkpoint when those signals deteriorate.

Lifecycle controls extend beyond launch

The technical-control dimension starts with design and testing, then continues through rollout and production monitoring. Change review completes the cycle. During design, IMDA prefers deterministic system-level safeguards for higher-risk actions where fixed rules can define the boundary. The framework gives tool-layer access control as an example. Before deployment, teams should test overall task execution and policy adherence. They should examine tool selection and permissions, then inputs and ordering. Testing must also cover behavior under errors or edge cases.

Build a lifecycle control record around those stages:

• Design: link every identified risk to a control point and owner. Record the trusted tools and approved MCP servers. Define data boundaries and the authentication method, then document the permission policy and sandbox. Name the human checkpoint.
• Pre-deployment: run expected and prohibited workflows in a realistic test environment. Preserve the fixture and agent version. Save the tool configuration and expected result, followed by the actual result and reviewer. Record the remediation.
• Deployment: limit the first release by trained users and available features. Limit the connected systems and whitelisted services as well. Document the expansion criteria before widening access.
• Operation and change: monitor high-risk actions and attempted unauthorized access. Also monitor repeated tool calls and approval failures. Track agent-to-agent handoffs. Re-run risk review when models or tools change. Apply the same review to changes in permissions and autonomy, plus new regulatory requirements.

The agentic AI runtime security guide maps the control points inside a running agent loop. IMDA adds pre-release tests, phased deployment, interventions for production anomalies, and preserved audit trails. A change process must account for cascading effects across connected agents.

Users need an operating card

The fourth dimension assigns responsibility to people who interact with agents and those who integrate agents into work. IMDA asks organizations to tell users that they are dealing with an agent at the point of interaction. Users should also learn what the agent can do and which data it collects or accesses. They need to know where a human remains accountable and how to escalate a malfunction.

Create an operating card for each user group. For an external user, place the agent disclosure in the interface and name the available actions. Describe data treatment and provide a human contact, followed by the complaint or escalation route. For an employee using an agent inside a workflow, add the approved use cases and restricted data. Document common failure modes and approval duties. Include the fallback procedure and refresher schedule. Record completion of training and updates after material capability changes.

The May revision also raises tradecraft and business continuity. If an agent takes over the entry-level work that taught staff how a process functions, the fallback plan needs trained people who can still perform it. Test that plan during a controlled agent outage. A policy link in the footer provides disclosure. A timed exercise proves the team can continue operating.

The four records join into one deployment decision

Keep the boundary record, checkpoint specification, lifecycle control record, and user operating card under the same deployment ID. A change to tool access should trigger review of the boundary and test set. A new irreversible action should update the approval checkpoint. New users need an updated operating card before rollout. Monitoring results should feed back into the risk decision.

The agentic AI compliance guide covers the broader relationship with NIST and ISO/IEC 42001. It also covers the EU AI Act. Singapore's framework asks who remains accountable, which powers are bounded, how controls operate throughout the lifecycle, and what users need to supervise the system.

Use one approval packet for the go-live review. Include the four current records and open exceptions. Add the test failures and residual-risk decision. Name the acceptance authority. Give each artifact a version and effective date. Six months later, the reviewer should be able to reconstruct the exact operating boundary without relying on a slide deck that describes the pilot.

DeepInspect

DeepInspect can supply one bounded part of the Singapore framework's deployment evidence. For authenticated HTTP calls deliberately routed between a user or agent and an LLM, the stateless proxy can evaluate application-supplied identity and role. It can also evaluate the model destination and data classification, followed by the active policy, before permitted traffic proceeds. HTTP tool egress can enter that scope only when the deployment routes it through the same enforcement path.

Each routed decision can retain the policy version and matched rule. The record can also retain the action and destination, followed by the timestamp and supplied identity under the organization's evidence policy. Those records support tests for model-route boundaries and data policy. Local actions and platform-internal execution remain with their designated owners. The same applies to identity issuance and user training. Approval design and the final deployment-risk decision also remain with their designated owners.

Book a technical deep dive at deepinspect.ai.