MAS SAFR Agentic AI Safeguards: What Banks Should Build at Runtime

MAS's SAFR white paper proposes a checkpoint that rules on each AI agent action in a bank or insurer before it executes. The checkpoint verifies the agent, checks the action against the institution's rules, rules on it and logs it. It is voluntary and explicitly not supervisory guidance. Read it anyway if you run or supply agents to a Singapore financial institution. It is the most detailed public design we have seen for governing an agent at the moment it acts, and it points to the controls worth building first: mandates, exposure limits, escalation with a timeout, and a log the agent cannot edit.

The timing matters. MAS published SAFR on 3 July 2026, eight days after announcing the Future of Finance Institute, which will support SAFR adoption through pilots and sandbox testing. MAS's own AI risk guidelines, which name AI agents in scope, closed consultation on 31 January 2026 and had not been issued as of 30 July 2026.

What is MAS SAFR, and is it binding?

SAFR (Safeguards for Agentic Finance at Runtime) is a voluntary white paper, not a rule. The Monetary Authority of Singapore published Version 1.0 on 3 July 2026 under its BuildFin.ai initiative, with contributions from Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC and Visa. The paper says it "does not constitute regulatory guidance or supervisory expectations."

SAFR is easy to mistake for MAS rules because MAS published it. The SAFR white paper, Version 1.0, July 2026 also says it does not "prescribe or anticipate future directions" for guidance, and each institution "remains responsible for determining how its deployment aligns with applicable supervisory expectations." This is general information, not legal advice.

Why care, then? MAS's 3 July 2026 media release says SAFR builds on the Project MindForge AI risk toolkit "with a focus on how safeguards can be operationalised at the point of action for AI agents." Mastercard and Visa describe their own agent designs in its case studies, and we expect bank procurement questionnaires to borrow its vocabulary.

The gap SAFR targets is timing. Model risk frameworks validate a model before go-live, and audit samples transactions after the fact. Neither stops a bad agent decision before it executes.

How does the SAFR checkpoint rule on each agent action?

SAFR inserts a governance checkpoint between an agent's proposed action and its execution, built from four runtime components: Agent Identity, Controls Repository, Disposition Engine and Audit Log. The agent packages each proposal in a governance envelope, and the engine returns one of four outcomes: Deny, Escalate, Auto-Execute or Observe, per the July 2026 paper.

The governance envelope is a structured record submitted with each proposed action: the action, the trace of steps that led there, and context such as identity and mandate. A mandate is the user's delegated authority in machine-readable form: what the agent may do, within what limits. The Disposition Engine is the rule evaluator; the paper says it "evaluates the proposed action deterministically against the controls," so a fixed limit always gets the same ruling. Some inputs are softer: AI-specific controls such as evidence quality "may involve probabilistic or semantic assessment." Use those scores as inputs to a rule, never as the rule.

Authority does not carry forward. "An Auto-Execute or Observe outcome at one step carries no authority into the next." Clearance to fetch a client's statement is not clearance to move the client's money three steps later.

