An AI agent pilot is ready for production in Singapore when you can show written evidence for ten gates: a risk tier for the use case, a tier for every action the agent can take, its own scoped identity, human approval before irreversible steps, workflow-level testing, a staged rollout with monitoring and a stop rule, change control, PDPA checks, vendor terms and user disclosure. Those gates follow IMDA’s Model AI Governance Framework for Agentic AI.
This AI agent governance checklist for Singapore covers the step most pilots skip: moving a demo that worked under a developer’s login, with someone watching every click, onto live records. Educational only, not legal or regulatory advice.
Who this is for, and who should skip it
For: Singapore CIOs, heads of operations, finance or customer service, risk teams, DPOs and product owners with an agent pilot, built in-house or bought, that leadership now wants in production.
Skip if: you have not picked a use case yet (start with choosing your first RAG or agent use case); you run a Philippine GCC and need the reviewer-staffing side (see AI agent governance in Philippine GCCs); or you need a meeting agenda for any AI feature launch (use the AI launch review board agenda).
What IMDA’s agentic AI framework actually says
IMDA launched the Model AI Governance Framework for Agentic AI at Davos on 22 January 2026 and updated it on 20 May 2026; the current version 1.5 is marked updated 5 June 2026. It targets organisations deploying agents, whether they develop them in-house or use third-party agentic solutions, and IMDA calls it a living document of emerging best practices. It sets out four dimensions:
- Assess and bound the risks upfront: choose use cases by risk; limit autonomy, tools and data access; make actions traceable.
- Make humans meaningfully accountable: allocate responsibility, require human approval at significant checkpoints, and audit those approvals.
- Implement technical controls and processes: design controls, pre-deployment testing, gradual rollout with monitoring, change management.
- Enable end-user responsibility: tell users when agents are used and train the people overseeing them.
It is not a statute: your binding duties still come from the PDPA and any sector rules. Nor is it static: version 1.5 added guidance on multi-agent risks, third-party agents and change management four months after launch.
Two related sources matter for most buyers. PDPC’s Advisory Guidelines on Use of Personal Data in AI Recommendation and Decision Systems (issued 1 March 2024) explain how the PDPA applies when machine-learning systems use personal data; they are advisory, and the PDPA prevails. For financial institutions, MAS consulted in November 2025 on proposed Guidelines on AI Risk Management that expressly cover AI agents, and in March 2026 said it was still reviewing responses. Check the MAS site for the current status before relying on the draft.
Original element: the pilot-to-production gate matrix
Fill one row per gate with the pilot team, the system owner and risk. A gate passes only when the evidence exists in writing.
| Gate | Evidence to show | IMDA dimension | Red flag | Owner |
|---|---|---|---|---|
| 1. Use-case risk tier | Impact and likelihood scored on the framework’s factors | Assess and bound | “It’s low risk, it was only a pilot” | Business owner, risk |
| 2. Action inventory | Every tool and action listed, each tagged auto, approve or never | Assess and bound | Tools added “just in case” | Product owner |
| 3. Agent identity and access | Own identity, named owner, scoped and time-bound least-privilege access | Assess and bound | Runs on a developer’s or shared admin account | IAM, security |
| 4. Human checkpoints | Approval points for irreversible actions; override-rate and review-time reports | Human accountability | Approve-everything queue, or no approvals at all | Process owner |
| 5. Workflow testing | Repeated-run results for task, SOP, tool-call and error handling | Technical controls | Only “the answers looked good” demos | QA, engineering |
| 6. Staged rollout and monitoring | Ring plan; alert rules; halt path; undeletable logs | Technical controls | Big-bang go-live to everyone | Operations |
| 7. Change control | Named triggers and review levels by risk | Technical controls | Model version updates silently | Engineering, risk |
| 8. Personal data | Personal data mapped in tools, memory and logs; overseas processing reviewed | Human accountability, plus PDPA | Agent memory keeps customer data indefinitely | DPO |
| 9. Vendor terms | Security, performance and data protection terms; tool-call logs available | Human accountability | “The platform handles governance” | Procurement, counsel |
| 10. User disclosure and training | Point-of-use notice; escalation contact; reviewer training | End-user responsibility | Disclosure buried in a policy PDF | Business owner |
Gates 1 and 2: tier the use case, then every action
The framework’s risk factors are practical. On impact: does the agent touch sensitive data, reach external systems, write as well as read, and can its actions be undone? On likelihood: how much autonomy does it have, how complex is the task, does a third party run it, and how many agents interact?
Then list every action and tag it. Reading a record or drafting a reply is usually auto. Writing to a system of record is usually approve, at least at first. Actions the framework calls irreversible, such as permanently deleting data, sending communications or making payments, start as approve or never. Remove any tool that is not on the list. IMDA also suggests deterministic, system-level controls for higher-risk actions instead of prompt instructions: block the tool at the access layer rather than asking the model not to use it.
Gate 3: give the agent its own identity
Pilots often run on a developer’s token. The framework says each agent’s identity should be unique, tied to a supervising human or department, recorded according to whether it acts on its own or for a user, and catalogued centrally so you can find and revoke it. Permissions should be scoped, time- or session-bound, non-transferable and least-privilege, and a user should not be able to grant an agent more access than they hold themselves. If your identity platform cannot do that yet, narrow the agent’s scope.
Gate 4: approvals that are not rubber stamps
Human approval only works if people actually read what they approve. The framework names automation bias and alert fatigue, and suggests tracking the human override rate (a low rate may signal rubber-stamping) and reviewer response times (very short times may signal fatigue). Keep approval requests short, with the risk stated. For high-risk actions, ask for a written reason. If the approval system is down, deny by default. For queue sizing and reviewer screens, see our human-in-the-loop design guide.
Gate 5: test the workflow, not just the answer
Agents must be tested across steps, not just on outputs. IMDA lists four things to test: whether the agent completes the task, whether it follows SOPs and routes for approval when required, whether it calls the right tools with the right permissions, inputs and order, and how it handles errors and edge cases. Test in an environment that mirrors production, run the same cases more than once because agent behaviour varies, and include hostile inputs. A document carrying hidden instructions is a realistic test case; our prompt injection checklist covers the patterns.
Gates 6 and 7: roll out in rings, and treat changes as releases
The framework recommends rolling out gradually by users (trained users first), tools (whitelisted tools first) and systems (lower-risk internal systems first). Its GovTech case study shows the pattern: agentic coding assistants went first only to GovTech’s own developers, without external tool connections, on lower-risk systems.
Monitoring needs alert thresholds (attempted unauthorised access, bursts of repeated tool calls), a defined response per alert, up to halting the agent, and logs that cannot be deleted. For change control, IMDA lists triggers: model updates and tool changes, shifts in domain or business context, degraded performance, and regulatory changes. Minor prompt tweaks get light review; model or autonomy changes get a full one. Our AI model change management guide has a release process you can reuse.
Gates 8 and 9: personal data and the vendor in the middle
Agents put personal data in tool results, memory and logs. Map all three. If personal data goes to a model or agent platform outside Singapore, the Transfer Limitation Obligation applies, and PDPC’s Advisory Guidelines on Key Concepts keep that responsibility with you even when a vendor does the processing. The same guidelines require a notifiable breach to be reported to PDPC no later than three calendar days after you determine it is notifiable. PDPC’s cross-border transfer guide covers the transfer options, and our guide to LLM logging and retention under PDPA covers what to keep and for how long.
If you buy the agent, the framework advises covering security, performance guarantees and data protection in the contract, and checking for scoped API keys, per-agent identity tokens and tool-call logs. Where those are missing, scope the use case down or keep sensitive data out.
Gate 10: tell users, and keep their skills
Tell people they are dealing with an agent at the point of interaction, not only in a policy document, and give them a contact if it goes wrong. Train overseers on failure modes such as agents citing outdated policies. The framework also warns about loss of tradecraft: keep enough human practice that staff can take over when the agent stops.
Worked example: an accounts-payable agent at a Singapore distributor
Illustrative scenario, not a client case. A Singapore distributor pilots an agent that reads supplier invoices, matches them to purchase orders in the ERP and prepares a draft payment batch, using an analyst’s login while the analyst checks every step. The matrix changes the production design:
- Tiers: reading invoices and purchase orders is auto; posting a matched invoice to the draft batch is auto with a daily sample review; changing supplier bank details is never; releasing payment stays a human decision.
- Identity: its own service identity, owned by the AP manager, read-only on the supplier master and able to write only to draft batches.
- Testing: a replay of past invoices, including duplicates, credit notes and a fake invoice with hidden instructions, run several times.
- Rollout: one legal entity and SGD invoices first, other entities after a clean month; any attempted write to the supplier master halts the agent.
- Data and vendor: supplier contact names are personal data and the model is hosted overseas, so transfer clauses, breach notice times and log retention are agreed with the vendor.
- Change: any model version change reruns the replay suite before release.
None of this needed a bigger model. It turned “the demo worked” into evidence the board can read.
Decision framework: go, limited go, or not yet
- Go: all ten gates have evidence, and the business owner accepts the residual risk in writing. The framework treats residual risk as a conscious organisational decision.
- Limited go: gates 3, 4, 6 and 8 pass but others are partial. Launch to one ring of trained users, with read-mostly tools and a fixed review date.
- Not yet: no agent identity of its own, no approval on irreversible actions, or no way to stop the agent. Stay in pilot.
- Any change trigger fires: re-run the affected rows before the change ships.
Common mistakes
- Promoting the pilot’s credentials to production.
- Counting clicks as oversight. Measure override rates and review times.
- Testing final answers only.
- Letting the vendor update the model silently. Make model changes a contractual review trigger.
- Treating the IMDA framework as a replacement for the PDPA or MAS expectations.
For build and hosting next to governance, see AI agents in Singapore and the private / VPC LLM deployment questions.
FAQ
Is IMDA’s agentic AI framework mandatory?
No. It is a model framework of recommended practices, not legislation. Your binding duties come from the PDPA and sector rules; the framework organises the controls those duties need.
Does it apply if we use a vendor’s agent rather than building one?
Yes. IMDA says it is for organisations deploying agents, whether built in-house or from third parties, and covers what to ask third-party providers for.
Does every agent action need human approval?
No. The framework notes that continuous human oversight of every workflow becomes impractical at scale. Reserve approvals for high-stakes, irreversible or unusual actions, and back them with automated monitoring.
We are MAS-regulated. What else applies?
MAS’s proposed Guidelines on AI Risk Management cover AI agents and propose a 12-month transition after they are issued. Check MAS for their current status, and bring your technology risk team in early. Our MAS TRM questions for software vendors is a useful companion.
What to do next
Copy the gate matrix, fill it in for your current pilot, and mark a row green only where the evidence exists. If you need help building the identity, approval, testing and monitoring layers around an agent, see our AI agent development for Singapore, AI automation in Singapore and private AI deployment services, or our custom software team. You can also contact us to walk through your pilot.