Singapore Listed Ten Ways to Control an Agent. Human Approval Is Only One of Them.

The 2026 Singapore Consensus on Global AI Safety Research Priorities was published in July 2026, the outcome of the second International Scientific Exchange on AI Safety, held from 17 to 19 May 2026. It is an agenda document. It says what the people who showed up think the field should work on, and it carries more than 100 contributors from 13 countries, drawn from frontier developers, government safety institutes, academia and civil society.

The 2026 edition does two things the previous one did not. It adds a fourth pillar on societal resilience. And it ships a Companion Report on Agentic Risk Management, published by the Singapore AI Safety Institute, which analyses emerging practices in managing risk from autonomous agents using input from leading model and agent developers, academic research and existing agentic governance frameworks.

That companion report is what this piece is about, and I want to be exact about one thing before going further. What follows is an account of a governance document. It is not a regulation, not a binding standard, and not evidence that anything described in it is running anywhere. A great deal of the report is a survey of what other people already do.

Ten principles, grouped by when they bite

The companion report proposes managing agentic risk through ten foundational principles, and it arranges them across the lifecycle of an agentic system rather than listing them flat.

• Design and development. Least privilege, traceable identity, auditability.
• Testing and deployment. Validated deployment, adversarial resilience, multi agent stability.
• Operation and monitoring. Runtime assurance, interruptibility, legibility, human oversight.

For each principle the report sets out governance context across jurisdictions including the United States, China, Singapore and the European Union, and then describes technical practices being used to address it. It is a map of a field, assembled from the people currently in it.

Read the list once for content and you get a competent inventory of agent safety concerns. Read it a second time for shape and something else appears.

Human oversight is one line on a list of ten

Human oversight is the tenth item. It sits in the operation and monitoring group, alongside runtime assurance, interruptibility and legibility. It is not the frame the other nine hang from. It is a peer.

Most agent governance writing does the opposite. It treats human approval as the control, and everything else as plumbing that helps the human approve well. This document does not. Least privilege decides what the agent can reach before anyone is asked to approve anything. Traceable identity decides whether the question "who did this" has an answer. Auditability decides whether the answer survives. Interruptibility decides whether a decision can be unwound while it is still happening. Human oversight decides who is asked, and when.

What the oversight principle actually asks for

The report's account of human oversight is built around defined checkpoints and escalation pathways, with human approval required for high risk actions. It also states the thing most oversight guidance leaves implicit: oversight has to be scalable to remain practical in production, and agentic behaviour may change over time and across contexts, so oversight continues after deployment rather than ending at it.

The part I find most useful is that the report describes oversight as a sliding scale rather than a switch. At one end, full independence for low risk actions. At the other, manual approval of every step in high risk settings. Everything in between is a calibration.

Notice what the scale is indexed against. It is indexed against the risk of the action, not against a trust level assigned to the agent. Those are different designs, and the difference is not cosmetic. A trust level attached to an agent says this agent is now permitted to operate with less supervision. A calibration attached to an action says this particular thing, in this particular setting, needs a person. The second one survives an agent that behaves impeccably for six weeks and then encounters something novel. The first one does not.

Moona Intelligence has argued a version of this before, from a different direction, when a vendor put a hard check outside the model rather than trusting a system prompt, and again when the question was what a long running agent is allowed to do between the moment you authorised the goal and the moment it finishes.

Stopping is a separate principle from approving

Interruptibility gets its own line, and this is the part of the ten that does the most work.

The report calls for standardised mechanisms enabling trusted and authorised overseers to safely stop both an individual agent action and the overall agent execution. It notes that it may be necessary to grant some of those permissions to automated safety oversight systems as well, which would be able to react at superhuman speeds. And it pairs stopping with safe resumption, so that activity can be robustly resumed if analysis concludes the interruption was unwarranted.

Three things in that paragraph are worth slowing down for.

The first is the phrase trusted and authorised overseers. The ability to stop is described as a permission somebody holds. It is not a property of the agent's own good behaviour, and it is not the same permission as the one used to approve the agent's work. Somebody is authorised to halt this thing, and the report treats identifying that somebody as part of the design.

