Singapore's Agentic AI Framework Just Reshaped Your Compliance Roadmap. Here's What to Do Before Your Next Audit.

On 20 May 2026, Singapore's Infocomm Media Development Authority (IMDA) published version 1.5 of the Model AI Governance Framework for Agentic AI — the first government-issued governance framework written specifically for AI systems that plan, call tools, and act over multiple steps with varying autonomy. More than sixty organisations including OCBC, PwC, Tencent, Workday, Ant International, and Google contributed feedback to v1.5, and the document arrived with the kind of cross-industry weight that voluntary guidance usually has to earn over years. If you run a SOC 2, HIPAA, or HITRUST programme at a SaaS company, a healthcare-technology firm, or a regulated mid-market organisation, this framework now sits on your desk whether you went looking for it or not.

The reason this lands on the compliance officer's desk — and not only the engineering team's — is that the framework is built around audit evidence, not architecture. The four dimensions IMDA defines are control-shaped: risk assessment upfront, human accountability, technical controls and processes, and end-user responsibility. Each one produces artifacts that map cleanly onto the categories your auditors already ask about. Customers reviewing your vendor security questionnaire will start citing the framework this year. EU AI Act conformity assessments already reference it as a touchstone for high-risk and general-purpose AI systems. National AI strategies in the United Kingdom, Canada, and Japan are quietly aligning to it. Voluntary guidance is doing the work of de facto regulation in 2026, and your team will be asked to evidence alignment long before anyone in Singapore publishes a binding rule.

This post is the compliance-officer's take on what the framework means in practice. We cover what to put on your audit calendar, where your existing programme already covers you, where the genuinely new asks sit, and what belongs on the next 90 days of your risk register. Where the engineering build side matters — agent architecture, identity scoping, evaluation pipelines — we defer to colleagues who specialise in that and cross-link at the end. Our focus here is what your auditors and your customers are about to start asking for, and how to be ready.

The Four Dimensions, in Compliance Language

IMDA frames the work in four dimensions that an organisation iterates through — not a one-time gate. For a compliance officer, the useful translation is to ask what artifact each dimension expects you to produce and present. The engineering depth lives elsewhere; here we are after the evidence package. We have organised this against the language your SOC 2, HIPAA, and HITRUST examiners already use, so the lift from your current programme is incremental rather than net-new.

Dimension 1: Risk Assessment Upfront

IMDA's ask is that organisations identify and bound the risks of an agentic system before deployment, including the data the agent can reach, the actions it can take, and the autonomy level under which it operates. The audit evidence a compliance officer should expect to produce is a risk-register entry that treats the agentic system as a discrete asset with its own risk profile, an AI system inventory that captures autonomy tier and data scope, and a threshold-documentation artifact showing how your team decided which agentic uses required additional controls versus which fell within existing tolerances. This maps directly onto the risk-analysis cadence your HIPAA Security Rule programme already runs under §164.308(a)(1), and onto the risk-assessment evidence SOC 2 examiners look for under CC3.x. If your existing risk register has rows for SaaS vendors, network changes, and infrastructure migrations, an "agentic AI in scope" row belongs alongside them.

Dimension 2: Human Accountability

IMDA's ask is that organisations make humans meaningfully accountable for the agent's actions — not nominally, but with named owners, defined oversight responsibilities, and escalation criteria. The audit evidence is a RACI matrix for agent oversight, a set of human-in-the-loop SOPs covering when an agent must pause for review and how that review is logged, and documented escalation criteria so that when an agent flags an edge case the route to a qualified human reviewer is unambiguous. This is squarely in the territory of SOC 2 Common Criteria CC1.x — control environment, organisational accountability, defined roles and responsibilities. Your existing accountability framework already covers system owners, security incident commanders, and change-management approvers. Adding agent identities and agent-action approvers to that framework is an extension of work you have done, not a rebuild.

Dimension 3: Technical Controls and Processes

