Appearance
Assess and Bound the Risks Upfront
Assess and bound the risks upfront is Dimension 1 of Singapore's IMDA Model AI Governance Framework for Agentic AI. It is the first of the framework's four dimensions, applied as an iterative loop, and it is where the operative recommendations begin. Dimension 1 answers two questions before an agent is built: is this use case suitable for an agent at all? and how do we constrain the agent's authority so that, when it errs, the damage is bounded? It covers the impact-and-likelihood risk assessment, threat modelling and taint tracing, bounding by design, agent identity and delegated authorisation, the central agent catalogue, and residual-risk acceptance.
The MGF for Agentic AI is voluntary best-practice guidance, not law and not a mandatory standard. The recommendations on this page use the source's advisory register ("organisations should", "consider", "prefer") and are presented as such.
Primary source
This page is a structured guide to Dimension 1 (Assess and bound the risks upfront) of the IMDA Model AI Governance Framework for Agentic AI, v1.5, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. The relevant sections are §2.1.1 (Determine suitable use cases for agent deployment) and §2.1.2 (Bound risks through design), with the action-space-versus-autonomy classification drawn from §1.1.3.
Why agents need risk assessment before they are built
Agentic systems differ from a plain generative-AI application in that they can plan multi-step workflows, call tools, hold memory, and act on external systems with varying degrees of autonomy. That capability is also the source of new risk: an agent's actions emerge dynamically rather than from fixed logic, so the consequences of an error scale with how much authority the agent holds. Dimension 1 places the assessment upfront — before development — because the cheapest place to bound risk is in the choice of use case and the design of the agent's limits, not after deployment.
Two ideas anchor the dimension. First, not every use case is suitable for an agent; the framework is explicit that some workflows are better served by deterministic workflows. Second, even a suitable use case should have its risk bounded by design so that residual risk is tolerable and explicitly accepted. Section 1 of the framework supplies the descriptive vocabulary (the eight core components, the action-space-versus-autonomy distinction, the four human-involvement levels) but assigns no duties; the duties begin here in Dimension 1. For that vocabulary, see Agentic AI components and risks.
Determine suitable use cases (risk = likelihood × impact)
The framework's first recommendation under §2.1.1 is to identify and assess the risk against the benefits of an agentic use case. Risk is treated as a function of likelihood (the probability the risk manifests) and impact (the severity if it does). The framing carries a clear gate: not all use cases are suitable for agents.
This is, in the framework's terms, a suitability decision distinct from the scoring of impact and likelihood. The suitability decision asks whether the agentic design adds value commensurate with the additional risk it introduces; the scoring then tiers the use case so that the highest-risk action classes can be excluded from agent action — or fitted with compensating controls — where the available controls cannot bound the residual risk.
The classification basis is the action-space-versus-autonomy distinction from §1.1.3: action-space is what the agent can do (its tools, permissions, and the systems it can read from or write to), and autonomy is how independently it decides (mapped to the four human-involvement levels — agent proposes/human operates; agent and human collaborate; agent operates/human approves; agent operates/human observes). Classifying per workflow-action-class, rather than per agent as a whole, gives a more honest picture: a single agent may read low-risk data autonomously while writing high-risk changes only with approval.
Worked example (illustrative)
The framework's Dayos case study scores every type of IT ticket against severity of impact, reversibility, and feasibility of human oversight, and uses the score to set a tier that dictates how much autonomy the agent gets — fully automated for low-severity reversible tickets, human-approval-gated for moderate ones, and no agent action for high-severity production changes. The specific tiers and figures are illustrative of the method, not framework requirements.
Impact factors and likelihood factors
The framework lists non-exhaustive factor sets on each axis. They are intended to structure the assessment, not to define a scoring formula.
| Axis | Factor | What it asks |
|---|---|---|
| Impact | Domain and use case | Tolerance for error in the domain; number and criticality of business processes the agent supports |
| Impact | Access to sensitive data | Whether the agent can reach personal or confidential data; heightened where the agent has persistent memory across sessions |
| Impact | Access to external systems | Whether the agent can act on external systems (and so leak data to, or disrupt, third parties) |
| Impact | Scope of the agent's actions | Read versus write; a few pre-defined tools versus a broad action space (for example, a general computer-use tool) |
| Impact | Reversibility of actions | Whether modifications can be easily undone, or trigger downstream obligations (for example, entering a contract) |
| Likelihood | Level of autonomy | Whether the agent follows a defined procedure or defines the entire workflow itself |
| Likelihood | Task complexity | Number of steps and depth of analysis required at each step |
| Likelihood | Access to external systems | Exposure to external, possibly untrusted, systems, increasing susceptibility to prompt injection and cyberattack |
| Likelihood | Provided or operated by an external party | Whether visibility and control over the agent are limited by a third-party vendor |
| Likelihood | System complexity | Multi-agent setups, feedback loops, and combinations of the above, which can produce more emergent behaviour |
Threat modelling and taint tracing
The framework recommends threat modelling to make the risk assessment more rigorous, by systematically identifying the specific ways an attacker might compromise an agentic system. Common threats it cites include memory poisoning, tool misuse, and privilege compromise. Because agentic systems can grow very complex, the framework describes taint tracing — a method that maps all the workflows and interactions to track how untrusted data can move through the system.
More relevant threat events make risk assessments more rigorous and robust, which in turn yields more targeted controls and more effective layered defence. Because risk assessment is continuous, the threat model is expected to be updated regularly. This threat-modelling guidance is adapted in the source from Cloud Security Alliance material; the agentic threat-modelling artefact it produces is distinct from a one-off security test report, and it persists as a living document. In Modulos, this living artefact is part of red-teaming and third-party assessment (MRF-319), discussed under Make humans meaningfully accountable.
Bound risk by design: limits on access, autonomy, and area of impact
Having selected a suitable use case, §2.1.2 recommends bounding the residual risk by defining limits and permission policies for each agent. The framework names three areas of limit:
- Access to tools and systems. Define least-privilege policies that give an agent only the minimum tools and data access it needs. Structuring agents around functional boundaries (for example, separating an IT helpdesk agent from an HR self-service agent) acts as a natural constraint.
- Autonomy. For process-driven tasks, constrain the agent to follow a defined standard operating procedure rather than giving it the freedom to define every step itself. SOPs improve consistency and reduce unpredictability.
- Area of impact. Design mechanisms and procedures to take agents offline and limit their potential scope of impact when they malfunction — for example, running agents in self-contained, network- and data-restricted environments, especially for high-risk tasks such as code execution.
Prefer deterministic limits over prompt instructions
The framework states a clear preference: prefer deterministic rather than non-deterministic limits, and bound by design. The canonical illustration is access control — rather than relying on a prompt to instruct the agent against using a certain tool, impose access controls so the tool cannot be called by the agent at all. The structural-over-prompt-layer principle is the through-line of Dimension 1, and it is elaborated technically in Dimension 3.
Where a limit can only be non-deterministic or is otherwise less reliable, the recommendation is to layer on more monitoring measures or incorporate human-in-the-loop review to catch failures. The framework also pairs bounding with the area-of-impact limit from §2.1.2 — mechanisms and procedures to take the agent offline and limit its potential scope of impact when it malfunctions — so that the limit is enforceable in practice, not only on paper. The testing of these mechanisms belongs to Dimension 3. For how these structural controls are built and tested, see Implement technical controls and processes.
Agent identity: identification and authorisation best practices
As organisations deploy more agents — including agents that interact across organisation boundaries — identity management needs to extend from humans to agents, so that individual agent behaviour is traceable and accountability for each agent is clear. The framework acknowledges this is an evolving space with real gaps (today's authorisation systems often have static, pre-defined scopes and assume a single human principal), and recommends the following interim best practices.
Identification — an agent's identity should be:
- Unique — its own cryptographically verifiable identity, so it can identify itself to the organisation, its human user, or other agents.
- Accounted for — tied to a supervising agent, a human user, or an organisational department.
- Differentiated according to the capacity in which it acts — for example, acting independently versus on behalf of a specified human, recorded for auditability.
- Catalogued and centrally managed — issued from and tracked by a centralised system (see the next section).
Authorisation — an agent's authority should be:
- Scoped, least-privilege, non-transferable — generally scoped, time- or session-bound, non-transferable, and least-privilege by default, with explicit escalation paths for elevated permissions.
- Bounded by the authorising human's permissions — as a rule of thumb, a human user should not be able to grant an agent permissions greater than the human's own, and such delegations of authority should be clearly recorded.
The central agent catalogue (preventing agent sprawl)
The fourth identification best practice deserves its own treatment because it sits at the organisation layer rather than the per-agent layer. To prevent agent sprawl, the framework recommends that all agent identities and their attendant permissions be issued from and tracked by a single centralised system. A central catalogue lets an organisation track its deployed agents, identify anomalies, and remove identities that are no longer required.
This is a tenant-wide capability, not an artefact of any single application, which is why Modulos locates it in the OFF-17 (org) framework rather than the per-application MFF-17. It is the one clean one-to-one mapping in OFF-17: requirement ORF-391 (Maintain central agent catalogue) maps to the single control OCF-298 (Central agent catalogue and identity reconciliation).
Evaluating residual risk
Residual risk is the risk that remains after mitigation measures have been applied. The framework is explicit that some risk always remains — even after a suitable use case is chosen and limits are defined — and particularly so given how quickly agentic AI is evolving. The closing recommendation of Dimension 1 is therefore that organisations evaluate whether the residual risk for an agentic deployment is at a tolerable level, and decide whether it can be accepted.
The framework prescribes no numeric threshold; tolerance and the acceptance decision are left to the organisation. The decision is best recorded as a durable artefact tied to the specific agent, alongside the limits that produced it, so that it can be revisited when the agent, its context, or the available controls change.
How to operationalize Dimension 1 in Modulos
Modulos implements the MGF for Agentic AI as two paired framework templates: MFF-17 at the application layer (per agent) and OFF-17 at the organisation layer (tenant-wide). Dimension 1 spans both. The split is deliberate: the per-agent suitability decision and bounding live with the application, while the risk-and-change methodology and the central catalogue are tenant-wide and live with the organisation. Modulos honours an explicit cross-template routing so that no obligation is duplicated on both sides.
| Requirement | Template | Covers | Mapped controls |
|---|---|---|---|
| MRF-311 — Determine agent use-case suitability and risk context | MFF-17 (app) | Suitability decision; action-space × autonomy classification; impact and likelihood scoring; highest-risk exclusion gate | MCF-16, MCF-545, MCF-546, MCF-547 |
| MRF-312 — Bound agent authority by design | MFF-17 (app) | Least privilege, deterministic-over-prompt limits, sandboxing, emergency revocation, per-agent identity and delegated authority, residual-risk acceptance | MCF-23, MCF-331, MCF-337, MCF-378, MCF-380, MCF-385, MCF-403, MCF-517, MCF-518, MCF-519, MCF-521, MCF-523 |
| ORF-390 — Maintain agentic risk and change-management methodology | OFF-17 (org) | The organisation-wide risk-assessment method and change-management triggers and categorisation that MRF-311 draws on | OCF-3, OCF-44, OCF-95, OCF-97, OCF-103, OCF-109, OCF-110, OCF-111, OCF-130, OCF-299 |
| ORF-391 — Maintain central agent catalogue | OFF-17 (org) | The central identity catalogue that prevents agent sprawl — the only 1:1 mapping in OFF-17 | OCF-298 |
A few points are worth calling out:
- Scoping is not tag-driven. All thirteen MGF requirements carry empty requirement tags. Risk scoping is driven instead by the action-space × autonomy classification (MCF-545, Action-space and autonomy classification) and the impact × likelihood risk-cell rubric (MCF-546, Agentic risk-cell rubric), with the suitability decision enforced by MCF-547 (Agent suitability gate). There is no Singapore-specific tag filter for this framework.
- The org/app routing is explicit. MRF-311 references the organisational risk-assessment methodology (obligation O-007) but routes it to ORF-390, where it actually lives. MRF-312 references the central catalogue (obligation O-014) but routes it to ORF-391. Document the methodology and the catalogue once, at the organisation, and let each agent's MFF-17 project inherit them.
- The agentic-specific controls sit alongside a reused baseline. Several controls under these requirements are part of Modulos's shared library that also serves other frameworks (for example, MCF-16 Risk Tiering, MCF-23 Risk Management at Inception, MCF-331 least-privilege access, MCF-403 Sandbox Techniques). The agentic-specific block is the MCF-517+ and MCF-545+ controls — for example, MCF-517 (Intent binding and drift detection), MCF-519 (Agent identities and delegation controls), MCF-521 (Emergency revocation and quarantine), and MCF-523 (Safe code execution pipeline).
- Requirements are evidenced by readiness plus attestation, not reviews. When all controls linked to a requirement reach a final state, the requirement becomes ready for review — a signal to the requirement owner, who attests fulfilment by marking it fulfilled, with rationale captured in the requirement's comments and logs. Reviews in Modulos apply to control status changes (and other reviewable objects), not to requirements. The residual-risk acceptance decision (MRF-312) is recorded as part of this attestation. For the organisation-wide view across agents, see the portfolio overview.
Cross-framework mapping (preview)
Preview
Dimension 1 sits adjacent to several frameworks that organisations commonly run alongside the MGF for Agentic AI. The bounding-by-design and least-privilege themes are close to the OWASP Top 10 for Agentic Applications security taxonomy (excessive agency, tool misuse, privilege compromise). The suitability decision and residual-risk acceptance echo the risk-management lifecycle in ISO/IEC 42001:2023 and the Map and Manage functions of NIST AI RMF. These are framework-level adjacencies for orientation only; cross-framework reuse in Modulos is implicit at the control layer (several controls cited here are shared, framework-agnostic objects). Detailed, control-by-control mappings — including any EU AI Act correspondence — are out of scope for this page.
Related pages
MGF for Agentic AI overview
The four dimensions, scope, the agentic risk taxonomy, and the MFF-17 / OFF-17 split
Agentic AI components and risks
The eight core components, action-space versus autonomy, and the risk taxonomy this dimension assesses
Implement technical controls and processes
How the structural, deterministic limits chosen in Dimension 1 are built and tested
Operationalizing in Modulos
The MFF-17 / OFF-17 playbook: requirements, controls, and the evidence loop
Portfolio overview
See agentic risk classifications and residual-risk status across all agents
Source attribution
This page summarises and paraphrases Dimension 1 of the IMDA Model AI Governance Framework for Agentic AI, v1.5, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. The relevant sections are §2.1.1 and §2.1.2, with the classification basis in §1.1.3. The threat-modelling and taint-tracing guidance is adapted in the source from Cloud Security Alliance material. Company case studies (Dayos, OCBC and Bank of Singapore, MSD) and their figures are reproduced in the framework as illustrations and are not framework requirements.
Disclaimer
This page is for general informational purposes and does not constitute legal advice. The MGF for Agentic AI is voluntary best-practice guidance, not law and not a mandatory standard; the recommendations here describe common practice for agentic-AI governance programmes. For the authoritative text, consult the IMDA publication directly.