Frequently asked questions about the Singapore MGF for Agentic AI

The FAQ gives short information and refers to the sections with the full information and sources.

Disclaimer

This page gives general information. It is not legal advice.

What is the Singapore IMDA Model AI Governance Framework for Agentic AI?

The Model AI Governance Framework for Agentic AI (MGF for Agentic AI) is voluntary guidance from the Infocomm Media Development Authority (IMDA) of Singapore. It is for organizations that want to deploy agentic AI. It is not law.

• The MGF is for organizations that make AI agents and for organizations that use "third-party agentic solutions" (Executive Summary).
• This page uses Version 1.5. The first page of Version 1.5 gives the dates "Published 20 May 2026" and "Updated 5 June 2026". IMDA identifies the MGF as "a living document" (Annex B).
• The MGF has four dimensions (§2).

See The MGF.

Is the MGF for Agentic AI mandatory or voluntary?

The MGF for Agentic AI is voluntary guidance. It is not law. It sets no obligations in law. It gives "emerging best practices to address new concerns from agentic AI" (§2). The IMDA press release of 20 May 2026 tells organizations that the MGF "provides guidance to organisations on how to deploy agents responsibly, recommending technical and non-technical measures to mitigate risks" (¶1).

This item is about the MGF only. The MGF does not tell organizations which other laws of Singapore apply to an agent.

See The MGF.

What are the four dimensions of the MGF for Agentic AI?

The MGF for Agentic AI has four dimensions (§2):

1. "Assess and bound the risks upfront" (§2.1)
2. "Make humans meaningfully accountable" (§2.2)
3. "Implement technical controls and processes" (§2.3)
4. "Enable end-user responsibility" (§2.4)

The MGF recommends an "iterative process": after anomalies during "implementation or monitoring", organizations "should re-evaluate the earlier dimensions, re-assessing and further bounding the risks if needed" (§2).

See The four dimensions of the framework and Risk assessment before development or deployment.

What changed in version 1.5 of the framework?

In Version 1.5, the Infocomm Media Development Authority (IMDA) added guidance for organizations ("What's new in this version"):

• Controls, and logging and monitoring, as agent components, and "newer protocols" (§1.1.1).
• Systemic and multi-agent risks (§1.2.3).
• New risk factors, for example system complexity and the use of "third-party solutions" (§2.1.1).
• Platform providers as a role that is different from system providers or app developers (§2.2.1), and more methods against automation bias (§2.2.2).
• The types of controls (§2.3.1), and change management (§2.3.3).
• The "loss of tradecraft" and its effect on business continuity (§2.4.3).
• Case studies, and an IMDA case study about OpenClaw (§2).

Case studies show examples for one deployment.

See Changes in Version 1.5.

How does the agentic MGF relate to the original MGF and other AI frameworks?

The MGF for Agentic AI "builds on the responsible AI practices for organisations set out in MGF (2020)", the "Model AI Governance Framework (2nd Ed)" (§2). It also refers to the OpenClaw case study (§2) and other testing guidance (§2.3.2).

Other Singapore documents, different from the MGF, give related guidance. Each document identifies its effect:

• The Cyber Security Agency of Singapore (CSA), addendum "Securing Agentic AI": "not mandatory, prescriptive nor exhaustive".
• The Personal Data Protection Commission (PDPC), Advisory Guidelines on Use of Personal Data in Generative AI: "not legally binding".
• The Infocomm Media Development Authority (IMDA), Transparency Guidelines for Generative AI Chatbots: "are voluntary".
• The Monetary Authority of Singapore (MAS), Safeguards for Agentic Finance at Runtime (SAFR): "does not constitute regulatory guidance or supervisory expectations".

See Related guidance. To compare AI governance frameworks, see Comparison.

What counts as agentic AI under the Singapore framework?

The MGF for Agentic AI tells organizations that "there is no consensus on what defines an AI agent" (§1.1). It is about "agents built on generative AI models" (§1.1).