IMDA's ask is that organisations implement the technical and procedural controls that bound agent behaviour: access controls on the tools the agent can call, monitoring of agent activity, change management when agent capabilities are updated, and logging that supports after-the-fact review. The audit evidence is a control matrix that maps each agentic system to the SOC 2 Common Criteria you already evidence — CC6.x logical access, CC7.x system operations and monitoring, CC8.x change management. Alongside the control matrix, examiners will want system architecture diagrams showing where the agent sits in your data flow, and change-management logs that capture both code changes and agent-configuration changes — including prompt updates, tool grants, and autonomy-tier changes.

NIST AI RMF's Measure and Manage functions overlap heavily here, and HITRUST CSF 09.x communications and operations management catches most of the operational-controls scope as well. The engineering depth — exactly how to architect identity, evaluation, and observability for agents — is exactly what our AI services division at TrustEdge has written up, and we cross-link to their engineering guide in the closer. Your job as compliance officer is to know what evidence to ask the engineering team to produce, not to design the technical implementation.

Dimension 4: End-User Responsibility

IMDA's ask is that organisations equip the people interacting with agentic systems — employees, customers, downstream users — to use them responsibly, with clear notice, training, and policy guardrails. The audit evidence is an AI Use Policy that addresses agent-specific behaviour (not just generative-AI behaviour), training records showing that staff who interact with agents have been instructed on appropriate use and escalation, and notice-and-disclosure logs that capture where and how end users were informed that an agent was involved in a decision or workflow. HITRUST CSF awareness-and-training categories absorb most of this. HIPAA §164.308(a)(5) workforce training is a natural home for the agent-specific training records. Customer-facing notice-and-disclosure mirrors the contractual transparency requirements you already manage under your privacy programme.

Read across the four dimensions and a pattern emerges: most of the artifacts IMDA expects already live in mature SOC 2, HIPAA, and HITRUST programmes — under different names, against different control IDs, but conceptually intact. The next section walks through where that overlap is sharpest and where you can move quickly with the work you have already done.

Where This Overlaps With What You Already Do

The encouraging news for any compliance officer reading the framework cold is that you are not starting from zero. Mature programmes built around SOC 2, HIPAA, HITRUST, and NIST AI RMF cover a significant share of what IMDA expects — often with evidence that can be re-tagged rather than re-produced. Below are the highest-leverage overlaps your team can act on this quarter.

SOC 2 Common Criteria CC1.x (Control Environment) ↔ IMDA Dimension 2 (Human Accountability). Your SOC 2 evidence for CC1.1 through CC1.5 already covers most of what IMDA expects under human accountability — board oversight, defined roles, documented responsibilities, ethical-conduct standards. Extending that framework to include named agent owners, oversight approvers, and escalation paths for agent-flagged decisions is incremental. Add agent identity and oversight roles to your existing accountability framework rather than building a parallel structure.

SOC 2 Common Criteria CC7.x (System Operations) ↔ IMDA Dimension 3 (Technical Controls + Monitoring). CC7.1 through CC7.5 already require continuous monitoring, change detection, incident response, and recovery for production systems. Bring agentic systems explicitly into scope — Datadog or AWS GuardDuty alerting on anomalous agent behaviour, PagerDuty routing for agent incidents, change-management coverage of agent configuration — and most of the dimension-3 evidence is already being produced.

HIPAA §164.308(a)(1) Risk Analysis ↔ IMDA Dimension 1 (Risk Assessment Upfront). The HIPAA-mandated risk analysis cadence is the natural home for agentic AI risk evaluation. If a coding assistant has been granted access to a repository that contains PHI, or if a customer-service agent reads from a system that carries PHI, the agent belongs in the §164.308(a)(1) Risk Analysis and the §164.308(a)(8) Evaluation. The artifact already exists; the scope simply needs to expand.

HITRUST CSF 09.x (Communications and Operations Management) ↔ IMDA Dimensions 3 and 4. The HITRUST control family covering operations procedures, third-party service delivery, system planning, and monitoring overlaps heavily with both the technical-controls dimension and the end-user-responsibility dimension. Your HITRUST evidence for 09.aa (audit logging) is the audit-log evidence IMDA expects for agent activity. Your evidence for 09.j (controls against malicious and mobile code) extends naturally to agentic tool-call governance.

