Singapore's Agentic AI Governance Framework: What It Actually Requires

Singapore has now done something no other jurisdiction covered in this publication has done: issued a governance framework addressed specifically to autonomous AI agents, as distinct from generative AI generally, followed by a dedicated discussion paper asking the harder question of who is legally responsible when an agent’s autonomous action causes harm. These are two separate documents from the Infocomm Media Development Authority, published four months apart, and they answer two different questions. Conflating them, as a fair amount of commentary already has, obscures what each one actually does.

The Framework: 22 January 2026

The Model AI Governance Framework for Agentic AI is IMDA’s answer to how an organisation should build and deploy an AI agent responsibly. It is not aimed at generative AI chatbots, which IMDA’s earlier general guidance already covers. It is built around a distinction this publication has made before: an agent plans its own steps and acts, largely without a human reviewing each one, and that changes what governance has to look like. The framework organises its requirements around four dimensions.

Assess and bound the risks upfront. Before deployment, an organisation must determine suitable use cases for the agent and design explicit limits on what it can do, rather than deploying broadly and narrowing scope only after something goes wrong.
Make humans meaningfully accountable. Responsibility must be allocated to specific roles, not left diffuse, and oversight has to be genuinely effective, not a formality.
Implement technical controls and processes, spanning development, pre-deployment testing, and continuous post-deployment monitoring.
Enable end-user responsibility, through transparency about what the agent does and training for the people relying on it.

Within the technical controls dimension, the framework gets specific in ways worth quoting precisely, because they translate directly into what a firm advising a client on agent deployment, or deploying one internally, should actually check for.

Access controls and guardrails. The framework calls for applying the principle of least privilege to limit the tools available to each agent, with robust authentication and authorisation, and specifically warns against granting an agent write access to sensitive databases unless strictly required. Agents should run in self-contained environments with limited network and data access, governed by defined standard operating procedures that constrain autonomy rather than leaving it open-ended.

Human approval checkpoints. The framework identifies specific categories of action that should require human sign-off before an agent proceeds: high-stakes actions such as editing sensitive data, irreversible actions such as permanently deleting data or sending communications, and outlier or atypical behaviour where an agent accesses systems outside its normal scope. It also makes a practical point often missed in policy drafting: approval requests should be kept contextual and digestible, not buried in raw data a human supervisor has no realistic chance of reviewing properly under time pressure.

Logging and monitoring. Organisations are expected to continuously monitor and log agent behaviour after deployment, with threshold-based alerts (for example, an agent attempting unauthorised access or making repeated tool calls), anomaly detection, and the capacity for real-time intervention to stop an agent’s workflow and escalate to a human supervisor. Logging must capture each step of an agent’s workflow, including agent-to-agent interactions, not just the final output.

Accountability distribution. The framework assigns distinct responsibilities across organisational roles: leadership defines permitted use cases and data access limits, product teams own reliable implementation across development, testing and monitoring, cybersecurity teams implement baseline security guardrails, and end users bear responsibility for ethical use and reporting issues. For agents built on external vendor tools, the framework expects organisations to clarify the distribution of obligations in contracts and terms of service, and to verify that vendors actually provide adequate authentication and observability, rather than assuming a vendor’s marketing claims satisfy this. Where a vendor’s controls fall short, the framework’s expectation is that the organisation either sources an alternative, builds in-house, or narrows the use case, not that it proceeds regardless.

Multi-agent and third-party risk. The framework treats multi-agent systems as a distinct risk category, flagging cascading effects where one agent’s mistake propagates as its output is passed to others, and unpredictable coordination where agents compete or interfere in unintended ways. Testing is expected at the multi-agent system level specifically, to surface emergent behaviour that wouldn’t appear when testing a single agent in isolation. On third-party integrations, the framework singles out protocols such as MCP servers as a specific vulnerability, an untrusted or compromised server can be used to exfiltrate data, and recommends whitelisting trusted servers and sandboxing code execution, while acknowledging that current identity systems struggle to handle complex third-party agent setups and that this remains an area of interim best practice rather than settled standard.

The Discussion Paper: May 2026

Four months after the framework, IMDA published a separate document, the Discussion Paper on Legal Responsibility for AI Agents, developed with input from a working group of over twenty members including legal professionals. This document does not tell organisations how to build agents safely. It asks a different question: when an autonomous agent’s action causes harm, which existing legal doctrine, if any, actually assigns responsibility for it, and does that doctrine need to change.

The paper identifies three features of agentic AI, autonomy, decision-making capability, and action-taking capacity, as the source of the difficulty, and works through four existing liability frameworks against that difficulty:

Contract law can define obligations between the parties who agreed to them, but is limited by privity, it says little about a harmed third party outside the contractual chain, and there’s a live concern that risk gets shifted onto whichever party in the chain has the weakest bargaining position.
The tort of negligence, built on duty, breach and damage, runs into real difficulty with foreseeability and causation once an agent’s decision-making path is autonomous and not fully predictable even by its own developer.
Product liability could in principle apply, but Singapore’s existing product liability law is narrowly scoped and wasn’t drafted with autonomous software decision-making in mind.
Strict liability is raised as an alternative that would sidestep the foreseeability problem, but IMDA flags the obvious concern: strict liability risks deterring exactly the innovation the framework’s four dimensions are meant to enable responsibly.

The paper’s own framing of the problem is worth quoting directly: the central challenge, in its words, is not the absence of applicable legal principles, but how those principles should be applied to agentic AI. That is a materially different, and more honest, position than claiming existing law already has this covered. The paper explicitly leaves open, for further study, how value-chain responsibility should be allocated between developer, deployer and platform, how to protect consumers with limited bargaining power in that chain, and how to treat harm arising from an agent’s genuinely unforeseeable action.

What Practitioners Should Actually Take From This

The discussion paper is exactly that, a discussion paper, open for input, not a statement of settled law, and it should not be cited to a client as though it resolves a liability question it explicitly says remains open. That has a direct practical consequence: until this settles further, the allocation of responsibility for what your client’s AI agent does sits almost entirely in whatever your contracts say, because the general law has not yet caught up to the framework’s own risk architecture. This is squarely a drafting problem right now, not a litigation certainty either way.

For firms advising on agent deployment or procurement in Singapore, three things follow directly from the two documents together.

First, treat the framework’s four dimensions as your due diligence checklist for any client considering deploying an agent, not as best-practice advice to mention in passing, since a client who ignores them is building on a foundation the discussion paper’s own liability analysis assumes doesn’t exist yet.

Second, push vendor and deployment contracts to allocate responsibility expressly for the specific failure modes the framework identifies, unauthorised access, cascading multi-agent failure, third-party protocol compromise, rather than relying on generic AI liability boilerplate that predates this level of specificity.

Third, watch this discussion paper’s consultation outcome closely. When IMDA moves from discussion paper to settled guidance or legislative proposal, it will very likely track the four liability frameworks it has already ruled in or out here, which gives you an unusually clear preview of where Singapore law is heading on this question.

This is precisely the kind of governance and accountability structure we address in the Compliance and Governance module of The AI Bar Foundation for Lawyers, and it’s worth reading alongside our earlier piece on agentic AI in legal practice generally, since IMDA’s framework is now the most detailed regulatory answer anywhere in the jurisdictions we cover to the exact governance gap that piece identified. The framework tells you how to build the agent responsibly. The discussion paper is IMDA’s own admission that nobody, including the regulator, has fully worked out yet who answers for it when something goes wrong.