• Agents "usually possess some degree of independent planning, decision-making, and action-taking" "over multiple steps to achieve a user-defined goal".
• An agentic AI system is a software system with one or more AI agents. These agents "may operate individually or collaboratively".
• Usually, such an agent uses a small language model (SLM), a large language model (LLM), or a multimodal large language model (MLLM). There are also other types of agents, for example agents that use deterministic rules or "other neural networks".

See Agentic AI.

What are the core components of an AI agent under the MGF?

The MGF for Agentic AI gives eight "Core components of an agent", in three groups (§1.1.1):

• Components 1 to 3 — the model, the instructions, and the memory. A "simple LLM-based app", which uses a large language model (LLM), also has these components. An agent uses them "in similar ways".
• Components 4 to 6 — planning and reasoning, tools, and protocols. Examples of protocols are the Model Context Protocol (MCP), for communication between agents and tools, and the Agent2Agent Protocol (A2A), for communication between agents.
• Components 7 and 8 — controls, and logging and monitoring. These are "components for safe and reliable performance". The controls include access controls, guardrails, and human approvals.

See Agent components.

What is the difference between action-space and autonomy?

The MGF for Agentic AI gives organizations "two concepts" (§1.1.3): action-space is the "Range of actions the agent can take", and autonomy is the "Degree to which an agent can decide how to act".

Tools and permissions set action-space. Instructions and human involvement set autonomy.

The MGF gives two levels of instructions: "Detailed instructions and SOP", and "Using its own judgment". SOPs are standard operating procedures. The MGF also tells organizations: "In enterprise deployments, most agentic implementations are hybrid systems combining deterministic rules with some autonomy." The MGF does not include "hybrid systems" in the two levels of instructions.

Read access is different from write access, and computer use agents have "access to a computer and browser" (§1.1.3).

See Action-space and autonomy.

What levels of human involvement does the MGF describe?

The MGF for Agentic AI gives four levels of human involvement in agent actions (§1.1.3):

1. "Agent proposes, human operates": "The human reviews and approves every agent action."
2. "Agent and human collaborate": the agent "requires human approval at significant steps", and the person "can intervene anytime".
3. "Agent operates, human approves": the agent "requires human approval only at critical steps or failures".
4. "Agent operates, human observes": the agent "does not require human approval", but "its actions may be audited after the fact".

The MGF does not tell organizations to use one level for all agents.

See Human approval. For the points at which an organization gets human approval (§2.2.2), see Human approval (Dimension 2).

What multi-agent architectures does the MGF recommend?

The MGF for Agentic AI does not recommend one design pattern. It gives "Three simple design patterns for multi-agent systems" (§1.1.2):

• Sequential — the agents work one after the other. The output of each agent is the input of the next agent.
• Supervisor — "One supervising agent coordinates specialised agents under it".
• Swarm — the agents work at the same time. An agent gives the work to a different agent when it is necessary.

The MGF tells organizations: "There is no universally correct architecture for a multi-agent setup, and the task at hand can require different or hybrid patterns" (§1.1.2). The three design patterns are examples.

See Multi-agent systems.

What risks does agentic AI introduce?

The MGF for Agentic AI gives organizations five types of risk from agent actions (§1.2.2):

• "Erroneous actions".
• "Unauthorised actions": actions "outside its permitted scope or authority". An example is an action without human approval when an "explicit human instruction, a company policy, or standard operating procedures" makes human approval necessary.
• "Biased or unfair actions".
• "Data breaches": agents "can not only leak but also wrongly modify data".
• "Disruption to connected systems".

"The risks themselves are familiar" (§1.2.1). Agents "inherit traditional software vulnerabilities (such as SQL injection) and LLM-specific risks", where LLM is a large language model. These risks can occur in the planning, the tools, or the protocols of an agent (§1.2.1).

See Agent risks.

What are systemic and multi-agent risks?

The MGF for Agentic AI identifies risks from agent speed and interactions (§1.2.3):

• Because of agent speed, human oversight in real time is not always easy. Human oversight at all times can cause automation bias and alert fatigue.
• An error can "propagate and amplify across later steps". Multi-agent systems increase these risks.
• Possible risks include agent sprawl, miscoordination, conflict, collusion, and emergent behaviors.
• "The extent to which multi-agent systems introduce qualitatively different risks is still being studied".
• When agents operate across systems or organizations, results are "more difficult to test for and anticipate", "especially if an organisation does not have white-box access to these external systems".

