The agent has finished the analysis. That does not mean it should move the money. A persuasive recommendation and permission to act are two different things. Singapore's agentic-AI frameworks put that distinction in focus: who sets the boundary, when does a human step in, and what record survives the decision?
This is not just a banking question. An agent might send a customer message, change an account, release a refund or write to a production system. The practical problem is the same: a useful assistant becomes a business actor when it can change something outside the conversation.
Two documents. Different jobs. No new AI law.
IMDA's Model AI Governance Framework for Agentic AI provides a structured overview of agentic risks and emerging practices for managing them. MGF version 1.5 was published on 20 May 2026 and updated on 5 June 2026. It is a living governance framework, not a new AI law.
The broader MGF asks organisations to make humans meaningfully accountable. That means thinking about the agent's powers, technical controls and significant checkpoints, not merely putting a person's name on an ownership chart. IMDA also highlights automation bias: stronger-looking outputs can make human review less sceptical precisely when scrutiny matters.
On 3 July 2026, MAS published Safeguards for Agentic Finance at Runtime, or SAFR. This industry-developed framework was jointly developed by the financial industry under MAS' BuildFin.ai initiative. It focuses on authorising agent actions, activating human oversight and recording decisions in financial services.
Be precise about its status. SAFR is explicitly not regulatory guidance or supervisory expectations. The MAS announcement describes governance checkpoints before task execution. Publication by MAS does not turn the paper into a statutory mandate. Existing legal and sector obligations still need a separate assessment for your institution, activity and deployment.
Use MGF for the wider organisational conversation and SAFR for the finance-specific lens. Our existing Singapore SAFR runtime-readiness page provides finance-specific context. This guide connects the two; it does not replace that page or declare your system compliant.
The SGD 1.2 million question
Picture a hypothetical treasury assistant. It has reviewed liquidity and proposes releasing SGD 1.2 million. The analysis looks convincing. Without a checkpoint connected to the execution path, the application could treat that recommendation as sufficient authority to send the payment. That is the risk in this illustration, not a reported incident or a demonstrated live treasury workflow.
Now separate the story from the actual test. In an isolated HaltState evaluation, an authored policy set an SGD 1 million threshold for a payment-release request in Singapore dollars, with specified region and requester-role conditions. The synthetic SGD 1.2 million request matched that policy. The returned decision was APPROVAL_REQUIRED.
That threshold was chosen for the demonstration. It is not an IMDA or MAS payment limit. The test did not show an agent analysing liquidity, selecting an approver or deciding which actions are irreversible. It showed a policy evaluation against authored conditions.
No money moved. No human approval was completed. No payment or approval workflow was exercised, and no irreversibility classifier was proved. A decision saying approval is required is not evidence that a reviewer received the request, considered it or authorised execution. Those are separate integration and operating questions.
A verified digest is not a compliance certificate
The saved hash-only record captures the decision, policy version and operation reference. Its content digest verified, with independent review recomputing the original digest and policy version. That supports a narrow claim about the recorded content's internal consistency.
It does not prove a signature, authenticated issuer, trusted timestamp, tamper-proof storage or compliance certification. Nor does one positive synthetic case establish production readiness, bypass resistance or correct behaviour across every request. Keeping those limits visible makes the evidence useful. Stretching them makes it marketing fiction.
Put the checkpoint where the action happens
For your own deployment, start with an inventory of actions, not another slide about responsible AI. Name what the agent can change, which system performs the change and who owns that system. Set explicit conditions for permission, review and refusal. Treat those as customer-owned design decisions, informed by risk and applicable obligations.
Then trace the execution path. Where is the decision requested? What happens when approval is required? Can the worker proceed without it? What happens if the decision service is unavailable or the request changes during review? These are questions to test in your integration, not capabilities established by the isolated demonstration.
Finally, decide what reviewers need to see and what records you need to retain. A person cannot be meaningfully accountable with an empty approval screen. A record cannot explain a decision if it loses the policy context. Restrict sensitive content, define access and retention, and involve the people responsible for legal, security and operational review.
Frameworks guide governance. They do not put the checkpoint into your code. HaltState's demonstrated contribution here is the authored-policy decision and its hash-verified record; workflow enforcement still needs wiring and verification. Define the boundary. Keep the record. Keep a human accountable.
Discuss your agent-action boundary with HaltState. Bring one proposed action, its owner and the workflow that would execute it. Start there, not with a claim of certification. This guide is practical governance information, not legal advice.