The second is the concession about speed. If the stop permission may need to go to an automated system because a human cannot react fast enough, then human oversight and interruptibility are not two names for the same control. They cannot be. One of them is being explicitly contemplated as something no human will be executing.

The third is resumption. A stop that cannot be safely undone is expensive enough that nobody uses it, which is how kill switches quietly become decorative. Designing the resume alongside the stop is what makes the stop usable more than once.

This is the same seam Moona Intelligence has tracked elsewhere. An assessment of frontier developers was built around the distinction that watching an agent is not the same as stopping it, and a gateway product was interesting mainly because it put the approval decision somewhere the agent's builder could not skip. Singapore's report reaches the same distinction from the governance side and writes it into the list as two entries instead of one.

What happens when the agent is not alone

Multi agent stability is also its own principle, and it sits in testing and deployment rather than in operation. The report's framing is that harm in these systems emerges from interaction failures across agents and tools rather than from a single bad decision by one agent.

That is a claim about where to look, and it is not the same claim as saying each agent should be well behaved. Traceable identity and auditability are in the first group for a related reason: if you cannot say which actor took an action, and the actor may be an agent that another agent created, then every downstream control is guessing about its subject. We have written about what happens when an agent creates another agent and nobody has decided which permissions came with it.

The report also spreads responsibility rather than assigning it. Managing agentic risk, on its account, is distributed across model and agent developers, deployers, cloud platform providers and the open source ecosystems the components come from. It surfaces open problems instead of resolving them. For a document assembled from the practices of the companies currently shipping this software, that is the honest shape.

What this document is not

Several limits are worth stating plainly, because this is the sort of publication that gets cited loosely.

It is not law and it is not regulation. Singapore's AI Safety Institute is not regulating anyone with it, and no organisation is obliged to do any of this. It is a consensus research agenda with a companion analysis attached.

It is not a conformance standard either. Nothing in the ten principles is written as a testable requirement with a pass condition, and the report does not certify or assess anybody against them.

And it is not evidence of production enforcement. The companion report describes technical practices drawn from industry. A practice being described in a survey of what developers say they do is documentation, not demonstration. Moona Intelligence keeps those three categories apart on purpose: governance guidance, technical implementation and demonstrated enforcement are three different claims, and this document is firmly in the first.

What we could not verify

The primary destinations for this report, the Singapore Consensus site and the Singapore AI Safety Institute site, are both blocked at the network egress policy for the session in which this piece was researched, and neither the publication page nor the report PDF could be fetched. Everything above rests on repeated, independently phrased searches whose results were consistent with each other across separate queries. The full basis is recorded in the source notes below, and an editor with unblocked access should read the report itself.

Two consequences follow, and both belong in the piece rather than in a footnote.

The exact publication date is not established here. Index listings and reporting seen this session place the release in July 2026, with individual dates ranging from the seventh to the sixteenth of that month. This piece says July 2026 and no more precise than that.

Several specific claims circulating about this report could not be confirmed against it. In particular, we could not establish that the report defines shutdown and override as system level privileges sitting outside the agent's own reasoning loop, that it assigns intervention responsibility to whoever controls the execution environment, that its interruptibility principle covers redirecting and reversing actions or requires the agent to be unable to tamper with the stop mechanism, that it requires an orchestration layer to maintain coherent oversight across a delegation chain or across organisational boundaries, that approval requirements may be relaxed on the basis of demonstrated agent performance, or that it describes a convergence toward agents pausing before consequential actions and resuming on an explicitly recorded human decision. Those are all plausible readings of the principles as named. None of them is asserted here, because none of them was confirmed, and a governance document is exactly the sort of source people quote at each other later.

The button was never the control

Strip out the jurisdictional survey and the ten principles say something fairly blunt about the current state of agent control.

The approval prompt is one component. It sits downstream of what the agent was allowed to reach, alongside the separate question of who can halt it, and upstream of whether anyone can reconstruct the decision afterwards. Build only the prompt and you have built the part of the architecture that is easiest to see and least able to act on its own.

That is not Singapore's phrasing. It is what falls out of a list that puts human oversight tenth.