See Systemic and multi-agent risks.

When should an organization assess whether an agentic use case is suitable?

The MGF for Agentic AI recommends a risk assessment "When considering if an agentic use case is suitable for development or deployment" (§2.1.1). It recommends that the organization first "identify and assess the risk against the benefits". This applies to agents that the organization makes and to "third-party agentic solutions" (Executive Summary).

• "Not all use cases are suitable for agents, and some may be better served by deterministic workflows" (§2.1.1).
• After anomalies during "implementation or monitoring", organizations "should re-evaluate the earlier dimensions, re-assessing and further bounding the risks if needed" (§2).

See Risk assessment before development or deployment.

Which factors determine agentic AI risk?

The MGF for Agentic AI gives "non-exhaustive" risk factors for impact and for likelihood (§2.1.1). It identifies risk as "a function of likelihood" and impact, but it does not tell organizations how to calculate the risk.

• Impact — "domain" and use case, sensitive data access, external system access, range of actions, and reversibility. Persistent memory increases sensitive data risks.
• Likelihood — the level of autonomy, task complexity, access to external systems, an agent that an external party supplies or operates, and system complexity.

These risk factors are different from the five types of risk in §1.2.2. The MGF gives no numbers and no limit values for these risk factors.

See Impact and likelihood.

How should organizations bound an agent's authority?

The MGF for Agentic AI tells organizations to "consider defining limits" on agents (§2.1.2):

• Access to tools and systems — least-privilege policies.
• Autonomy — "For process-driven tasks", standard operating procedures (SOPs) that the agent "is constrained to follow".
• Area of impact — mechanisms and procedures "to take agents offline and limit their potential scope of impact when they malfunction". An example is "self-contained environments", "particularly" for high-risk tasks such as code execution.

The MGF recommends deterministic limits, and more monitoring or human-in-the-loop review for "non-deterministic or less reliable" limits (§2.1.2). For risks that "are harder to define through fixed rules, model-based safeguards can be most effective" (§2.3.1).

See Limits on agents and Structural controls.

How do agent identity and delegated permissions work under the MGF?

The MGF for Agentic AI gives organizations agent identity and authorization measures to "consider" in the "interim" (§2.1.2):

• Agent identity: "unique, cryptographically verifiable", with "a supervising agent, a human user, or an organisational department", recorded capacity, and a central agent catalog.
• Authorizations "should generally be scoped, time- or session-bound, non-transferable", with least privilege and "explicit escalation paths for elevated permissions".
• Permissions: "pre-defined" by role or task, set "dynamically" by the human user, or the two together.

The MGF gives this "rule of thumb": the human user "should not be able to set permissions for the agent greater than" that user's permissions. The MGF recommends clear records of these delegations of authority.

See Agent identity and authorization.

Why does the MGF recommend a central agent catalog?

The MGF for Agentic AI recommends one system for all agent identities and permissions, to prevent agent sprawl: "all agent identities (and their attendant permissions) should be issued from and tracked by a centralised system" (§2.1.2). Agent sprawl is "the uncontrolled proliferation of AI agents without centralised management" (§1.2.3).

With this system, an organization can keep a record of its deployed agents, find anomalies, and remove agent identities that are not necessary (§2.1.2).

See Central agent catalog.

What is taint tracing, and how does it relate to threat modeling?

The MGF for Agentic AI tells organizations that taint tracing follows "untrusted data" through agent workflows (§2.1.1). It is "often useful" for "very complex" systems.

• Threat modeling identifies the methods to "compromise the system", and it adds to the risk assessment.
• The risk assessment continues. Thus, the MGF recommends that organizations keep the threat model up to date at regular intervals.
• For the methods, organizations "may refer to" "CSA's Draft Addendum on Securing Agentic AI". CSA is the Cyber Security Agency of Singapore.
• The MGF does not tell organizations to make a specified record of threat modeling or taint tracing.

See Threat modeling and taint tracing.

Who decides whether residual agentic risk is acceptable?

