In January 2026 IMDA published the world’s first Model AI Governance Framework for Agentic AI. By May it had been revised, with case studies and practices contributed by more than 50 organisations, and labelled a living document. Singapore moved faster on this than anyone, which means Singapore companies get asked about it first.
The framework exists because of a specific gap. Earlier governance work, including IMDA’s frameworks for traditional and generative AI, assumed a human reviewed the output before anything happened. An agent breaks that assumption. It makes multi-step decisions, calls tools, writes to systems, and carries on without a person in the loop for each step. The output is not a paragraph someone reads. It is a refund issued, a record updated, an email sent to a customer.
Most Singapore companies deploying agents right now have not reckoned with what that changes. The agent is given an API key with whatever permissions were convenient, wired into a production system, and watched for a week. It works. Attention moves on. Nobody writes down what it is allowed to do, nobody can reconstruct what it did three Tuesdays ago, and nobody has a way to undo a bad run.
That is the exposure, and it is not theoretical. An agent with broad credentials and no action log is a system where you cannot answer the two questions that follow any incident: what did it do, and on whose authority. Those are the questions a regulator asks, and they are the questions a client’s procurement team now asks before signing.
Who is accountable when an agent acts alone?
You are. The framework is direct about it, stating that humans remain ultimately accountable for AI agent outputs.
This matters more than it sounds, because the commercial instinct runs the other way. Teams deploying agents tend to describe them as though agency transferred with the task. The agent decided. The model got it wrong. The vendor’s tool misfired. None of that survives contact with a governance review, and none of it survives a client asking who signed off.
Accountability that means anything has a name attached. Not a function, not a committee, a person who can describe what the agent is permitted to do and who approved that scope. In practice this is the control most often missing, and it costs nothing to fix. It is a line in a document and a conversation with the person whose name goes on it.
The second non-technical control the framework calls for is an incident escalation path. When an agent does something wrong at 2am on a Saturday, who gets woken, and what are they authorised to switch off. Teams that have an on-call rotation for infrastructure frequently have nothing equivalent for the agents now running inside that infrastructure.
The controls IMDA actually asks for
Three technical controls carry most of the weight, and they are all unglamorous.
Least-privilege access. The agent gets the narrowest set of permissions that lets it finish its job, and nothing adjacent. An agent that drafts replies does not need delete rights. An agent reconciling invoices does not need access to payroll. The common failure is handing an agent a service account built for a human administrator, because that account already existed and already worked.
Logging of every action. Not the model’s reasoning, which is interesting but not the point. The actions: which tool was called, with what arguments, against which record, at what time, under which identity. This is the difference between an incident you can investigate in an hour and one you cannot investigate at all. It is also what lets you prove an agent did not do something, which turns out to be the more common need.
Rollback. A way to reverse what the agent did. For some systems that is straightforward, because writes are versioned and reversible. For others it requires deliberate design, and the honest answer is that an agent should not be given write access to a system where its actions cannot be undone until someone has thought about that properly.
Meaningful human oversight sits across all three. The framework’s phrasing is worth noting, because oversight that exists on paper and never fires is the thing it is written against. Oversight means a person sees a decision before it commits, at points chosen because they are consequential, not at points chosen because they were easy to instrument.
How this fails in practice
A worked example makes the controls less abstract. A support agent is deployed to handle refund requests under a dollar threshold, reading from the order system and writing to the payments system. It runs well for six weeks.
In week seven a supplier changes a field in the order feed. Currency codes start arriving in a different position. The agent reads an amount correctly and a currency incorrectly, and issues a run of refunds in the wrong denomination. The error is small per transaction and the volume is high.
Now trace what each missing control costs. Without an action log, the finance team discovers this from a bank reconciliation rather than from the system, days later, and cannot produce the list of affected transactions without reconstructing it by hand. Without rollback, reversing the refunds is a manual operation against live customer records. Without a scoped credential, the investigation has to consider everything else that account could have touched, which widens the review from one system to four. Without a named owner, three teams each believe another team is handling it.
None of those failures is the model’s. The agent did exactly what it was asked to do with the data it was given. What turned a field-mapping bug into a week of cleanup was the absence of the unglamorous controls around it.
Financial services is on a tighter clock
If you are a financial institution, or you build for one, the picture is further along. MAS has issued the FEAT principles and published observations on AI Model Risk Management. Neither is binding regulation in itself, and both convey supervisory expectations that institutions are strongly encouraged to adopt. MAS has also indicated it intends to develop formal supervisory guidelines on AI risk management.
Read that sequence as a direction of travel. Guidance becomes observation becomes guideline. Institutions building agentic systems this year will be asked to show governance that was designed in, not retrofitted, and retrofitting logging onto a live agent is considerably harder than building it in on day one.
For vendors serving that sector, the practical consequence is that governance artefacts are now part of the deliverable. A model card, an action log schema, a documented permission scope and a named accountable owner belong in the handover pack alongside the runbook.
What to do before the next agent goes live
Start with an inventory, because most organisations do not have one. List every agent currently running, what credentials it holds, what systems it can write to, and who approved it. That list is usually longer than expected and the approval column is usually empty.
Then work the three technical controls in order of what breaks worst. Permissions first, because over-broad credentials turn a small error into a large one. Logging second, because without it you cannot assess anything else. Rollback third, and where rollback is genuinely impossible, change the agent’s write access rather than accepting the risk quietly.
Webpuppies builds agentic systems for clients in Singapore and the region on Claude, AWS and OpenAI infrastructure, with permission scoping, action logging and escalation paths designed in from the start. If you have agents running and no inventory of what they can reach, that is the audit worth doing first. Get in touch.
Sources
- Singapore: IMDA updates Model AI Governance Framework for Agentic AI, Baker McKenzie
- AI Regulation in Singapore and Hong Kong: A Mid-Year Checkpoint, Mayer Brown
- Updated Model AI Governance Framework for Agentic AI, Regulations.ai
- Singapore’s Digital and AI Governance: A Pro-Innovation, Framework-Driven Model, Duane Morris
Frequently Asked Questions
What is the IMDA Model AI Governance Framework for Agentic AI?
A governance framework IMDA published in January 2026, the first of its kind globally, covering AI systems that make autonomous multi-step decisions with limited real-time human involvement. IMDA updated it in May 2026 with case studies contributed by more than 50 organisations.
Is the IMDA agentic AI framework legally binding?
No. It is guidance, not legislation, and Singapore has deliberately taken a framework-driven approach rather than a statutory one. It still shapes procurement questions, audit expectations and what a regulator will ask after an incident.
Who is accountable if an AI agent causes harm?
The framework is explicit that humans remain ultimately accountable for AI agent outputs. Deploying an agent does not move liability onto the vendor or the model provider.
What technical controls does the framework recommend?
Least-privilege access for the agent’s credentials, logging of every action the agent takes, and rollback mechanisms that can reverse what it did. These sit alongside non-technical measures such as named accountability and incident escalation paths.
Does this apply to financial institutions differently?
Yes. MAS has issued the FEAT principles and its AI Model Risk Management observations, which convey supervisory expectations, and has signalled it intends to develop formal supervisory guidelines on AI risk management.