NIST AI RMF Govern function ↔ IMDA Dimension 2 + Organisational Accountability across all four. The Govern function of NIST AI RMF was written to overlap with international frameworks like the IMDA model. If your team has already begun an AI RMF Govern adoption, the four-dimension structure of IMDA reads as a Singapore-flavoured restatement of the same accountability and risk-management posture. Map your AI RMF Govern artifacts to the four dimensions and you have a defensible crosswalk for any vendor questionnaire or audit conversation.

Our AI services division at TrustEdge maintains a full control-mapping table for the framework — every IMDA expectation cross-walked to NIST AI RMF, ISO 42001, SOC 2, and HIPAA. We defer to that table for the comprehensive crosswalk and cross-link to it in the closer. Here we wanted to highlight the highest-leverage overlaps your compliance team can move on immediately, with the evidence you already produce.

Where the Gaps Are

The harder part of the framework is the work that mature compliance programmes typically do not have yet. These are the asks that will keep surfacing on customer questionnaires and in vendor due diligence, and they are where most of the next quarter's compliance work should concentrate. We have walked through four genuinely-new controls below — for each, the concept in plain language, the compliance officer's first move, and why it is not covered by what your existing programme already produces.

1. Agent identity management at the IAM layer, not the service-account layer. Today's pattern is to give an agent a service account, often with broad permissions, and to log its activity under a single shared identity. IMDA asks for something closer to how you treat human principals: discrete identities for each agent, scoped permissions matched to its job function, and revocability the moment behaviour goes sideways. The compliance officer's first move is not to implement this — it is to ask your engineering team three questions: how many agent identities exist in production today, are they distinct from human and service-account identities, and what is the time-to-revoke if an agent misbehaves? Bring the answers back to the risk register. This is net-new because SOC 2 CC6.x is currently satisfied by service-account governance, and few HIPAA programmes treat agents as distinct workforce-equivalent principals subject to §164.308(a)(3) workforce-access management. The framework treats them that way, and your auditors will follow.

2. Multi-agent emergent-behaviour testing in the evaluation cycle. The evaluation work most teams currently do — if they do it at all — is single-agent unit testing — does this agent answer this question correctly? IMDA's expectation is that you also test what happens when agents interact, when one agent calls another, when recursion limits are tested, when chains of agents produce outcomes that no single agent intended. The compliance officer's first move is to add a row to the risk register labelled "multi-agent emergent behaviour" with a status of "not yet evaluated" if that is the truth, and to ask your engineering team for a test plan and a cadence. This is net-new because SOC 2, HIPAA, and HITRUST do not currently require any equivalent — single-system testing has always been the implicit standard, and emergent-behaviour testing is a category most evaluation suites simply do not contemplate.

3. Automation-bias monitoring of human reviewers. Where IMDA expects a human-in-the-loop control — and where SOC 2 examiners increasingly expect to see one for AI-assisted decisions — the implicit assumption is that the human is actually reviewing the agent's recommendation rather than rubber-stamping it. Automation bias is well-documented: the more often an agent is right, the less critically humans review its outputs. IMDA asks you to measure this. The compliance officer's first move is to ask whether the systems flagging items for human review also capture how long the human spent reviewing, what percentage of items the human modified versus accepted, and whether there is a sampling-based audit of human-reviewer accuracy. If none of those measurements exist today, the gap is real. This is net-new because SOC 2 CC4.x monitoring activities currently cover control operation, not control effectiveness in the human-judgement sense, and no existing HIPAA or HITRUST control explicitly asks you to evidence that your humans are actually engaging with the AI outputs they sign off on.

4. Tradecraft retention plans. As agents absorb routine work — Microsoft Copilot drafting policy language, Cursor or Cline writing boilerplate code, ServiceNow Now Assist handling tier-1 support tickets, Glean answering internal knowledge questions, Salesforce Einstein generating account briefings — the underlying human skill that the agent is replacing atrophies. When the agent fails or behaves unexpectedly, you need humans who can still debug, audit, or take over manually. IMDA asks you to plan for that. The compliance officer's first move is to identify the workflows most heavily delegated to agents in your environment, ask the responsible function leaders whether the team retains the underlying skill to perform that workflow without the agent, and capture a tradecraft retention plan as part of your operational-resilience programme. This is net-new because no existing compliance framework asks the resilience question in this form — disaster-recovery and business-continuity controls assume the technology can fail, not that the humans can lose the underlying capability.