The MGF for Agentic AI recommends that the organization makes the decision if residual risk is "of a tolerable level and can be accepted" (§2.1.2).

• Residual risk is "the risk that remains after mitigation measures have been applied". The MGF tells organizations that "there will always be a level of risk remaining" (§2.1.2).
• The MGF gives no limit value and no specified record for this decision.
• Modulos has no function that records a decision to accept residual risk. The organization makes the decision.

See Residual risk and Work not held in Modulos.

Who is accountable when an agent acts: the deployer, developer, or end user?

The MGF for Agentic AI keeps accountability with organizations that deploy agents and persons with human oversight (§2.2). This voluntary guidance does not set liability in law.

• The agent value chain has six roles: model developers, tooling providers, platform providers, system providers or app developers, the deployer, and end users (§2.2.1).
• One organization can have "multiple overlapping roles", for example the role of the system provider and the role of the deployer (§2.2.1).
• The MGF adds that "human accountability also extends to these users" (§2.4). The accountability of the organization continues. The MGF recommends information for end users, and education and training for users who integrate agents.

See Human accountability and Agent value chain.

How should responsibility be allocated across the agentic AI value chain?

The MGF for Agentic AI recommends that organizations "consider" who does each task in the organization and across the agent value chain (§2.2.1).

• One organization can have more than one role in the agent value chain.
• The internal teams and their tasks are examples: key decision makers, product teams, cybersecurity teams, and users.
• "All teams involved in agentic AI should also develop internal capabilities to understand the technology."
• With external parties, organizations "should consider provisions on security arrangements, performance guarantees, or data protection". "Where there are gaps, the organisation should reassess if the agentic deployment meets its risk tolerance."

See Agent value chain, Teams and accountability, and Contracts and external agents.

When should an agent action require human approval?

The MGF for Agentic AI recommends "significant checkpoints" for human approval, "especially before sensitive actions are executed" (§2.2.2). The examples are "High-stakes actions and decisions", "Irreversible actions", "Outlier or atypical behaviour", and "User-defined" limits. For the last example, "users may be given the option to define their own boundaries".

For approval requests, the MGF recommends that organizations "keep the request short and clear", with risk data or "a confidence score" (§2.2.2). For "straightforward actions", the human user "can simply approve or reject". For "more complex cases", "it may be more productive for the human to edit the plan". For "high-risk actions", "human users can be required to provide an additional written justification".

See Human approval and Approval requests.

What is automation bias, and how can human oversight remain effective?

The MGF for Agentic AI identifies automation bias as "the tendency to over-trust an automated system" "especially when it has performed reliably in the past" (§2.2). The MGF recommends that organizations "implement measures to ensure continued effectiveness of human oversight, particularly as humans remain susceptible to alert fatigue and automation bias and may be influenced by anthropomorphic design" (§2.2.2). These measures "can include":

• Regular audits (§2.2.2). For example, a low "Human override rate" "may signal" a problem. The MGF gives no limit values. See Check human oversight.
• Training of human overseers on "common failure modes". Chain-of-thought reasoning "may not be a faithful explanation of the agent's actions".
• Persons with "the domain expertise to evaluate agent actions".

Also, "human oversight should be complemented with automated real-time monitoring" (§2.2.2). An example is "Denying action by default when approval infrastructures fail".

See Human oversight.

How often should agents be red-teamed?

The MGF for Agentic AI gives no schedule for red teaming. In its example of internal teams, the "Key responsibilities" of cybersecurity teams "can include" "Conducting regular red teaming and threat modelling" (§2.2.1).

• The risk assessment continues. Thus, the MGF recommends that organizations keep the threat model up to date at regular intervals (§2.1.1).
• The MGF recommends tests before deployment (§2.3.2). After deployment, it also recommends that organizations "continuously test the agentic system" (§2.3.3).
• The MGF does not tell organizations to make a specified record of red teaming or threat modeling.

See Red teaming and threat modeling and Test agent workflows before deployment.

What should organizations check when using third-party agents?

For external parties, the MGF for Agentic AI recommends (§2.2.1):

