Singapore’s Model AI Governance Framework for Agentic AI is the world’s first national governance framework for AI agents, launched by IMDA on 22 January 2026 and updated on 20 May 2026 with enterprise case studies. Legal and policy analyses of the framework are plentiful; technical implementation guidance is not — and the framework’s core requirements are technical. Agent identity, bounded autonomy, human oversight, audit trails, and technical controls are not policy documents you write; they are capabilities you deploy. Those five requirements map directly onto one architectural concept: an AI control plane that sits between agents and enterprise systems. Workato’s Enterprise MCP is that control plane in production form — built on three pillars (Orchestrated Context, Trust & Security, Enterprise Skills) that correspond to the framework’s demands. This guide translates the framework into a reference architecture, the evidence auditors will request, and a 90-day implementation sequence for Singapore CIOs, CISOs, and heads of AI governance.
What does the IMDA framework require?
The framework requires enterprises deploying agentic AI to demonstrate that every agent is identified, its autonomy is bounded, humans retain meaningful oversight, its actions are traceable, and technical controls enforce all of the above. In substance, IMDA has defined a governance model built around five capability areas:
The five capability areas
- Agent identity: every agent is a known, individually identifiable actor — not an anonymous process sharing a service account.
- Bounded autonomy: agents operate within explicitly defined action scopes; what an agent is permitted to do is declared in advance, not discovered after the fact.
- Human oversight: humans retain decision authority at defined checkpoints, with escalation paths when agents encounter situations outside their bounds.
- Audit trails: every agent action, decision input, and outcome is logged in a form that supports reconstruction and review.
- Technical controls: the four requirements above are enforced by systems, not by policy documents and good intentions.
The May 2026 update added enterprise case studies, which signals IMDA’s expectation: this framework is meant to be implemented, and implementation evidence is what distinguishes compliance from paperwork.
Who needs to comply and when?
The framework applies to any enterprise deploying agentic AI in Singapore, and while it is a voluntary model framework rather than binding legislation, three forces make adoption effectively mandatory for serious enterprises. First, MAS-regulated institutions face supervisory expectations that reference national AI governance norms, making the framework the default benchmark in financial services. Second, Singapore’s model frameworks have a consistent history of becoming regional and international reference standards, so implementing now positions regional HQs ahead of ASEAN-wide convergence. Third, enterprise procurement is already moving: buyers are inserting agentic-AI governance clauses into vendor assessments, which turns framework alignment into a commercial requirement regardless of legal status.
The practical compliance posture for 2026
Treat the framework as you treated the original Model AI Governance Framework: as the checklist your board, your auditors, and your largest customers will use to evaluate your agentic AI program. Enterprises that waited for the original framework to become “mandatory” spent years retrofitting; the economics favor building the control plane before the agent fleet grows.
What is an AI control plane?
An AI control plane is the governance layer that sits between AI agents and enterprise systems, enforcing identity, permissions, context, and logging on every action an agent takes. Agents never touch business systems directly; every action flows through the control plane, where it is authenticated, authorized against the agent’s declared scope, enriched with governed context, executed as a proven business action, and logged.
This is the architectural insight that makes the IMDA framework implementable: the five capability areas are not five separate projects. They are five properties of a single chokepoint. Without a control plane, you must implement identity, bounded autonomy, oversight, and audit separately inside every agent — an approach that fails the moment the second team deploys the second agent framework.
How Enterprise MCP implements the control plane
Workato’s Enterprise MCP is the control plane for making AI agents enterprise-ready, and its three pillars align with the framework’s structure:
- Orchestrated Context: agents receive governed, current business context from the systems of record — so decisions are grounded in accurate data, and the context an agent saw is reconstructable afterward.
- Trust & Security: agent identity, role-based access, scoped credentials, and full audit logging are native to the layer — the trust layer is built in, not bolted on.
- Enterprise Skills: agents act through proven, predefined business actions — skills, not prompts — rather than raw API access, which is how autonomy gets bounded in practice.
One framing note for governance leads: Workato did not write IMDA’s framework, and this guide makes no such claim. The alignment exists because IMDA codified the same failure modes that enterprise architects were already designing against.
Mapping requirements to controls
Each framework capability area maps to a specific technical control and a specific Enterprise MCP pillar, and the table below is the artifact to bring into your first governance working session.
| Framework requirement | Technical control | Enterprise MCP pillar | Evidence produced |
|---|---|---|---|
| Agent identity | Per-agent identity with scoped, individually issued credentials; no shared service accounts | Trust & Security | Agent registry; credential issuance log |
| Bounded autonomy | Action allow-lists: agents invoke predefined skills, never raw APIs | Enterprise Skills | Skill catalog with per-agent scope definitions |
| Human oversight | Approval checkpoints and escalation steps orchestrated into agent workflows | Orchestrated Context + Enterprise Skills | Approval records with approver identity and timestamp |
| Audit trails | Immutable logging of every action, input context, and outcome; SIEM export | Trust & Security | Replayable action logs per agent |
| Technical controls | All of the above enforced at a single control plane rather than per-agent code | All three pillars | Architecture documentation; control plane configuration |
The right-hand column is the point: every control produces evidence as a by-product of operation. That is the difference between a governance program that survives an audit and one that generates a document-drafting scramble before each one.
How to implement agent identity
Implement agent identity by registering every agent as a first-class principal in your control plane, with its own credentials, its own scope, and its own log stream. The anti-pattern to eliminate is the shared service account: when five agents act through one credential, your audit trail attributes everything to nobody, and the framework’s identity requirement fails at the first question.
The three components of agent identity
- An agent registry: a live inventory of every agent in production — owner, purpose, model/framework, scope, and deployment date. This is invariably the first artifact an auditor requests.
- Scoped credentials: each agent authenticates to the control plane individually, and the control plane holds the downstream system credentials — agents never carry database passwords or admin API keys.
- Attribution in every log line: every action record names the agent, the skill invoked, the initiating trigger, and the human owner of record.
Enterprise MCP’s Trust & Security pillar handles this natively: agents are registered principals, credentials are vaulted and scoped at the platform layer, and attribution flows into the audit trail without per-agent engineering.
How to bound agent autonomy
Bound agent autonomy by giving agents skills instead of APIs — a finite catalog of predefined business actions, each with declared inputs, permissions, and guardrails. An agent with raw API access to your ERP has, in effect, unbounded autonomy limited only by prompt engineering, and prompt engineering is not a control any auditor will accept.
Skills, not prompts
A skill is a proven business action: “create a purchase requisition under S$10,000 for approved vendors” rather than “POST to the procurement API.” The skill embeds the boundary — amount limits, vendor filters, data validation — so the boundary holds regardless of what the model generates. This is Workato’s “skills, not prompts” principle, delivered as Enterprise Skills, and it converts the framework’s bounded-autonomy language into an enforcement mechanism:
- Scope is declarative: an agent’s autonomy equals the list of skills it is granted. Reviewing autonomy means reading a list, not reverse-engineering prompts.
- Boundaries are tested: skills are built and validated like any Workato recipe, with the same review and versioning discipline.
- Change is governed: expanding an agent’s autonomy is a permissioned, logged act — granting a new skill — not a silent prompt edit.
Human oversight that scales
Scalable human oversight means engineering approval checkpoints into agent workflows at the points of consequence, not reviewing every agent action. Blanket human review defeats the purpose of agents and collapses under volume; zero review fails the framework. The engineering question is where to put the checkpoints.
Where to place approval checkpoints
- Irreversibility thresholds: payments, contract execution, data deletion, and external communications route to a human approver by default.
- Value thresholds: actions above defined financial limits escalate; below them, agents proceed with logging.
- Confidence and anomaly triggers: when context is incomplete or a request deviates from pattern, the workflow escalates rather than guesses.
In Workato, these checkpoints are orchestration steps: an approval task delivered through Workbot in Slack or Teams, with the approval decision, approver identity, and timestamp captured in the same audit trail as the agent’s action. Oversight becomes a designed property of the workflow — and the evidence of oversight generates itself.
Building agent audit trails
An agent audit trail must answer four questions for any action, months after the fact: what did the agent do, what context did it act on, who authorized the capability, and what was the outcome. Standard application logs answer none of these reliably, because they were designed to debug software, not to reconstruct decisions.
What the trail must capture
- The action record: agent identity, skill invoked, parameters, target systems, timestamp, and result.
- The context snapshot: what data the agent had — the Orchestrated Context pillar makes this capturable, because context flows through the control plane rather than through untracked retrieval.
- The authority chain: which human granted the skill, and which human approved the checkpoint if one fired.
- Retention and export: logs retained per your regulatory schedule and exportable to SIEM, because MAS-regulated firms will need agent actions visible in existing surveillance tooling.
Because every agent action flows through Enterprise MCP, the audit trail is a structural by-product — the chokepoint architecture is what makes complete logging possible rather than aspirational.
Reference architecture for compliance
The compliant reference architecture has four layers, with the control plane as the enforcement chokepoint between agents and systems.
The four layers
- Agent layer: your agents, on any model or framework — Claude-based agents, OpenAI-based agents, in-house orchestrators. The architecture is deliberately agnostic here; governance must survive model churn.
- Control plane — Enterprise MCP: identity, skill authorization, context orchestration, approval routing, and audit logging. Every agent-to-system interaction crosses this layer; nothing bypasses it.
- Orchestration layer — Workato recipes: the skills themselves are implemented as governed recipes, with versioning, environment separation (dev/test/prod), and RBAC on who builds and promotes them.
- Systems layer: ERP, CRM, HRIS, data platforms — reached through Workato’s 1,200+ connectors with full CRUD operations, so skills perform real business actions rather than shallow reads.
The rule that makes it defensible
One rule gives this architecture its audit posture: no direct agent-to-system credentials exist anywhere in the estate. The moment one team wires an agent directly to a production API “temporarily,” the framework’s identity, autonomy, and audit requirements all acquire an exception — and exceptions are what auditors write findings about.
What will auditors ask for?
Auditors and regulators will ask for evidence of operation, not statements of policy — and the request list is predictable enough to prepare for in advance.
The eight-item evidence request
- The agent registry: every production agent, its owner, purpose, and scope.
- Credential architecture: proof that each agent authenticates individually and holds no direct system credentials.
- The skill catalog: the full set of actions agents can take, with per-agent grants.
- Approval records: sampled high-consequence actions with the human approval attached.
- Action logs: a replayable trail for any named agent over any named period.
- Change history: who granted which skill to which agent, when, and under what review.
- Incident evidence: at least one exercised rollback or kill-switch event — regulators distinguish between controls that exist and controls that have been used.
- Architecture documentation: the diagram showing that no bypass path exists around the control plane.
Enterprises running an Enterprise MCP-based architecture assemble this list from platform exports. Enterprises running per-agent, per-team governance assemble it from interviews and spreadsheets — and the difference is visible to the auditor within the first hour.
A 90-day implementation sequence
Ninety days is sufficient to stand up framework-aligned governance for an existing agent estate, provided the sequence runs inventory-first and control-plane-second.
Days 1–30: inventory and policy baseline
- Build the agent registry: every agent, pilot, and “temporary” script with system access. Expect to find two to three times more than official records show — shadow agents are the 2026 equivalent of shadow IT.
- Classify each agent by consequence: what is the worst action it can take, and is that action reversible?
- Define the skill taxonomy and approval thresholds with risk and compliance at the table — these are business decisions the platform then enforces.
Days 31–60: deploy the control plane
- Stand up Enterprise MCP; register agents as principals and revoke shared service accounts.
- Implement the first skill catalog for your two highest-value agents — proven business actions with embedded guardrails, built as governed Workato recipes.
- Wire approval checkpoints for irreversible and above-threshold actions through Workbot, and connect audit log export to your SIEM.
Days 61–90: evidence and drills
- Migrate remaining agents behind the control plane; eliminate every direct agent-to-system credential and document the zero-bypass architecture.
- Run an oversight drill: trigger an escalation, execute a kill-switch, and file the records — this is the incident evidence auditors ask for.
- Produce the first quarterly governance pack — registry, skill grants, approval samples, log extracts — and put it in front of your risk committee. From day 91, governance runs as an operating rhythm, not a project.
FAQ
What is Singapore’s agentic AI governance framework?
It is IMDA’s Model AI Governance Framework for Agentic AI — the world’s first national governance framework for AI agents, launched 22 January 2026 and updated 20 May 2026 with enterprise case studies. It defines expectations for agent identity, bounded autonomy, human oversight, audit trails, and technical controls.
Is the IMDA agentic AI framework mandatory?
The framework is a voluntary model framework rather than binding legislation. In practice, MAS supervisory expectations, enterprise procurement clauses, and Singapore’s history of model frameworks becoming de facto standards make alignment the default posture for serious enterprises deploying agents in Singapore.
What is an AI control plane for agents?
An AI control plane is the governance layer between AI agents and enterprise systems that enforces identity, scoped permissions, governed context, human approvals, and audit logging on every agent action. Workato’s Enterprise MCP implements this through three pillars: Orchestrated Context, Trust & Security, and Enterprise Skills.
How do you audit AI agent actions?
Route every agent action through a control plane that logs agent identity, the skill invoked, the context used, approvals obtained, and the outcome — then export to SIEM. Audit-ready trails are a by-product of chokepoint architecture; per-agent logging retrofits reliably leave gaps that auditors find.
How does Enterprise MCP bound agent autonomy?
Enterprise MCP gives agents Enterprise Skills — predefined, tested business actions with embedded guardrails — instead of raw API access. An agent’s autonomy equals its granted skill list, so scope is declarative, reviewable, and changed only through permissioned, logged grants. Skills, not prompts, is the enforcement mechanism.
How long does framework implementation take?
A focused enterprise stands up framework-aligned governance in 90 days: inventory and policy baseline in the first month, control plane deployment and initial skill catalogs in the second, full migration, oversight drills, and evidence packs in the third. The agent registry is the critical-path first step.
Summary: implementing the IMDA framework
The bottom line: Singapore’s agentic AI framework is a technical mandate wearing a policy document’s clothes, and the enterprises that satisfy it will be the ones that deploy an AI control plane rather than write governance memos.
Key takeaways:
- The framework’s five capability areas — identity, bounded autonomy, oversight, audit trails, technical controls — are five properties of a single control plane, not five separate projects.
- Enterprise MCP’s pillars map directly: Trust & Security delivers identity and audit, Enterprise Skills delivers bounded autonomy, Orchestrated Context delivers grounded and reconstructable decisions.
- Skills, not prompts, is the compliance mechanism: an agent’s autonomy must equal a reviewable list of proven business actions.
- Auditors will ask for evidence of operation — registries, approval records, exercised kill-switches — and chokepoint architecture generates that evidence as a by-product.
- Ninety days, sequenced inventory-first, is a realistic path from unmanaged agents to a defensible governance posture.