Appearance
Agentic AI Components and Risks
The first section of the IMDA Model AI Governance Framework for Agentic AI is its conceptual foundation: what the framework means by "agentic AI", the parts an agent is built from, the ways agents are combined, the two axes that describe what an agent can do, the levels at which a human stays involved, and the kinds of harm that follow when agents act in the real world. Everything the framework recommends in its four dimensions builds on these definitions, so this is the page to read before the four pillar pages.
Section 1 is descriptive. It does not assign duties to any actor — the only soft framing is that organisations should be aware of the five real-world harm types. The operative recommendations begin in Section 2 (the four dimensions). The framework as a whole is voluntary best-practice guidance from IMDA, not law and not a mandatory standard.
Primary source
This page summarises Section 1 ("Introduction to Agentic AI") 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 framework is a living document in the MGF series and builds on the Model AI Governance Framework (2020, 2nd Ed). Where this page reproduces adapted concepts, the framework attributes them to third-party sources (including GovTech Singapore, CSA Singapore, Anthropic, the World Economic Forum, AWS, the Knight First Amendment Institute at Columbia University, and the Gradient Institute); those attributions are preserved below and are not IMDA instruments.
What the framework means by "agentic AI"
The framework acknowledges there is no consensus definition of an AI agent, but identifies common features: agents usually possess some degree of independent planning, decision-making, and action-taking — such as searching the web or creating files — over multiple steps to achieve a user-defined goal. Agentic AI systems are software systems consisting of one or multiple AI agents that may operate individually or collaboratively.
The framework scopes itself to agents built on generative AI models, which generally use a small, large, or multimodal large language model (SLM, LLM, or MLLM) as their "brain" to make decisions and complete tasks. It notes that software agents are not a new concept and that other types of agent exist — for example those that use deterministic rules or other neural networks — but those are outside the framework's focus.
The eight core components of an agent
Because agents are built on top of language models, the framework starts from the components of a simple LLM-based application and extends them. It names eight core components:
| # | Component | What it is |
|---|---|---|
| 1 | Model | The SLM, LLM, or MLLM that serves as the central reasoning and planning engine — the agent's "brain". It processes instructions, interprets user inputs, and generates responses. |
| 2 | Instructions | Natural-language commands that define the agent's role, capabilities, and behavioural constraints (for example, an LLM system prompt). |
| 3 | Memory | Information stored and accessible to the model in short- or long-term storage, sometimes added so the agent can draw on previous interactions or external knowledge. |
| 4 | Planning and reasoning | The model's ability to output the series of steps needed for a task. |
| 5 | Tools | Interfaces that let the agent take actions and interact with other systems — writing to files and databases, controlling devices, performing transactions. An agent can itself be called as a tool by another agent (for example, a supervisor agent invoking a specialist agent). |
| 6 | Protocols | Standardised ways for agents to communicate with tools and other agents. The framework cites the Model Context Protocol (MCP) for agent-to-tool communication and the Agent2Agent Protocol (A2A) for agent-to-agent communication, noting this is a fast-developing space. |
| 7 | Controls | Access controls, guardrails, and human approvals that limit the agent's action-space and autonomy. |
| 8 | Logging and monitoring | Records of agent actions, decisions, and interactions across all components, to enable monitoring, debugging, and accountability. |
Components 1–3 are the LLM-app fundamentals; component 4 (planning and reasoning) and component 5 (tools) are what enable an agent to complete more complex, multi-step tasks; component 6 (protocols) standardises how the agent reaches tools and other agents. Components 7 and 8 — Controls and Logging and monitoring — are the components most directly about safe and reliable performance, and are an explicit part of the core-component model in this version of the framework rather than an afterthought.
The framework names three control sub-types under component 7: access controls (limiting what the agent can see, use, or change, including sensitive data, tools, and systems), guardrails (monitoring and constraining behaviour before, during, or after the agent acts, to catch unsafe instructions, policy violations, or actions inconsistent with user intent), and human approvals (requirements for a human to review or approve agent actions).
INFO
MCP and A2A are cited as examples of the connector and agent-communication patterns, not as mandated technologies. The framework treats protocols as a fast-developing space — MCP is one instantiation of a connector/gateway pattern, and more protocols continue to emerge, particularly in agentic commerce.
Multi-agent design patterns: sequential, supervisor, swarm
In an agentic system it is common for multiple agents to work together, so that each can specialise in a function or work in parallel, and so that each agent's tools and permissions can be scoped separately rather than concentrated in one agent with access to many tools. The framework describes three simple design patterns:
| Pattern | How agents are arranged |
|---|---|
| Sequential | Agents work one after another in a linear or otherwise structured workflow (for example, a graph). Each agent's output becomes the next agent's input. |
| Supervisor | One supervising agent coordinates specialised agents under it, calling specific agents as tools when required. |
| Swarm | Agents work at the same time, handing off to another agent when needed. |
The framework stresses there is no universally correct architecture, and that a real task can require different or hybrid patterns. A well-defined task with a step-by-step workflow can lend itself to a sequential architecture, whereas a more open-ended task that involves brainstorming or pursuing different lines of inquiry may benefit from a swarm.
Action-space versus autonomy
While each agent may share the same core components, the design of those components significantly affects what the agent can actually do. The framework distinguishes two concepts:
- Action-space (or authority, capabilities) — the range of actions an agent can take, including the transactions it can execute, determined by the tools it is allowed to use and the permissions on those tools.
- Autonomy (or decision-making) — the degree to which an agent can decide how to act toward a goal, such as by defining the steps to be taken, determined by its instructions and the level of human involvement.
These are separate axes. An agent's autonomy depends mainly on how detailed its instructions are — an agent told to follow a detailed SOP is limited in the decisions it can make at each stage, whereas an agent told to use its own judgment has more freedom to define its plan and workflow. The framework notes that, in enterprise deployments, most agentic implementations are hybrid systems combining deterministic rules with some autonomy.
Tool access tiers and read vs write
An agent's action-space depends chiefly on the systems its tools can reach and the operations it can perform on them. The framework describes the systems an agent can access as a tier:
- Sandboxes only — sandboxed tools (for example, code execution or data analysis) that cannot affect any other system.
- Internal systems — tools internal to the organisation, such as searching and updating the organisation's databases.
- External systems — tools that reach external services, such as retrieving and updating data through third-party APIs.
Cutting across this is the read versus write distinction: an agent may only be able to read and retrieve information from a system, or it may also be able to write to and modify data. The framework also flags an emerging modality, the computer-use agent, whose primary tool is access to a computer and browser. Such an agent can take any action a human can with a computer and browser — scrolling, clicking, typing — without relying on specifically defined tools and APIs, which significantly increases what it can access and do.
This tiering matters operationally because the highest-risk combinations — irreversible writes against external systems, or computer-use surfaces — are exactly the combinations the framework later recommends bounding by design, gating behind default human approval, or otherwise heavily constraining.
The levels of human involvement
A further input to autonomy is the level at which a human stays involved. The framework names four levels:
| Level | What it means |
|---|---|
| Agent proposes, human operates | The human reviews and approves every agent action. |
| Agent and human collaborate | The agent requires human approval at significant steps (for example, before writing to a database or making a payment); the human can intervene at any time by taking over or pausing the agent and requesting a change. |
| Agent operates, human approves | The agent requires human approval only at critical steps or failures, such as deleting a database or making a payment above a predefined amount. |
| Agent operates, human observes | The agent does not require approval to complete its task, though its actions may be audited after the fact. |
These four levels run from the most hands-on to the most hands-off, and together with the agent's instructions they set its autonomy. The framework adapts this human-involvement scale from the Knight First Amendment Institute at Columbia University's work on levels of autonomy for AI agents.
Types of agentic risk
The framework treats the sources of agentic risk as largely familiar. Agents are software systems built on LLMs, so they inherit both traditional software vulnerabilities (such as SQL injection) and LLM-specific risks (such as hallucination, bias, data leakage, and adversarial prompt injection). What is new is that these risks can manifest differently through the agent's new components — for example, planning and reasoning can produce a plan that contradicts or drifts from the user's intent; tools can be called when they do not exist, with the wrong inputs, or be turned against the agent through prompt or code injection; and poorly deployed or compromised protocols can be used to exfiltrate data (for example, an untrusted MCP server).
Because agents take actions in the real world, malfunctions can cause real-world harm. The framework says organisations should be aware of five types of harmful outcome:
| Risk type | Description |
|---|---|
| Erroneous actions | Incorrect actions, such as fixing an appointment on the wrong date or producing flawed code; the harm depends on the action (flawed code can create exploitable vulnerabilities, a wrong medical appointment can affect a patient's health). |
| Unauthorised actions | Actions outside the agent's permitted scope or authority — for example, proceeding without escalating for human approval where a human instruction, company policy, or SOP required it. |
| Biased or unfair actions | Biased LLM output translating into biased actions, leading to unfair outcomes across groups — for example, biased vendor selection in procurement, grant disbursement, or hiring decisions. |
| Data breaches | Exposure or wrongful modification of sensitive (personal or confidential) data, whether through a security breach exploiting the agent or through the agent failing to recognise data as sensitive. Agents generally have greater data access than a standalone LLM and can not only leak but also wrongly modify data. |
| Disruption to connected systems | Disruption when an agent is compromised or malfunctions — for example, deleting a production codebase or overwhelming an external system with requests. |
Systemic and multi-agent risks
New in version 1.5, the framework adds a treatment of systemic and multi-agent risks — the ways the speed and complexity of agentic systems can amplify the risks above.
Two systemic effects are named first. Speed and volume: agents take decisions fast enough that oversight mechanisms may not detect and prevent unauthorised actions in real time, and asking human approvers to continuously oversee agents can itself lead to automation bias and alert fatigue. Cascading or compounding effects: a mistake in one step can propagate and amplify across later steps — for example, a single hallucinated inventory figure in supply-chain management triggering downstream actions that over- or under-order stock.
Multi-agent systems are described as exacerbating these risks because more agents interact, and because they often share context, memory, and intermediate outputs — increasing the chance that sensitive data is unintentionally logged, passed to a less secure agent, or exposed through prompt injection. The framework notes the extent to which multi-agent systems introduce qualitatively different risks is still being studied, but lists the more pertinent ones:
| Multi-agent risk | Description |
|---|---|
| Agent sprawl | Uncontrolled proliferation of agents within an organisation without centralised management, causing problems with provenance, incompatibility between old and new agents, and managing agents across generations. |
| Collaborative failures | The framework groups three modes under this heading. Miscoordination — agents working together fail through bad communication or miscoordination, for example interpreting the user's intent differently and working toward different goals. Conflict — agents optimising different goals come into conflict, for example a customer-support agent offering refunds to resolve complaints quickly while a revenue-protection agent blocks refunds above a threshold. Collusion — agents develop behaviour that appears coordinated even without an explicit instruction to collude, for example pricing agents observing each other and converging on higher prices (studied for pricing algorithms and now being studied for LLM-based agents). |
| Unpredictability and emergent behaviours | When multiple non-deterministic agents work together, the number of possible outcomes grows exponentially, producing emergent behaviour that cannot be predicted from testing each agent individually. |
Finally, the framework notes that agents can interact within a system or across systems and organisational boundaries; once agents cross those boundaries it becomes harder to test for and anticipate the spectrum of outcomes, especially without white-box access to the external systems. This treatment is adapted in part from the Gradient Institute's work on risk-analysis techniques for governed LLM-based multi-agent systems.
How these concepts drive risk scoping in Modulos
Section 1 is descriptive, so it carries no requirements of its own. In Modulos, the Section 1 concepts are operationalised one layer down — as the classification cluster of controls that the assessment requirements consume. Scoping for this framework is not tag-driven: every Singapore MGF for Agentic AI requirement carries an empty tag set. Instead, scoping is the output of an explicit classification-and-rubric step encoded in three controls:
| Control | Name | What it encodes from Section 1 |
|---|---|---|
MCF-545 | Action-space and autonomy classification | The §1.1.3 axes — action-space (sandbox / internal / external), autonomy (SOP-bound / hybrid / free-judgment), read/write effect, tool surface, and the multi-agent topology dimension (single-agent, sequential, supervisor, swarm, hybrid) from §1.1.2. |
MCF-546 | Agentic risk-cell rubric (impact × likelihood) | A per-action-class scoring rubric whose impact and likelihood factors map directly onto the §1.2.2 harm types and the §1.2.3 systemic and multi-agent factors. |
MCF-547 | Agent suitability gate | A pre-build gate that asks whether an agent is the right solution at all, given the action-space, autonomy, and risk the design introduces. |
These controls are referenced by MRF-311 (Determine agent use-case suitability and risk context), which consumes the classification and rubric to set each application's risk context, and the multi-agent topology dimension is the lens carried into MRF-317 (Govern multi-agent and cross-system interactions). MRF-317 is conditional: it applies only when more than one agent runs, so single-agent deployments mark it not applicable.
As with every Modulos requirement, the classification and suitability outputs are evidenced through a readiness signal plus owner-attested fulfilment — not through reviews, which are reserved for control status changes. The detailed assessment workflow lives on the Assess and bound risks page; the controls themselves and the rest of the control library are covered on Technical controls and processes.
Cross-framework mapping (preview)
The Section 1 vocabulary sits close to several other frameworks an organisation may already run, at a conceptual level:
- OWASP Top 10 for Agentic Applications — the agentic risk taxonomy (tool misuse, excessive agency, identity and privilege, multi-agent failures) is the closest neighbour to the §1.2 risk types and the §1.2.3 multi-agent risks.
- ISO/IEC 42001 — the management-system view of context, risk assessment, and component-level controls corresponds to the classification and risk-context work the MGF places upstream of design.
- NIST AI RMF — the Map function's context-and-component framing is adjacent to the action-space, autonomy, and component model described here.
Preview
This is a high-level adjacency note only. Detailed, control-by-control mappings are out of scope for this page, and this page does not assert article-level cross-framework obligations. Cross-framework reuse in the Modulos templates is implicit at the control layer (several mapped controls also serve other frameworks and carry an Agnostic tag). For the nearest agentic-risk neighbour, start with the OWASP Top 10 for Agentic Applications overview.
Related pages
Singapore MGF for Agentic AI overview
The hub: the four dimensions, the MFF-17 / OFF-17 templates, and how to operationalize the framework
Assess and bound risks
Dimension 1: how suitability, classification, and the risk-cell rubric set an agent's risk context
Technical controls and processes
Dimension 3: the control library that constrains action-space and autonomy in practice
OWASP Top 10 for Agentic Applications
The adjacent agentic-risk taxonomy, mapped at the control layer
Source attribution
This page summarises Section 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. It covers §1.1 (What is Agentic AI?), §1.1.1 (core components), §1.1.2 (multi-agent setups), §1.1.3 (action-space, autonomy, tool access tiers, and the four human-involvement levels), §1.2.1 (sources of risk), §1.2.2 (types of risk), and §1.2.3 (systemic and multi-agent risks). The framework is a living document in the MGF series and builds on the Model AI Governance Framework (2020, 2nd Ed). Concepts adapted in the source are attributed there to third parties including GovTech Singapore, CSA Singapore, Anthropic, the World Economic Forum, AWS, the Knight First Amendment Institute at Columbia University, and the Gradient Institute; those attributions are preserved here.
Disclaimer
The Singapore IMDA Model AI Governance Framework for Agentic AI is voluntary best-practice guidance, not law and not a mandatory standard. The Modulos platform labels the corresponding templates "Regulation", which is a platform-template artefact and not a legal characterisation. This page reproduces and summarises publicly available IMDA guidance for orientation and operational use; the authoritative source is the framework text itself. This page does not constitute legal advice.