STIVStrictly speaking, you can't "comply" with IMDA's Model AI Governance Framework for Agentic AI, because it is voluntary. You can align with it. In practice, that means listing every AI agent you run, limiting what each one can do, giving each a named human owner, gating consequential actions behind human approval, and logging agent activity so every decision can be traced. Organisations that do this are in a far stronger position. Under existing laws, they remain accountable for what their agents do either way.
This guide turns the framework into an eight-step checklist, a copy-ready template and a 90-day rollout plan.
Key takeaways
- Voluntary, not optional in spirit. The framework isn't legally binding, but organisations stay accountable for the actions and impacts of their AI systems under existing laws.
- It covers bought agents too. The IMDA framework applies to agents you build in-house and agents you buy from third parties.
- Three core controls: guardrails that check an agent before, during or after it acts; human review or approval of agent actions; and logging and monitoring that make actions traceable.
- Say "aligned with", never "certified". No certification scheme exists for this framework.
- A realistic timeline is about one quarter for a first wave of agents, if you start with an inventory.
What is IMDA's Model AI Governance Framework for Agentic AI?
It is Singapore's guidance on deploying AI agents responsibly. These are systems that don't just generate text. They take actions such as sending emails, updating records or initiating payments.
Timeline
- 22 January 2026: IMDA launched the framework. Minister Josephine Teo announced it at the World Economic Forum in Davos. It builds on the Model AI Governance Framework introduced in 2020.
- 20 May 2026: IMDA updated the framework with industry feedback, new best practices and real-world case studies.
Who it applies to
The framework is aimed at organisations deploying agentic AI, whether they build the agents or buy them. If your business operates in Singapore, it's the reference point regulators, partners and customers will use. That holds even if your headquarters are elsewhere.
Is it mandatory? Why follow it anyway?
No, it isn't mandatory. There are still three good reasons to treat it seriously.
- You're accountable regardless. If an agent mis-sends customer data or approves a wrong payment, data protection, contract and consumer laws still apply. The framework is effectively a blueprint for showing you took reasonable care.
- Buyers and auditors will ask. Enterprise procurement and internal audit teams increasingly want evidence of agent oversight. A documented alignment exercise answers that question once, in a reusable form.
- It travels well. The same controls (inventory, risk tiering, human oversight, logging) underpin other regimes, including the EU AI Act. Work done here is rarely wasted.
The framework's core areas in plain English
When it launched, IMDA invited feedback and case studies on bounding risk, assigning human accountability, technical controls, safety testing, monitoring and end-user responsibility. Those themes map onto the framework's four dimensions. Check the exact wording in the IMDA PDF before you cite them internally.
| Area | Plain-English question | Evidence you should hold |
|---|---|---|
| Bound the risk upfront | What can this agent touch, and what's the worst it could do? | Agent register, risk tier, autonomy limits |
| Keep humans accountable | Who answers for this agent? | Named owner, approval policy |
| Technical controls and testing | What stops it misbehaving? | Guardrails, test results, logs |
| End-user responsibility | Do the people using it understand it? | Disclosures, training records |
Step-by-step checklist
Step 1: List every agent and what it can access
You can't govern what you can't see. Record each agent, its purpose, the systems it connects to, the data it reads and the actions it can take. Include vendor agents and "shadow" pilots.
Step 2: Assess risk and set autonomy limits
Tier each agent by the impact of a wrong action. Drafting an internal summary is low risk. Moving money or committing the company contractually is high. Then cap autonomy to match. An agent should hold the narrowest permissions that let it do its job.
Step 3: Assign a named human owner
Every agent needs one accountable person, not a team alias. That person approves its scope, reviews its incidents and signs off changes.
Step 4: Design approval gates for consequential actions
Decide which actions an agent may take alone and which need a human "yes". A good gate shows the approver what the agent proposes, why, and what data it relied on. One-click approval without context is a rubber stamp, not oversight.
Step 5: Build guardrails and technical controls
IMDA describes guardrails that check behaviour before, during or after an agent acts. Examples include input filters, spending or volume limits, allow-lists of recipients, and automatic halts when confidence drops or anomalies appear.
Step 6: Log everything
The framework recommends logging and monitoring agent actions, decisions and interactions so they can be traced. A minimum audit-log specification:
- Agent ID and version
- Triggering request or event, with timestamp
- Data sources consulted
- Proposed action and rationale
- Approver identity, decision and timestamp (where gated)
- Executed action and outcome
- Any guardrail triggered or override applied
Step 7: Test before deployment, then monitor
Test agents against realistic and adversarial scenarios before go-live. After launch, review logs on a fixed cadence, track exception rates and re-test after any model or prompt change.
Step 8: Tell end users and train them
Staff and customers should know when they're dealing with an agent, what it can do and how to escalate. Approvers need training on what to look for, so their reviews are meaningful.
Template: agent register, risk matrix and approval policy
Copy this into a spreadsheet and fill in one row per agent.
Agent register
| Field | Example |
|---|---|
| Agent name / ID | AP-Reconciler-01 |
| Business owner | Financial Controller |
| Purpose | Match bank lines to ledger entries |
| Systems connected | ERP, bank feed |
| Permitted actions | Propose matches; flag exceptions |
| Prohibited actions | Post journals; release payments |
| Risk tier | High |
| Approval required for | Any ledger write |
| Log retention | Per finance records policy |
| Last tested / reviewed | Date |
Risk-tiering matrix
| Tier | Typical actions | Autonomy | Oversight |
|---|---|---|---|
| Low | Summarise, draft internally, search | Act alone | Periodic log review |
| Medium | Send routine external messages, update CRM fields | Act within limits | Sampling plus alerts |
| High | Move money, sign or amend contracts, change customer entitlements | Propose only | Mandatory human approval |
Approval policy (one paragraph per agent): "[Agent] may [low-risk actions] without approval. It must obtain approval from [role] before [high-risk actions]. Approvers will see the proposed action, rationale and source data. All decisions are logged and reviewed [monthly] by [owner]."
What the controls look like by function
Finance: reconciliations and payments
Let agents match transactions, chase missing documents and draft journals. Keep posting and payment release behind a controller's approval. Logs should tie every proposed entry to its source documents. This is how AI finance automation should behave: faster close, with no unreviewed ledger writes.
Legal: contract review against playbooks
Agents can compare third-party paper against your playbook, flag deviations and suggest fallback clauses. Accepting non-standard terms, or sending redlines to a counterparty, should require a lawyer's sign-off. See how this works in AI contract review.
Sales and support: customer-facing actions
Routine follow-ups and lead qualification can run within tight limits, using approved templates, capped volumes and recipient rules. Discounts, refunds, commitments and anything off-script should route to a human. Customers should be told when they're corresponding with an agent.
Questions to ask an agentic AI vendor
Because the framework covers bought agents, vendor due diligence is part of alignment. Ask:
- Can we restrict each agent's permissions, system by system?
- Where do human approval gates sit, and can we configure them by action type?
- What exactly is logged, and can we export the audit trail?
- Does the agent connect to our existing systems, or must we migrate data?
- How are model or prompt changes tested and communicated?
- Who is accountable when something goes wrong, and how are incidents reported?
STIV AI was designed around these questions. Its division-specific agents connect to existing systems without migration, and every consequential action passes through human approval gates with full audit trails. Whichever vendor you choose, insist on clear answers. Our enterprise AI governance page sets out how we approach it.
A 90-day rollout plan
| Phase | Weeks | Outcomes |
|---|---|---|
| Discover | 1–3 | Complete agent register; assign owners; identify high-risk agents |
| Design | 4–6 | Risk tiers, approval policies, guardrail specs, log specification |
| Implement | 7–10 | Configure gates and logging; test high-risk agents; train approvers |
| Operate | 11–13 | Go live in stages; first log review; document alignment for audit |
After day 90, repeat the cycle quarterly. Review it again whenever IMDA revises its guidance, as it did in May 2026.
The bottom line
IMDA's framework doesn't ask for anything exotic. It asks you to know your agents, limit them, put a person in charge of each, and keep a record. Done well, that is simply good management of a new kind of worker. If you'd like to see how approval gates and audit trails work across finance, legal, sales and operations, book a walkthrough with STIV AI.
Frequently asked questions
Is the IMDA agentic AI framework mandatory or legally binding?
No. The framework is voluntary. Organisations nonetheless remain accountable for the actions and impacts of their AI systems under existing laws, so aligning with it is a practical way to show reasonable care.
When was the IMDA agentic AI framework launched and updated?
IMDA launched it on 22 January 2026, with Minister Josephine Teo announcing it at the World Economic Forum in Davos. It was updated on 20 May 2026 with industry feedback, new best practices and real-world case studies.
Does the framework apply to AI agents bought from vendors?
Yes. It covers agents built in-house and agents bought from third parties. That makes vendor due diligence, especially on permissions, approval gates and audit logs, part of aligning with it.
What does a human approval gate look like in practice?
The agent proposes a consequential action, such as a payment or contract change, and a named human reviews the proposal, rationale and source data before it executes. The decision and approver are logged for audit.
What should AI agents log for an audit trail?
At minimum, log the agent ID and version, the trigger, the data consulted, the proposed action and rationale, the approver decision, the executed outcome and any guardrail triggered. This makes every action traceable, as the framework recommends.
Can a company be certified compliant with the IMDA agentic AI framework?
No certification scheme exists for this framework. Organisations should describe their practices as aligned with it and keep documentation, such as an agent register, approval policies and logs, as evidence.