When I read a governance framework, I ask what would make me design a system differently.

Singapore’s Model AI Governance Framework for Agentic AI gave me several useful answers. The version I am discussing here is 1.5, published in May 2026 and updated in June. It covers controls beyond the prompt, delegated authority and ways to check whether human oversight is doing useful work.

What interested me most was how those recommendations translate into architecture, and where an architect still has decisions to make.

Put important controls beyond the prompt

The framework recommends deterministic safeguards at the system level, especially for higher-risk actions. Its examples make the distinction practical: restrict tools through access controls rather than merely telling an agent not to use them, and build required sequences into a workflow.

A prompt can explain a boundary. For an important action, I want the execution layer to enforce it.

This matters because the model also reads task instructions, retrieved documents and tool output. Those inputs can influence its reasoning. They should not be able to give it permission to cross a boundary.

The framework’s warning that prompt safeguards can be bypassed or forgotten prompted me to revisit my own designs. I found fewer structural controls than I would have guessed before checking. That was a useful result, even if it was not a comfortable one.

I now ask a concrete question during review: what stops the action if the agent ignores the instruction? The answer needs to identify a control in the system.

You cannot delegate authority you do not hold

The framework describes permissions that are scoped, time- or session-bound, non-transferable and limited by default, with explicit escalation paths. It also states that a human should not be able to grant an agent more authority than the human has.

That principle was familiar to me from payment systems. The difficulty is preserving it when an agent acts through a service with broader credentials.

Suppose a user asks an agent to retrieve a record. If the system checks only whether the agent’s service account can retrieve it, the user’s own permission may never be tested. The agent has become a confused deputy: it is using its authority on behalf of someone who may not have that authority.

The architecture has to preserve the relationship between the user, the requested action and the permission that permits it. Tool access alone does not answer all three.

The framework also acknowledges gaps in agent identity and authorisation. Static scopes do not easily express permissions that change with context, and identities become harder to follow when an agent serves multiple users or delegates to other agents. I read those as unresolved design questions, rather than details a policy statement can settle.

Measure whether people are actually reviewing

An approval button does not tell me whether someone made a meaningful decision.

The framework suggests watching override rates and review times, and looking for reviewers whose patterns differ from the rest. These signals made oversight more concrete for me. I put override rates and review times on the list of things I want instrumented before treating a gate as effective.

The numbers need interpretation. A low override rate could mean the proposals are good, or that people are approving without reading. A quick review might be appropriate for a familiar action, or it might reflect fatigue.

I would use those signals to decide where to investigate. In a controlled test, a deliberately unacceptable proposal could help establish whether the review process catches what it should. The metric points to a question; it does not answer it by itself.

The interface matters as much as the measurement. The reviewer needs to see the proposed action, the resource it affects, the scope of permission and the supporting evidence. If the proposal changes materially, the original approval needs to be reconsidered.

An explanation is not a reconstruction

The framework also cautions against treating an agent’s chain-of-thought account as a faithful explanation of its actions.

For a later review, a fluent narrative is not enough. I need the inputs, model version and surrounding context that were present when the action occurred, along with the action itself.

Those records need to be captured at the time. Asking the agent to explain later, after the underlying data has changed, cannot recreate the original decision conditions.

This distinction affects what I retain and where I retain it. Evidence should travel with the decision, so a reviewer does not have to reconstruct it from the agent’s recollection.

Where I wanted more guidance

Three areas left me with architectural work still to do.

Reversibility. The framework treats reversibility as a factor in risk. That is useful, but I want to go further: can an action be held pending approval, undone safely or paired with a compensating action? Making more actions reversible could let some gates become lighter without weakening the control.

Multi-agent accountability. The material added on systemic and multi-agent risks recognises a harder problem. If several agents contribute to an action, potentially across organisations, the record needs to show how authority and evidence moved between them. The guidance leaves substantial design work here.

The cost of controls. Oversight takes reviewer time, adds latency and requires engineering effort. The framework discusses costs in case material, but it does not price the recommended controls. I still have to decide which controls are proportionate and how people will use them under real workload.

That last point matters. A control people routinely work around may look complete in a diagram while failing in practice. Designing a usable review process is part of the architecture.

What I took into my work

I read this framework as guidance, not as certification of a system. Citing it does not establish that a control works, and a technically sound audit trail can still record a poor decision.

The useful changes were specific. I revisited where permission was enforced, gave more attention to oversight measurements and became clearer about the evidence needed to reconstruct an action.

The question I am still working on is reversibility. Identifying an action as hard to undo is only the start. Designing a safe holding state or a compensation path could change how much intervention it needs.

That is where the framework becomes useful to me: when a recommendation leads to a design decision I can build, inspect and test.

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. This analysis is based on version 1.5. Launch announcement · Framework (PDF)