The agent's own account is not evidence. The paper concedes that an agent's declared trace and its proposed action "can be fabricated together" by a sophisticated adversarial injection (hostile instructions slipped into the agent's inputs). The envelope must be "authenticated against its origin," and the audit log must let reviewers reconstruct events "without relying on the agent's own account."

Guardrails are a different layer. The paper is blunt: "Guardrails on model output are therefore not a substitute for runtime governance of financial action." A system prompt that says "never pay more than S$5,000" is a request. A disposition rule is a control.

Which runtime controls should you configure first?

SAFR's Table 1 lists four control categories an institution configures: authorisation, exposure limits, rate limits and evidence quality. The paper calls these "some of" the categories, says configuration "should be owned by the institution's risk and compliance leadership," and says exposure limits mirror existing delegated authority frameworks and "should be set to match them."

That is the shortcut. Your bank already keeps a delegated authority matrix, the table of who may approve how much. Make each agent one more row in it, and thresholds start from numbers risk has already signed.

The build list below draws on the whole paper, not only Table 1. The "what it stops" wording is our paraphrase; the ownership column is our reading.

Writing a mandate exposes what nobody decided. The paper lists what a control encodes: permitted action types, decision logic, escalation conditions, validity period and principal authority.

Illustrative example: an accounts-payable agent at a mid-size insurer. Permitted action: pay invoices already matched to a purchase order. Decision logic: up to S$20,000 per payment and S$150,000 per day. Escalation conditions: a new payee bank account, or any invoice above S$20,000. Validity: 90 days, then re-approval. Principal authority: the head of finance operations, who can revoke it. Numbers are made up. Each field has an owner who can say no.

One counter-intuitive detail: Table 1's evidence quality control routes actions to review when "the agent's stated confidence" falls below a threshold. Stated confidence is agent-declared, the same category of input the paper warns can be fabricated. Our reading: let a low score push an action toward review, and never let a high score lift it past an exposure limit.

The audit log has a spec worth copying. Each entry should hold the envelope as submitted, the mandate checked, the outcome, the specific rules applied, the basis for the outcome and the time elapsed at each stage. The last field doubles as a latency monitor.

For a CTO, the practical decision is the integration pattern. Native integration instruments the agent to emit an envelope before each action and is recommended for new builds. Gateway integration intercepts the agent's outbound API calls at the infrastructure layer, with no change to agent code, and is "designed for legacy systems, third party agents or existing deployment." For institutions with many existing agents, the paper calls the gateway a practical starting point. We agree: it forces the inventory you need anyway.

How do you size human review so it is not a rubber stamp?

Human review breaks when escalations outrun the people who must answer them. SAFR's July 2026 paper names three design tests: an escalation volume the institution can process, a review timeout after which the action defaults to block or goes to a senior reviewer, and reviewers with authority to approve, modify or decline.

The paper's diagnosis of current practice: notifications with "no defined deadline for response" and "no audit record of the decision made." In its words, "This gives the appearance of human oversight without the substance of it." MAS's consultation paper on AI risk management guidelines, 13 November 2025 points the same way. Its proposed human oversight section asks firms to take account of "automation bias and decision fatigue" and to give reviewers "the necessary authority and ability to intervene."

The volume test is arithmetic, and most designs fail it.

Illustrative example: an insurer's claims agent proposes 8,000 actions a day. Thresholds that escalate 4% send 320 actions to people. At 4 minutes per review, that is about 21 reviewer-hours a day, roughly three full-time reviewers across shifts. Loosen the evidence-quality threshold so 10% escalate and the load becomes 800 reviews and about 53 hours, close to seven people. Few teams staff that, so reviewers start clicking approve. The decision this forces: set the Escalate threshold from reviewer capacity first, route the band just below it to Observe (runs, but flagged for sampled review), and give every escalation a timeout. Numbers are made up for illustration.

A timeout that defaults to approve is not oversight. Default to block, or to a senior reviewer, as the paper says.

SAFR lists five calibration factors for outcomes, and action reversibility comes first. We cover which actions deserve a gate in bounding agentic risk by reversibility, and the reviewer side in designing the confirm step.

How does SAFR sit beside FEAT, TRM and the proposed AI risk guidelines?

SAFR is a voluntary implementation reference that sits beneath MAS's principles and proposed supervisory expectations; it replaces neither. FEAT (2018) states principles, the Technology Risk Management (TRM) Guidelines (18 January 2021, guidelines rather than a Notice) govern IT risk, and the proposed AI Risk Management Guidelines (consulted on from November 2025) would set expectations covering AI agents.

Their legal weight differs, and blurring it is the commonest error in coverage. As of 30 July 2026:

The proposed guidelines fit SAFR closely, if you read the verbs carefully. The consultation warns that "An AI agent granted access to an FI's internal systems might autonomously execute actions misaligned with business objectives or customer interests." It proposes that, where relevant, monitoring cover "reasoning processes, actions taken, tools used." For high-risk-materiality AI it says firms should "consider implementing" kill switches or override mechanisms, and where kill switches exist, test their activation protocols regularly. SAFR's log and rate limits are one buildable answer, not a certified one.

SAFR is not the first word on agent controls. Its own footnote credits the MindForge Operationalisation Handbook (November 2025) with least privilege, kill switches, timeouts and searchable logging for agentic AI. What SAFR adds is the per-action envelope, a disposition on every action and a log the agent does not write. Our piece on MAS AI risk management in 2026 argued the burden had moved from the model to the operating environment; SAFR describes that environment in the most detail yet.

One date to plan around: MAS proposed a 12-month transition after the final guidelines are issued, and as of 30 July 2026 that clock had not started. Implementation detail keeps arriving meanwhile, from the MindForge toolkit release, 20 March 2026 to the Future of Finance Institute announcement, 25 June 2026, which promises an updated toolkit "with implementation guides for deploying agentic AI."

Keep one separate track separate. On 28 July 2026, MAS and the Association of Banks in Singapore set up the AI-Driven Cyber and Technology Risk Taskforce (ACT), with members from DBS, OCBC, UOB, SGX, NETS and BCS. Its subject is attackers using frontier AI, not governance of your own agents. "Frontier AI is increasing the severity, scale and sophistication of cyber threats," said Vincent Loy, MAS's Assistant Managing Director (Technology) and Chief Technology Officer, in the MAS and ABS release of 28 July 2026. ACT will develop guidance; none had been issued by 30 July.

What changes for a mid-size FI and its vendors?

For a mid-size financial institution adopting the SAFR pattern, agent governance moves to risk and compliance, who configure the rules, and into production, where the rules run on every action. Vendors are not regulated by SAFR, but MAS's November 2025 consultation proposes that outsourcing and third-party expectations would apply to third-party AI.

For the MD or CEO, the board question shifts from "did we approve this model?" to "can we show what this agent did last Tuesday, and who could have stopped it?" The audit log is how you answer.

For compliance and risk, the Controls Repository becomes your document: policy expressed as configuration. Hire or train people who read a rule file as easily as a policy.

For the CTO, the work is plumbing: an agent registry, an envelope format, a rules evaluator in the call path, an append-only log store. The checkpoint's uptime becomes a production concern, and the paper does not say what happens when it is down. Decide and document it. Our view: fail closed for anything that moves money, and treat that as your design choice, not a SAFR requirement.

For SME vendors selling agents to banks and insurers, expect diligence questions to change shape. The proposed guidelines ask institutions to test third-party AI in their own context and to receive notifications of updates or changes. SAFR's gateway pattern lets a bank wrap your agent without your code. Make that easy: emit a structured record of each proposed action, accept a machine-readable mandate, and tell the bank before a model change ships.

Where Origin Pi stands

We build agent governance into the call path, the pattern the July 2026 SAFR paper describes. An agent's permissions belong in a layer it cannot talk its way around, and the record of what it did belongs somewhere it cannot write.

We design the agent-ready layer this paper describes in banking terms: bounded permissions expressed as mandates, a confirm step that fires where it is warranted and times out safely, and an audit trail written outside the agent. We go further than the paper on one point: size the human gate from reviewer capacity before setting a single threshold. Cerebrum, our governed business layer, is in build around the same pattern.

Version 1.0 will change. Start anyway: take one agent this week and write its mandate as your delegated authority matrix would: what it may do, up to what amount and until when. Name who signs above that line. If you cannot write it down, the agent should not be acting. Our AI compliance work starts from that exercise.