Docs

Appearance

"Assess and bound the risks upfront" ​

"Assess and bound the risks upfront" is the first of the four dimensions of the IMDA Model AI Governance Framework for Agentic AI (MGF), Version 1.5 (§2.1). The MGF is not law and sets no obligations in law (MGF for Agentic AI).

In the Executive Summary, the MGF recommends that organizations change their internal "structures and processes" for new risks from agents (p. 3).

Section 2.1 of the MGF gives two parts for this dimension. Organizations "should consider" the new risks of agents through these two parts:

  • "Determining suitable use cases for agent deployment by considering agent-specific factors that can affect the likelihood and impact of the risk."
  • "Design choices to bound the risks upfront by applying limits on agent’s access to tools and systems and defining a robust identity and permissions framework."

Risk assessment before development or deployment ​

The MGF recommends a risk assessment for each agentic use case before its development or deployment (§2.1.1). The MGF tells organizations: "When considering if an agentic use case is suitable for development or deployment, first identify and assess the risk against the benefits." The MGF is for organizations that make agents and for organizations that use agents from third parties (MGF for Agentic AI).

For the MGF, "Risk is a function of likelihood (probability of the risk manifesting) and impact (severity of impact if the risk manifests)." The MGF does not tell organizations how to calculate risk from these two items. The MGF also tells organizations that "Not all use cases are suitable for agents, and some may be better served by deterministic workflows."

Two of the factors in Impact and likelihood are the autonomy of the agent and the range of its actions. For more about autonomy and action-space (§1.1.3), see Action-space and autonomy.

The MGF also recommends a new risk assessment in some conditions. In §2, the MGF tells organizations that the four dimensions "should be viewed as an iterative process". The MGF gives this example: "if an anomaly is detected during implementation or monitoring, organisations should re-evaluate the earlier dimensions, re-assessing and further bounding the risks if needed".

Impact and likelihood ​

The MGF gives organizations "non-exhaustive" factors for the risk assessment of an agentic use case (§2.1.1). Five factors change the impact if the risk occurs. Five factors change the likelihood that the risk occurs. The MGF gives no number or weight for each factor.

TypeFactorItem that the MGF tells organizations to examine
ImpactUse caseThe tolerance of error in the use case of the agent and in its "domain". Also the number of "business processes" that use the agent, and how important these "business processes" are.
ImpactAccess to sensitive dataIf the agent can get access to sensitive data, for example personal data or confidential information. If the agent has this access, the risk increases if the agent has persistent memory and can keep sensitive data across sessions.
ImpactAccess to external systemsIf the agent can get access to external systems. An agent that sends data to third-party APIs can leak data to these third parties, or cause problems in these systems.
ImpactRange of actionsIf the agent can only read data and systems, or can also change them. Also if the agent can do a small or a wide range of actions with its tools.
ImpactReversibility of actionsIf the agent can change data and systems, how easily these changes can be "reversed". This can be hard if the changes cause "downstream obligations", for example "entering into a contract or sale".
LikelihoodLevel of autonomyIf the agent can "define the entire" workflow or "must follow" a "well-defined" procedure. More autonomy can cause "higher unpredictability" and can increase the likelihood of error.
LikelihoodTask complexityThe number of steps in the task, and "the level of analysis required at each step". More task complexity can also increase "unpredictability" and the likelihood of error.
LikelihoodAccess to external systemsIf the agent can get access to external systems, and "who maintains these systems". More access to external systems increases the risk of prompt injections and cyberattacks on the agent.
LikelihoodAgent from an external partyIf the organization uses agents that external parties supply or operate. For third-party solutions, the MGF recommends that organizations examine how much of the agent they can see and control.
LikelihoodSystem complexityThe system complexity, for example more than one agent with autonomy in decision-making, or feedback loops. Two or more of the other factors together can also increase the system complexity. More system complexity can cause "more unpredictable and emergent behaviour", "compounding any negative effects".

These factors are not the risk types in §1.2.2 of the MGF. For the risk types, see Agent risks.