• Contracts. The MGF recommends clear "distribution of obligations". Organizations "should consider provisions on security arrangements, performance guarantees, or data protection". With "gaps", the MGF recommends that organizations examine the deployment again against risk tolerance.
• "Third-party opacity". Organizations "should take steps to maintain sufficient security and control". Examples are transparency about "agent capabilities and data handling practices", and checks of "technical security and control features".

If these "features are lacking", organizations "should consider alternative or in-house solutions, or scoping down the agentic use case" (§2.2.1).

See Contracts and external agents.

Which technical controls does an agent need beyond a normal LLM application?

The MGF for Agentic AI tells organizations to "consider" controls for new agent components, the "larger attack surface and new protocols", and "Multi-agent interactions" (§2.3.1).

• A "simple LLM-based app", which uses a large language model (LLM), also has a model, instructions, and memory (§1.1.1).
• Control selection includes deterministic safeguards and model-based safeguards for risks "harder to define through fixed rules" (§2.3.1).
• Runtime controls operate "by monitoring and intervening during execution" (§2.3.1).
• The sample controls are examples. For MCP servers (MCP: Model Context Protocol), they include "Whitelist trusted servers" and "Sandbox any code execution". For multi-agent interactions, they include structured schemas and limits on shared memory (§2.3.1).

See Controls for agents and Structural controls.

Is MCP mandatory, or can it act as a governance layer?

The MGF for Agentic AI does not tell organizations to use the Model Context Protocol (MCP). When an organization uses MCP, the MGF tells organizations: "MCP can potentially act as a governance layer as it sits between the agent and the enterprise systems it accesses" (§2.3.1).

Organizations "can consider defining controls on the MCP layer, such as filtering sensitive data that passes through the servers, logging all agent-to-system interactions, or whitelisting only trusted servers" (§2.3.1). The Agent2Agent Protocol is only an example of a protocol for communication between agents (§1.1.1).

See MCP controls.

How do you test an agent workflow before deployment?

The MGF for Agentic AI recommends full workflow tests before deployment, with reasoning and tool calls (§2.3.2).

• Possible tests include "Overall task execution", policy compliance, use of the correct tools with correct permissions, inputs and sequence, and "response to errors and edge cases".
• Tests use an "execution environment that mirrors production as closely as possible". Organizations "should calibrate the need for realism against the risk of prematurely allowing agents to access tools that affect the real world".
• Test "at scale and across varied datasets", more than one time "to check for stability".
• Workflow parts can have "different evaluation methods", but it is necessary to "evaluate agents holistically".

See Test agent workflows before deployment (§2.3.2).

What changes when more than one agent is involved?

The MGF for Agentic AI recommends that organizations test each agent and the multi-agent system (§2.3.2), for emergent behavior and the effects when one agent "has been compromised".

• "Multi-agent systems exacerbate these risks" (§1.2.3). "The extent to which multi-agent systems introduce qualitatively different risks is still being studied" (§1.2.3).
• The sample controls for multi-agent interactions are examples: structured schemas, and limits on shared memory (§2.3.1).
• Some failure modes "may only manifest" with time and "realistic conditions" (§2.3.3).
• The MGF has no dimension only for multi-agent systems.
• In Modulos, the Requirement MRF-317 applies only when the system operates more than one agent.

See Test multi-agent systems and System scope in Modulos.

How should agents be deployed and monitored?

The MGF for Agentic AI recommends "continuous monitoring and testing during deployment", with logs and "reporting and failsafe mechanisms" (§2.3.3).

• Organizations "should consider gradually rolling out agents into production". For example, an organization can start with "trained or experienced users", "more secure, whitelisted MCP servers" (MCP is the Model Context Protocol), or "lower-risk internal systems".
• Organizations "should determine their objectives for monitoring" and "prioritise monitoring for high-risk activities".
• Organizations "can consider" alert thresholds, "log immutability", and "feedback loops" into "training datasets and evaluation frameworks".
• Include human review "proportionate to the risk level". For "catastrophic agentic malfunction or compromise", "termination and fallback solutions should be considered".

See Deployment and monitoring (§2.3.3).

When should a change trigger a new risk assessment?

