Most people reading a governance framework are checking whether they comply with it. I read this one looking for the sentences that would change what I build. There are four, and only one of them is about ethics.
Singapore’s IMDA published the Model AI Governance Framework for Agentic AI in January 2026. It is at version 1.5 now, and it is a better document than it was at launch. That is itself the most interesting thing about it, and I will come back to it. What follows is not a summary. There are good summaries. This is the part an architect would underline.
Controls beyond the prompt
Here it is, from the section on technical controls:
Rather than prompt-layer safeguards, consider implementing deterministic safeguards that operate at a system-level through predefined logic, especially for higher-risk actions.
The example given is the one that matters: rather than instructing an agent not to use certain tools, put access controls at the tool layer so those tools cannot be called at all — or can only be called in a restricted way, read-only for instance. And if an agent must follow a set procedure, build the sequence into the workflow rather than asking the model to adhere to it.
I would put that on a wall. An enormous amount of what currently passes for agent safety is an instruction in a system prompt, which is to say a request. It is a guardrail in the same sense that a sign is a fence. The framework’s phrasing for why this fails is dry and exactly right: prompt-layer safeguards “tend to be inconsistently defined across users, as opposed to system-level safeguards that can be consistently defined and enforced”. Its own worked example of an agentic deployment puts it more bluntly still, warning that prompt-layer guardrails “may be bypassed or ‘forgotten’”.
That word forgotten is doing a lot. It is not describing an attack. It is describing a Tuesday.
The architectural consequence is unglamorous and immediate. If a control matters, it cannot live in the same channel as the content the model is reasoning over, because anything in that channel is negotiable. It has to live in the layer that executes, which is the same reason your database carries constraints instead of a note in the application code asking everyone to be careful.
The delegation rule, which is older than any of this
Under the risk-bounding dimension, the framework says authorisations 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.”
Then it adds this:
the human user should not be able to set permissions for the agent greater than what the human user is himself authorised to do
Anyone who has worked on a payment system has met that rule before, and met it as an absolute. You cannot delegate authority you do not hold. It is the oldest idea in authorisation and it predates computers by several centuries, and here it is being restated in 2026 because we built a category of software that quietly broke it.
It broke it in a specific way, and the way has a name that is forty years old: the confused deputy. An agent typically runs with the credentials of the system that deployed it, not the person who asked it for something. So the moment a user asks an agent to fetch a record, the question of whether that user could have fetched it stops being asked, because the agent could. The permission boundary silently relocates from the person to the service account. Nobody decides this. It is an emergent property of how the thing was wired, and it is the oldest known failure of delegated authority in computing, arriving again in a new costume.
The framework is honest that the tooling here is not ready. It says outright that “gaps exist today in terms of handling agent identity robustly”, that current authorisation systems “typically have pre-defined, static scopes” while agents need permissions that change with context, and that authentication built around a single unique individual struggles with agents acting for multiple users, or spawning sub-agents. That is a candid paragraph for a government publication. It is also a fair description of an unsolved problem.
Measuring human oversight
The part I did not expect was in the revision.
Automation bias is the tendency to over-trust a system that has been reliable, and most frameworks of this kind mention it. This one does something more useful: it says what to measure. Watch the human override rate — how often people actually reject or modify what the agent proposed — because a low rate “may signal rubber-stamping behaviours.” Watch review times, because a short one may signal automation bias or fatigue. Use analytics to find outlier reviewers whose patterns diverge from everyone else’s, because that may indicate oversight has been compromised.
Those three are the difference between a control and a claim about a control. An approval gate you do not instrument is a gate you are trusting on the strength of its diagram.
A zero override rate means one of two things and you cannot tell which from the number alone: the proposals are genuinely good, or nobody is reading them. That ambiguity is the point rather than a weakness in the metric. It tells you where to look, not what you found. The way to disambiguate is to seed the queue with a proposal that should be rejected and see whether it is. If it sails through, you do not have a human in the loop. You have a human in the path, which is a different thing and worse than having nobody, because it produces documentation.
There is a related warning a few lines later that deserves more prominence than it gets. Chain-of-thought reasoning, the framework notes, “is not analogous to human reasoning and may not be a faithful explanation of the agent’s actions.” Explanation and reproducibility are not the same property. A system can produce a fluent account of why it did something and that account can be a post-hoc narrative. If you need to reconstruct a decision, you need the inputs, the version and the context that were live at the time, captured then rather than regenerated later against data that has moved.
Gaps in the guidance
Three things.
Reversibility is treated as a risk factor rather than a design surface. The framework correctly identifies reversibility as one of the factors determining how risky an agent action is, and gives a good illustration: rescheduling a meeting is easy to undo, sending an external email is not. But the guidance stops at classification. The engineering question is what you do about it: whether you can hold an action in an escrow state, whether you can make a class of actions structurally reversible so the gate can be lighter, whether you build compensation paths. Those are architecture decisions and they are where most of the real work lives.
The multi-agent material is the newest and it shows. Systemic and multi-agent risks were added in a revision, and the treatment is thinner than the single-agent material. Less a criticism than a reading of where the field currently is. Nobody has good answers yet for what accountability means when the thing that acted was a negotiation between four agents, two of which belonged to somebody else.
The controls are never priced. Cost appears in the case studies — one reports the savings from retiring a legacy system — but not one of the recommended controls carries an estimate of what it costs in latency, in reviewer time, or in engineering effort. A reader is left to assume an unlimited budget for oversight, and the actual failure mode in most organisations is not refusing to build controls. It is building too many, watching people route around them, and mistaking the resulting silence for safety.
What I took into my own work
The framework is guidance rather than statute, and it is explicit that organisations remain accountable for what their agents do regardless, so reading it for compliance is reading it wrong. Read the current version. It was at 1.5 by June and the revisions are where the value accumulated.
Two things changed how I work. The override-rate and review-time signals went on the list of things I want instrumented before a gate is called a gate, because until I read that I had no number for “is anyone actually looking.” And the prompt-layer sentence made me go back through my own designs asking which controls were structural and which were merely instructed. Fewer were structural than I would have guessed before checking, which is the useful kind of unwelcome.
The reversibility gap is the one I am still working on, and I think it is the most valuable unclaimed ground in this whole area. Classifying an action as hard to undo is the easy half. Building so that fewer actions are hard to undo — escrow states, compensation paths, a deliberate class of structurally reversible operations — is what would let the gates be lighter without being weaker. That is an architecture problem, it is where most of the real work lives, and nobody has written it down properly yet.
Source
IMDA, Model AI Governance Framework for Agentic AI, version 1.5, published 20 May 2026 and updated 5 June 2026. Version 1.0 was launched on 22 January 2026. All quotations above are from version 1.5. Launch announcement · Framework (PDF)