Dayos example ​

The Dayos case study in §2.1.1 of the MGF is an example from one organization. The MGF does not recommend the decisions of Dayos for all organizations.

In this case study, Dayos did a "structured risk assessment" before its IT ticket agent started to operate. "Every type of IT ticket was scored against three questions": "Severity of impact", "Reversibility", and "Feasibility of human oversight". The MGF gives this result: "The scores determined which tier each ticket type falls into, and that tier dictated what reasoning strategy the agent uses and how much autonomy the agent gets."

  • "Tier 1" ("Low severity, fully reversible"). The agent does the task without an engineer, in a "propose-confirm loop" with the user. A "designated reviewer" does "biweekly audits" of a sample of the reasoning records of the agent.
  • "Tier 2" ("Moderate severity, partially reversible"). The agent finds the possible cause of the problem and recommends a solution. Before the agent does the task, a "qualified engineer" examines the solution and gives approval.
  • "Tier 3" ("High severity, limited reversibility"). The agent does not do these tasks. Examples are "production deployments", "security changes", and "permission modifications".

Threat modeling and taint tracing ​

In §2.1.1, the MGF tells organizations that threat modeling adds "contextualised threat events" to risk assessment. These threat events identify how an attacker can compromise the system. More threat events that apply to the system make the risk assessment "more rigorous and robust". The result is "more targeted controls" and "effective layered defence". The MGF gives three examples of security threats to agentic systems: memory poisoning, tool misuse, and privilege compromise.

Agentic systems can have a very high system complexity. For these systems, the MGF tells organizations that "it is often useful" to use taint tracing. Taint tracing shows all the workflows and interactions, and how untrusted data can move through the system.

Risk assessment is "continuous". The MGF recommends that organizations keep the threat model up to date at regular intervals. IMDA adapted the information about threat events and the threat model from the CSA "Guide to Cyber Threat Modelling". In the MGF, CSA is the Cyber Security Agency of Singapore.

For how to do threat modeling and taint tracing, the MGF refers organizations to "CSA’s Draft Addendum on Securing Agentic AI". Then, a CSA page of 17 June 2026 gives a CSA addendum, "Securing Agentic AI", with the date June 2026. This addendum is "intended for informational purposes only and is not mandatory". See Related guidance.

Limits on agents ​

After the selection of an "appropriate agent use case", the MGF tells organizations that they "can further bound the risks by defining appropriate limits and permission policies for each agent" (§2.1.2). The MGF recommends that organizations "should consider defining limits on" these three areas:

  • Access to tools and systems. Least-privilege policies give the agent only the minimum tools and data access that are necessary for its task. The MGF also tells organizations that "Structuring agents around functional boundaries" can be a "natural constraint". An example is "separating IT helpdesk from HR self-service".
  • Autonomy. "For process-driven tasks", organizations frequently use SOPs and protocols to "improve consistency and reduce unpredictability". The MGF recommends standard operating procedures (SOPs) for agentic workflows that the agent is "constrained to follow". The agent does not get the "freedom to define every step of the workflow".
  • Area of impact. Mechanisms and procedures "take agents offline" and limit their possible area of impact if they do not operate correctly. These mechanisms can include "self-contained environments with limited network and data access", "particularly when they are carrying out high-risk tasks such as code execution".

Deterministic limits ​

For organizations, the MGF recommends: "In general, prefer deterministic rather than non-deterministic limits, and bound by design" (§2.1.2). The MGF gives this example. A prompt can tell the agent not to use a tool. But the MGF recommends access controls that stop all use of the tool by the agent.

Some limits are non-deterministic limits or are "less reliable". For these limits, the MGF recommends more monitoring measures or human-in-the-loop review "to catch any failures".

Section 2.3.1 of the MGF gives more information about technical controls of this type. That section also tells organizations that model-based safeguards "can be most effective" where risks "are harder to define through fixed rules". See Structural controls.

Agent identity and authorization ​