The four gaps above are the work that will differentiate compliance programmes that absorb the framework smoothly from those that are forced to play catch-up under customer pressure. None of them require waiting for a binding regulation. All of them can begin with conversations between your compliance lead and your engineering, security, and operations leaders this quarter.

The Vendor-Risk Angle

The other reason this framework should be on your desk right now is that your customers will start including agentic-AI questions in their vendor security questionnaires this year, and you will start asking the same questions of your own vendors. The framework provides the vocabulary both directions of that conversation will use. The teams that have ready answers will close enterprise deals faster, and the teams that do not will find their renewal cycles getting more uncomfortable.

Concretely, expect to see questions like these arrive in 2026:

• Do any of your systems include autonomous AI agents that take actions on customer data without per-action human approval?
• How do you authenticate AI agents that access customer data, and are agent identities distinct from human and service-account identities?
• What evaluation framework do you use to detect agent misbehaviour, hallucination, or unintended action chains?
• Have you mapped your AI systems to a named governance framework (NIST AI RMF, IMDA, ISO 42001, EU AI Act)?
• What is your incident response process when an agent takes an unintended action on customer data?

The mirror of that conversation is what your team will start asking of your own vendors — Microsoft Copilot, Salesforce Einstein, ServiceNow Now Assist, Notion AI, Glean, Datadog's AI-assisted alerting, the agent-mode features showing up in tools you already license. Each of those products is shipping agentic capability faster than vendor risk programmes are scoping it. Your vendor due-diligence questionnaire should be growing a section on agentic-AI behaviour: tier of autonomy, data residency, evaluation evidence, incident-notification commitments, and the vendor's own conformity claims against named frameworks. Our AI services division at TrustEdge has published an engineering vendor-diligence questionnaire that you can adapt — its technical depth is more than most compliance teams will use line-for-line, but the structure transfers directly into your own vendor-risk template.

The pragmatic posture for the next twelve months is to build the evidence before you are asked. Answer the questionnaire you expect to receive — write down which agentic systems are in scope, who owns them, what controls you have, what evaluation you run, what your incident process looks like — and store the answers where your sales engineering and customer success teams can pull from them when an RFP arrives. Compliance teams that build this evidence proactively close enterprise deals weeks faster than teams that scramble to assemble it under deal pressure. The framework gives you the structure; the work is gathering and writing.

What to Do in the Next 90 Days

Below is a concrete checklist your team can move on this quarter. None of these actions require a binding regulation, a new tool purchase, or a budget cycle — they require conversations with the right people and a few well-placed entries in the artifacts your compliance programme already maintains. We have framed each as the WHAT and the WHY so you can prioritise without rereading the framework.

1. Identify which agentic AI systems are in your environment. Almost always more than the security team initially thinks. Coding assistants (Microsoft Copilot, Cursor, Cline), customer-service bots (Intercom Fin, Salesforce Einstein agents), browser copilots, RAG implementations with agentic retrieval, and agent-mode features baked into Microsoft 365, Salesforce, ServiceNow, Notion AI, and Glean all qualify. Ask each functional area what they are running, not just IT — finance, sales, and HR have often onboarded agents without going through procurement. Without an inventory, you cannot evidence anything else.

2. Add "agentic AI" as a category to your risk register and risk assessment. Treat the class as a control gap until proven otherwise rather than evaluating every agent as a separate risk. Once you have the inventory, individual agents become rows within the category. This single act anchors the rest of the work and gives your auditors a clear starting point in your next examination.

3. Update your AI Use Policy to address agent-specific behaviour. Most existing AI Use Policies are written for generative AI — chat, draft, summarise — and silent on agents that take action. Cover agent inventory and registration, autonomy-tier classification (assist, suggest, act-with-approval, autonomous), permitted data scopes by tier, human-in-the-loop requirements by tier, prohibited tool combinations, and vendor onboarding gates. Sample policy language exists in our AI services division at TrustEdge's engineering guide (Section 11) for adaptation.

