Agentic AI oversight
IMDA Agentic AI Framework v1.5 §2.1 — Assess and bound the risks upfront
No binding instrument requires an organisation to decide what an AI agent may and may not do. The discipline comes from a framework nobody is compelled to follow — Singapore’s Model AI Governance Framework for Agentic AI, version 1.5 — which asks that those limits be enforced by the system itself rather than asserted in a prompt the agent can ignore.
§ 1 — Who it binds
Which deployments the framework speaks to
Deployer
Any deployment in which software carries out some degree of independent planning, decision-making and action-taking over multiple steps to achieve a user-defined goal. There is no sectoral, size or risk-tier gate — the framework scopes itself by behaviour. It addresses agents built on generative AI models and says so expressly, noting that other kinds of agent exist which it does not cover.
§ 2 — In practice
Where the boundary is actually drawn
Search the Union’s AI legislation for the word "agentic" and you find it once. Regulation (EU) 2026/1744 inserts a new Annex XIV into the AI Act — the list of codes used when a notified body’s scope of designation is notified — and within it code AIH 0401 covers "AI systems based on other emerging AI technologies not covered by other codes, including Agentic AI". That is the whole of it: a filing category, creating no duty for anyone deploying an agent. Nothing in the Act, and nothing in any other binding instrument, tells a deployer how much authority an agent may hold. What exists instead is the IMDA Model AI Governance Framework for Agentic AI, version 1.5 (20 May 2026, updated 5 June 2026), which recommends, invites feedback, calls itself a living document, and attaches no consequence to being ignored.
§2.1.1 puts risk at likelihood multiplied by impact and then names what moves each. Impact rises with the domain, with access to sensitive data — aggravated where memory persists across sessions — with access to external systems, and with the scope of actions: whether an agent can only read from or can also modify the data and systems it has access to, and whether it can complete a small or wide range of actions using the tools available to it. Likelihood rises with autonomy, task complexity, external provision, and — a factor version 1.5 added — system complexity, where components interacting in unexpected ways produce emergent behaviour. Most deployments scope by system rather than by verb. "The agent can reach Salesforce" collapses the read-and-write distinction the framework treats as the primary impact axis, and §2.3.1 is blunt about which side of it matters: do not grant agent write access to tables in sensitive databases unless strictly required.
The operative sentence is one line long: in general, prefer deterministic rather than non-deterministic limits, and bound by design. Rather than relying on prompts to instruct the agent against accessing certain tools, it says, impose access controls that prevent the tool from being called by the agent at all. Practitioners rarely draw the consequence. A system prompt listing forbidden actions is, on the framework’s own taxonomy, a non-deterministic limit — and where limits are non-deterministic or less reliable the recommendation is to layer on more monitoring measures or incorporate human-in-the-loop review to catch any failures. A prompt-layer boundary therefore creates a compensating duty rather than closing one. The OpenClaw case study makes the same point about approvals: enforce human approval through system-level controls where possible, as against prompt-layer guardrails, which may be bypassed or forgotten.
The envelope is assessed per action type, not per agent, and that is where most implementations stop short. The Dayos case study scores every type of IT ticket on severity, reversibility and oversight feasibility, landing each in one of three tiers: fully automated, propose-and-approve, or the agent cannot act at all. One autonomy setting for one agent is not that exercise. What follows it is a residual-risk position the framework states plainly — there will always be a level of risk remaining, and organisations should evaluate and determine if the residual risk for their agentic deployment is of a tolerable level and can be accepted. That is the same shape of judgement Article 9 makes binding for the provider of a high-risk system, with the difference that governs this page: nothing makes it binding for an agent, so the only thing that produces the record is a practice the organisation chose to adopt.
The framework addresses organisations looking to deploy agentic AI, whether by developing AI agents in-house or using third-party agentic solutions. Its value chain separates model developers, tooling providers, platform providers — a distinction version 1.5 introduced — system providers and end users, noting that organisations may play multiple overlapping roles. That matters when a limit is drawn, because the party able to enforce one is frequently not the party that decided it. A capability change is the moment the determination goes stale: a new tool, a new MCP server, a new hand-off target or a model upgrade each widens the envelope without anyone editing the document describing it. Our note on building an AI risk profile sets out one way to hold that record.
§ 3 — What a weak answer looks like
The prompt mistaken for a permission
The system prompt offered as the boundary. It is well drafted, it enumerates what the agent must not do, and under test the agent obeys it. What it cannot survive is the question of what happens when it does not, because nothing else stands behind it — and the framework classes exactly this as the kind of limit that triggers a requirement for compensating monitoring rather than one that discharges anything. A second version of the same answer is a service account confined to one system, offered as least privilege. It answers where the agent may go and stays silent on what it may do once it is there.
§ 4 — What discharges it
What a bounded agent leaves behind
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
An action catalogue with a tier assigned per action
A row for each action the agent can take, rather than one classification for the agent, with the tier it lands in and the reason. Where the catalogue was written from the design document it lists capabilities nobody has exercised and omits whatever was added last month.
02
A tool manifest exported from the runtime
Not the architecture diagram and not the vendor’s feature list — what the agent can call today, pulled from running configuration and reconciled line by line against the approved catalogue. The exceptions are the finding.
03
A register separating deterministic limits from prompt-layer ones
Every limit named, alongside where it is enforced: connector, tool layer, orchestration logic, or the system prompt. Each prompt-layer entry should carry the compensating monitoring or review, which is the framework’s own condition rather than an auditor’s embellishment.
04
Negative test results — disallowed actions attempted
The OpenClaw guidance says to attempt disallowed actions to ensure restrictions work. The artefact is the attempt and its outcome, per restriction, dated against a release. A restriction nobody has tried to breach is an assertion about software.
05
A dated residual-risk acceptance with a named accepter
Nothing compels this, which is why its presence carries weight. Where the framework’s language has been adopted, the record names who accepted, on what date, and precisely what — a tier assignment over a named set of actions, not an overall posture.
06
A re-scoping trigger tied to capability change
New tools, new MCP servers, new hand-off targets and model upgrades widen what an agent can do without amending anything. The artefact is the mechanism that reopens the determination, plus one occasion on which it fired.
§ 5 — Worked example
Worked example — a procurement agent with a threshold
A logistics firm deploys a procurement agent on a commercial platform. It reads supplier catalogues, drafts purchase orders and — below a value threshold set in its system prompt — submits them without review. The same prompt tells it never to contact suppliers directly and never to amend an existing order. Security signed the deployment off because the agent authenticates through a service account scoped to the procurement system alone.
Has the firm bounded the agent’s authority?
Only in the sense that it has confined the agent to one system. The threshold, the no-contact rule and the no-amendment rule are instructions, and instructions are non-deterministic limits: they will hold most of the time and nobody can say in advance when they will not. Each therefore carries a compensating requirement the firm has not met — monitoring able to detect the limit being crossed, or human review of the action it governs. The service-account scoping is a real control at the wrong granularity: it settles which system the agent reaches, not which verbs it may use inside that system, and submitting a purchase order is a write with a counterparty at the far end of it. And because no catalogue was built per action type, nobody has decided whether amending an order belongs in the same tier as raising one. The remedy is small. Move the value threshold into the procurement system’s own authorisation logic, where it becomes deterministic, then record why the remaining prompt-level limits are acceptable and what watches them.
§ 6 — Elsewhere
The same ground in other instruments
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
Article 9 requires a provider of a high-risk system to run a continuous risk process and to record a judgement that residual risk is acceptable. The framework’s upfront assessment of impact and likelihood sits at the same point in the sequence, for a population no regulation reaches.
NIST AI RMF
MAP 3.3 addresses specifying and documenting the targeted application scope of a system. It is the closest subcategory to deciding what an agent may be used for before deciding what it may do.
NIST AI RMF
MANAGE 1.4 addresses documenting negative residual risks. The framework asks for the same record and supplies no threshold for it, which leaves the acceptance rather than the rating as the artefact.
MAS instruments
The draft Guidelines, paragraph 3.10(c), would put the level of autonomy granted to a system, the degree of human involvement and the availability of alternatives into a financial institution’s risk-materiality assessment. It is a proposal in a consultation paper.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 7 — When it applies
Two versions, and why the version matters
22 January 2026
Version 1.0, launched at Davos. A publication date rather than a compliance deadline: there is no obligation here to transition to, and no transition period, because the framework creates no duty.
20 May 2026
Version 1.5, updated 5 June 2026, and the version to cite: system complexity was added to the likelihood factors here, and §1.2.3 did not exist in version 1.0. A publication date again, and nothing follows for an organisation that ignores it.
§ 8 — provenance
The provision itself
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
- IMDA and the AI Verify Foundation, Model AI Governance Framework for Agentic AI, version 1.5, §2.1 "Assess and bound the risks upfront", with §2.1.1 and §2.1.2.
- Version 1.5 published 20 May 2026 and updated 5 June 2026. A publication date; the framework sets no deadline and creates no duty.
- MDDI, announcing the launch of version 1.0 on 22 January 2026.
- Regulation (EU) 2026/1744, Article 1 point (43), inserting Annex XIV to Regulation (EU) 2024/1689 — heading 3(d), code AIH 0401, the sole occurrence of "Agentic AI" in EU AI Act legislation.
- MAS Consultation Paper P017-2025, November 2025. The draft Guidelines are at §6 and carry their own numbering; paragraph 3.10(c) is a draft Guidelines paragraph.
§ 9 — Also read
Also read
How to build an AI risk profile for a deployment
Certification
Assessed on the same standard of evidence
Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The Certified Applied AI Associate, the Council’s flagship, is open to any adult today, its fee waived by a coupon code from the AI-Readiness Check, and the register lists what is open for enrolment.