The MGF tells organizations that identity management "needs to be extended to agents" (§2.1.2). With identity management for agents, an organization can monitor the actions of each agent and "establish who holds accountability for each agent". This is important when an organization deploys more agents, and when agents operate "across organisation boundaries".

The MGF also tells organizations that agent identity is "an evolving space" and that "gaps exist today". For example, authorization systems usually have "pre-defined, static scopes". But "to operate safely in more complex scenarios", agents "require fine-grained permissions". These permissions can change with the conditions, the risk level, and the task.

Authentication systems usually apply to one person. These systems cannot easily operate with an agent that operates for more than one human user with different permissions. They also cannot easily operate with recursive delegation, where an agent starts more agents.

Until solutions are available, the MGF recommends that organizations "should consider these best practices". For identification, the MGF recommends that each agent identity has these four qualities:

  • "Unique". An agent "should have its own unique, cryptographically verifiable identity, such that it can identify itself to the organisation, its human user, or other agents".
  • "Accounted for". The MGF recommends a connection from each agent identity to "a supervising agent, a human user, or an organisational department", for "accountability and tracking".
  • "Differentiated according to the capacity in which it acts". An agent can operate in different "capacities", for example "independently or on behalf of a specified human user". The MGF recommends that the organization records each "capacity" "for auditability".
  • "Catalogued and centrally managed". All agent identities, with their permissions, come from one system for the organization. See Central agent catalog.

For authorization, the MGF recommends that the authority of an agent has these two qualities:

  • "Scoped, least-privilege, non-transferable". Authorizations "should generally be scoped, time- or session-bound, non-transferable, and follow the principle of least privilege by default, with explicit escalation paths for elevated permissions".
  • "Bounded by authorising human’s permissions". The permissions of an agent can be "pre-defined" and "based on its role or the task". The "authorising human user" can also set them "dynamically". An agent can also have permissions of the two types together. The MGF gives this "rule of thumb": the human user "should not be able to set permissions for the agent greater than" the permissions of that user. An example is access to data that is not in the permissions of the human user. The MGF recommends that organizations record these delegations of authority clearly.

Central agent catalog ​

The MGF recommends a central agent catalog "To prevent agent sprawl" (§2.1.2). In this central agent catalog, one system for the organization gives all agent identities and their permissions, and monitors them. With this system, an organization can monitor its deployed agents, find anomalies, and remove agent identities that are not necessary at this time.

For more information about agent sprawl, see Risks of agentic AI.

Residual risk ​

The MGF recommends that organizations make a decision about their residual risk (§2.1.2). For the MGF, "Residual risk is the risk that remains after mitigation measures have been applied." Some risk always "remains", also after the selection of "appropriate agentic use cases" and after limits on agents. The MGF adds: "especially given how quickly agentic AI is evolving".

The MGF tells organizations: "Ultimately, organisations should evaluate and determine if the residual risk for their agentic deployment is of a tolerable level and can be accepted." The MGF gives no number for a "tolerable level". The MGF also does not tell organizations how to record the decision.

For a new risk assessment after an anomaly, see Risk assessment before development or deployment. Modulos has no function that records a decision to accept residual risk (see Work not held in Modulos).

Use the framework in Modulos ​

For the Singapore MGF for Agentic AI, Modulos has MFF-17 at AI System level and OFF-17 at Organization level (Set up the AI Systems).

For the Requirements and their MGF sections, see the Requirements in Modulos.

Sources ​

  • IMDA (Infocomm Media Development Authority), Model AI Governance Framework for Agentic AI, Version 1.5, "Published 20 May 2026" and "Updated 5 June 2026". The Executive Summary (page 3), §2 (page 13), §2.1 (page 15), §2.1.1 with the Dayos case study (pages 15–18), §2.1.2 (pages 19–24), and the Acknowledgements (page 53).
  • CSA (Cyber Security Agency of Singapore), "Securing Agentic AI", an addendum to the Guidelines and Companion Guide on Securing AI Systems, June 2026, pages 1–5.

Disclaimer

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