Singapore Published the First Agentic AI Governance Framework. Here's the Engineering Playbook.

Your procurement team forwards a new enterprise questionnaire from a Singapore customer. It is not the usual SOC 2 plus DPA bundle. It asks how your AI agents decide to act, who can override them, what happens when they hit an exception, and whether you can prove those controls were in place at the moment the agent executed.

If you are shipping agentic AI into regulated workflows, this is the new friction point. Most organizations still govern models. Singapore is already governing systems that plan and act.

What Singapore actually published

On January 22, 2026, Singapore's Infocomm Media Development Authority (IMDA) launched the Model AI Governance Framework for Agentic AI at the World Economic Forum. It is the first governance framework in the world designed specifically for AI agents capable of autonomous planning, reasoning, and action.

The framework is built around four dimensions: assessing and bounding risks upfront, making humans meaningfully accountable, implementing technical controls and processes throughout the agent lifecycle, and enabling end-user responsibility through transparency and education. Alongside the governance framework, the Cyber Security Agency of Singapore released a companion discussion paper on securing agentic AI, covering attack surfaces and vulnerabilities that agentic systems introduce, including prompt injection, tool misuse, and cascading failures across multi-agent systems.

Read together, the two documents sketch a comprehensive picture of how Singapore thinks organizations should approach deploying AI that acts, not just AI that advises. The governance framework is non-binding, but Singapore has historically used its regulatory environment as a competitive advantage, and frameworks like this tend to become procurement baselines before they become law.

The third dimension, technical controls and processes, is where most organizations have the largest gap. The MGF specifically calls for tool guardrails, least-privilege access to tools and data, policy compliance testing and tool use accuracy testing pre-deployment, progressive rollouts, and real-time monitoring post-deployment. That reads less like a governance document and more like an engineering requirements spec. What follows is how to implement it.

Step 1: Inventory what actually exists

Agent governance starts with an uncomfortable truth: most organizations cannot answer, with confidence, what agents they have in production, what those agents can touch, and under which authority.

In the model era, an inventory meant which models are deployed and what datasets were used. In the agent era, your inventory needs to be structured around capability and blast radius. You need four inventories that stay in sync.

The agent inventory captures purpose and workflow, operating mode (fully autonomous, human-in-the-loop, or assistive-only), decision scope (may propose refunds versus may issue refunds under $50), execution surface (which systems it can act on), and deployment boundaries including environment, regions, and data residency constraints.

The tool inventory captures each API integration, function, plugin, and database connector the agent can reach. For each tool: owner, category (read-only, write, destructive, financial, customer-facing, code execution), input/output schema, side effects, authentication method, and rate limits. The same agent becomes high-risk or low-risk depending on whether it can call CreateRefund() or only DraftRefundEmail(). That distinction needs to be explicit.

The MCP server inventory is the new supply chain layer most teams miss. The Model Context Protocol is rapidly becoming a standard way to expose tools to agents. For each MCP server, capture hosting and trust boundary, exposed tools list, versioning and change control, logging and auditability, and data handling. If your agents can dynamically discover tools through MCP, treat MCP servers like package registries in software security: powerful, convenient, and a common path for unexpected capability expansion.

The permission inventory captures the credentials and authority that make actions possible. Which identity the agent assumes. Exact API scopes, database roles, and cloud IAM roles. Whether the agent acts as the user, on behalf of the user, or as a shared service principal. Token TTLs and re-auth requirements. And separation of duties: where approvals are required and who can approve.

The deliverable is a living agent capability registry that ties together agent to tools to MCP servers to permissions, and can answer: what can this agent do, through what path, under what authority, and with what logging?

Step 2: Define action boundaries as enforceable rules

The MGF pushes organizations toward something many teams avoid: writing down what the agent is allowed to do in a way that can be checked at runtime. Most companies have acceptable use language that says "do not share sensitive information" and "escalate uncertain cases." Those are intentions, not controls.

Structure boundaries into four categories.

Allowed operations are actions the agent can take without asking because the risk is low and the blast radius is bounded. A support agent may read CRM records and draft responses but may not send without review. A finance agent may categorize expenses and recommend reimbursements but may not execute payments. What makes these safe is that they are either read-only or they create reversible artifacts rather than irreversible actions.

Blocked operations are hard stops that should never happen regardless of context. Agent may not export full customer lists. Agent may not rotate credentials or create new admin users. Agent may not send external emails from an executive mailbox. Agent may not execute arbitrary shell commands in production. These are denies, not best efforts. If your architecture cannot reliably block these pre-action, you are left with monitoring and cleanup, which is exactly what Singapore's framework is trying to move beyond.

Approval-gated operations acknowledge that some actions are legitimate but only with an explicit, attributable decision by a human or a higher-trust system. Refunds over $50 require approval by a support lead. Any change to production infrastructure requires approval by on-call SRE. The key is that approval must be engineered, not implied. If the agent can call the tool directly, you do not have a gate. You have a policy statement.