In the MGF for Agentic AI, "critical changes affecting high-stakes decisions may mandate an immediate re-risk assessment" (§2.3.3). The MGF tells organizations to "consider" "Defining triggers for a change review process" and "Categorising review changes by risk" (§2.3.3).

• The triggers "can include technical triggers", "environmental triggers", "performance triggers", and "regulatory triggers".
• "Minor changes such as prompt refinements may follow lighter review processes".
• "Material changes such as model updates or autonomy adjustments may require a full governance review".
• After anomalies during "implementation or monitoring", organizations "should re-evaluate the earlier dimensions, re-assessing and further bounding the risks if needed" (§2).

See Change management and Risk assessment before development or deployment.

What should users be told about an AI agent?

The MGF for Agentic AI recommends user information on agent actions, data access, and user "responsibilities" (Executive Summary), with examples in §2.4.2:

• User "responsibilities". "Where appropriate", users can set "their own approval thresholds and boundaries".
• "Declare upfront in the user interface" that users interact with agents at the "point of interaction". Only this item has that location.
• The range of actions and decisions with authorization.
• How agents collect, keep, and use user data, "in accordance with the organisation's data privacy policies". "Where necessary, obtain explicit consent from users before collecting or using their data for the agents."
• "Human contact points" when "agents malfunction" or users are "dissatisfied with a decision".

See Information for users (§2.4.2).

What is the difference between users who interact with agents and users who integrate them?

The MGF for Agentic AI (§2.4.1) gives two "main archetypes" of end users: users who interact with agents, and users who "integrate agents into their work processes or oversee them".

• Users who interact usually use agents "that act on behalf of the organisation". These agents "tend to be external facing", but there are internal examples too (§2.4.2).
• Users who integrate usually use agents "as part of their internal workflows", for example "coding assistants". "The agent acts for and on behalf of the user" (§2.4.3).
• For users who integrate agents or "oversee them", the MGF recommends education and training. This adds to the information for users who interact with agents (§§2.4.1, 2.4.3).

See Types of users and User training.

What training do integrating users need?

The MGF for Agentic AI recommends education and training for users who integrate agents into their work (§2.4.3). This adds to the information for users who interact with agents (§2.4.2). It gives three groups (§2.4.3):

1. "Foundational knowledge on agents": "Relevant use cases", "the scenarios under which the use of agents should be restricted", "Instructing the agents", and the range of agent actions.
2. "Effective oversight of agents": "Common agent failure modes", "Ongoing support, such as refreshers", and feedback loops for reports of overrides and incorrect actions.
3. "Potential impact on tradecraft and business continuity": "training and work exposure so that users retain foundational skills".

The MGF sets no schedule or test.

See User training and Tradecraft and business continuity.

What is tradecraft continuity, and how does it differ from AI literacy?

The MGF for Agentic AI recommends that organizations keep users able to "perform critical processes manually" when "agents malfunction or become unavailable" (§2.4.3). Section 2.4.3 gives tradecraft as an item different from "Foundational knowledge on agents" and "Effective oversight of agents". The MGF does not use "AI literacy".

Agents can "take over entry-level tasks, which typically serve as training for new staff". This "could lead to skill degradation" and business continuity risks (§2.4.3). The MGF recommends: "Organisations should identify core capabilities of each job and provide sufficient training and work exposure so that users retain foundational skills."

See Tradecraft and business continuity.

How does Modulos implement the MGF for Agentic AI?

In Modulos, use the MGF for Agentic AI Framework OFF-17 for Organization work and MFF-17 for each agentic AI System.

• Attach OFF-17 to the organization AI System. If your organization has no organization AI System, contact Modulos Support.
• One AI System with MFF-17 can contain more than one agent.
• The Requirement MRF-317 applies only when the system operates more than one agent.
• Some Requirements include sections from more than one dimension of the MGF.

See Set up the AI Systems. For the MGF sections of each Requirement, see Use the MGF in Modulos.

Are MGF Requirements reviewed in Modulos?

Yes. In Modulos, Reviews occur at the Requirement level. The Requirement Owner examines the completed work and makes the decision if the Requirement can have the Fulfilled status. For the conditions that come before a Review, see Requirements.

See Review Requirements.