4. For HIPAA-covered entities, re-evaluate your §164.308(a)(1) Risk Analysis and §164.308(a)(8) Evaluation to include agentic systems explicitly. The Risk Analysis must address any system that creates, receives, maintains, or transmits ePHI — and a coding assistant with repository access or a customer-service agent reading from PHI-bearing systems clearly qualifies. The Evaluation cadence is the natural moment to bring agentic systems formally into scope rather than waiting for a security event to force the conversation.

5. For SOC 2, prepare to evidence agent identity controls, tool-layer access controls, and human oversight in your next examination. Talk to your auditor ahead of time about how they intend to test agentic systems against CC1.x, CC6.x, CC7.x, and CC8.x. Examiners are still developing their own posture on agentic AI, and a proactive conversation now is a better path than a surprise finding in the management response window.

6. For HITRUST, incorporate agentic systems into your assessment scope before your next interim — do not wait for the full re-cert. Adding agentic-AI scope mid-cycle is significantly less disruptive than discovering at re-certification time that an entire control family has been missing scope. HITRUST Certified Assessors (we are one) can advise on the scoping decision and what evidence will satisfy your authorised external assessor at the next interim.

None of these six actions require waiting for binding regulation, vendor maturity, or budget approval. All of them set up the work that will let your team answer customer questionnaires with confidence, present clean audit evidence at your next examination, and bring agentic AI into your compliance posture as part of the normal cadence rather than as a crisis project.

How Jacobian Can Help

If your team is looking at the framework and the 90-day checklist and thinking "we know we have agentic AI in scope, we need someone to help us prove it to our auditors and our customers" — that is exactly the work we do. Jacobian Engineering has been helping growing SaaS companies, healthcare-technology firms, and regulated mid-market organisations stand up and evidence compliance programmes since 2005. We are an employee-owned, HITRUST Certified Assessor with the audit experience to know what your examiners will ask for and the operational depth to help your team produce it.

Our compliance assessment and managed-services teams can map your current SOC 2, HIPAA, or HITRUST programme against the four IMDA dimensions, identify the artifacts you already produce, surface the genuinely-new gaps, and stand up the controls that will close them. Our AI Model Risk Management practice brings the same posture to AI-specific governance work — NIST AI RMF adoption, agent inventory, AI Use Policy authoring, and vendor-questionnaire response support.

Book a Free Assessment and we will spend an hour with your team — no slides, no pitch — walking your current programme against the framework. You can reach us at (415) 644-8208 or through the contact form. Compliance is the door that enables AI deployment, and we work as your partner to open it.

For the Engineering Side: Cross-Links to Our AI Services Division

This post deliberately stays in the compliance lane — audit evidence, risk-register entries, programme-level controls. For the engineering side of the framework — how to actually build agentic systems that satisfy IMDA's expectations, including architecture patterns, agent identity implementation, evaluation pipelines, observability, and sample policy language — our AI services division at TrustEdge has published the companion material that goes deep on the technical detail this post intentionally skips.

Three resources worth bookmarking:

• Building Agentic AI Systems Aligned With Singapore's IMDA Framework — the practitioner build-spec covering the four dimensions from the engineering side.
• Implementing Agentic AI Within the IMDA Framework — Engineering Guide — the full 4,800-word engineering playbook covering architecture, identity, tools, evaluations, observability, sample policy language, and the vendor diligence questionnaire we reference above.
• Singapore IMDA Agentic AI Framework — Regulations Hub — the framework summary, applicability checklist, FAQ, control mapping to NIST AI RMF / ISO 42001 / SOC 2 / HIPAA, quick-start steps, and PDF download.

For the compliance side — programme design, audit preparation, evidence production, vendor-questionnaire support — talk to us at SOC 2, HIPAA, or AI Model Risk Management. The two sides reinforce each other, and the teams that get both right will be ready when the questionnaires start arriving.