Escalation paths define what safe failure looks like. Agents will hit ambiguity: missing data, conflicting instructions, tool errors, policy conflicts. Escalation should be explicit: escalate to a human with a structured packet, defer and create a ticket, fallback to a safe alternative tool, or abort with a user-visible explanation. A well-governed agent does not just avoid harm. It fails in a way your organization can operationalize.

Step 3: Enforce policy pre-action, not post-hoc

The MGF's emphasis on technical controls throughout the agent lifecycle points toward a specific architectural pattern: the LLM proposes, the system disposes.

Most agent governance implementations make the same mistake. They put the model in the driver's seat and try to monitor what happens after. The failure mode looks like this: the agent takes an action (refund, email, data update), monitoring detects something odd after the fact, humans triage and clean up. That is backwards for consequential actions.

The reference architecture that operationalizes Singapore's direction has five layers.

The intent layer treats the LLM as a planner, not an executor. The LLM interprets the user request, proposes a plan, suggests tool calls with structured parameters, and explains rationale. But the LLM does not directly execute tools. It outputs a tool call request that is then evaluated. This separation lets you treat the LLM as an untrusted component in a trusted system, the same principle we use in security engineering.

The policy engine is the enforcement point. Before any tool call executes, it passes through a policy decision point that evaluates agent identity and current mode, tool requested and category, target resource, data classification, context signals (user role, ticket severity, time of day, unusual patterns), and applicable rules. The output is not just yes or no. It should include the decision (allow, block, require approval, require escalation), the reason (rule IDs and explanations), and required controls (redactions, additional logging, rate limits, step-up auth).

The approval service handles gated operations. When a tool call requires approval, the system generates a request that includes the proposed action and parameters, the agent's rationale, risk flags, a preview of the side effect where possible, and the policy rule that triggered the gate. The approval artifact must be immutable and linked to the eventual execution.

The execution layer runs tools behind a controlled gateway that enforces authentication and least privilege, rate limits, parameter validation, output filtering and data minimization, and logging with correlation IDs. If you are using MCP, this is where you put a control plane in front of MCP servers rather than letting agents connect directly to arbitrary tool endpoints.

The oversight layer records what happened after execution, whether it matched the intended plan, and whether any anomaly signals fired. Post-hoc checks are valuable as backstops, but the governance win is preventing unauthorized actions before they occur.

Step 4: Generate evidence continuously

The MGF's fourth dimension, end-user responsibility through transparency, and the broader requirement for human accountability both depend on evidence that controls were operating at the moment the agent acted. Quarterly audits will not satisfy this.

Three things make continuous oversight real.

Event logs need to capture the full chain: user request, agent version (prompt and config hash, orchestrator version, tool registry version), the agent's proposed plan, tool call request with parameters, policy decision with the rule that fired, approval artifact if applicable, tool call response, and post-action evaluation. This is what turns "we think the agent is safe" into "we can show you the chain of custody for every consequential action."

Versioning must treat agents like production systems. Most teams version code but treat agent prompts, tool schemas, and routing logic as configuration that changes informally. You need versioning for agent prompts and system instructions, tool schemas and contracts, tool allowlists and denylists, policy rules and thresholds, model versions, and MCP server versions. You need to be able to say: on March 12 at 14:03 UTC, this agent ran with this exact configuration and this exact set of tools. If you cannot do that, you have snapshots, not continuous oversight.

Policy tests on every change close the loop. Every change to an agent, tool, or policy triggers a test suite that includes "should allow" and "should block" scenarios and produces artifacts: pass/fail, logs, and evidence. Prompt injection regression tests: can an untrusted email cause the agent to exfiltrate secrets? Tool misuse tests: can the agent call a destructive tool without approval? PII leakage tests: does the agent include full SSNs in outbound messages? If you are deploying agents weekly, periodic audits will always be behind. Continuous compliance is the only approach that scales with deployment velocity.

Why this will show up in your procurement queue

Even if your organization does not operate in Singapore, expect Singapore-style agent governance questions to become common. The questions align with how enterprise buyers experience agent risk. Can the agent take actions we did not intend? Can it be tricked via prompt injection? Can we constrain it to our processes? Can we prove, after an incident, what happened? Can we show auditors that controls are continuous, not annual?

The market pattern is familiar. SOC 2 started as a US trust services framework and became a global procurement checkbox. Agent governance frameworks that are specific enough to operationalize will travel the same way. And there is a second reason: agent platforms are shipping faster than organizations can invent governance from scratch. When teams adopt Salesforce Agentforce, Microsoft Copilot Studio, OpenAI tool-use patterns, or MCP-based internal agents, they inherit an execution layer immediately. Procurement and security teams will reach for whatever framework gives them concrete questions and defensible answers.

Singapore is positioning itself as one of those sources. The organizations that prepare now, with inventories, enforceable boundaries, pre-action enforcement, and continuous evidence, will answer those procurement questionnaires in hours instead of quarters.

We built Aguardic to turn governance frameworks into enforceable runtime controls. If your team is deploying agents into production workflows, see what enforcement looks like against your own policies and whether your current architecture passes the pre-action test.