# MAS SAFR Component Mapping — AgenticRail

> Markdown mirror for AI agents, generated 2026-08-25 from the live page.
> Canonical: https://agenticrail.nz/spec/safr/
> Site context: https://agenticrail.nz/llms.txt

Technical Reference — AgenticRail / MAS SAFR

# MAS SAFR Component Mapping: A Deterministic Pre-Execution Gate

SAFR describes a runtime governance layer that evaluates an agent's proposed action before it executes and records the decision. This page maps its four components and its Governance Envelope onto a deployed system that does the same thing, marks the two requirements SAFR states but leaves to the implementer, and says plainly where the mapping stops.

Mapped against SAFR White Paper Version 1.0, July 2026 · Published 14 August 2026 · Last reviewed 23 August 2026

## 1. What SAFR is

**Safeguards for Agentic Finance at Runtime (SAFR)** is an industry white paper published in July 2026, copyright the Monetary Authority of Singapore, and in its own words “developed through collaboration among financial industry members”. The paper records that it “is written with contributions from” Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC and Visa.

It is a reference architecture, not a rule. The paper states its own status directly:

SAFR, on its own standing

“It does not constitute regulatory guidance or supervisory expectations, nor does it prescribe or anticipate future directions for such guidance or expectations” — and separately, that “each institution remains responsible for determining how its deployment aligns with applicable supervisory expectations and internal governance requirements.”

It is also explicitly a first version. The paper describes itself as “a starting point to support industry discussion”, says it “should evolve through industry input and implementation experience”, and closes by inviting FinTechs and financial institutions to contribute to SAFR and the BuildFin.ai working group by “sharing pilot findings, identifying gaps in the specification, and raising domain requirements not yet addressed”. This page is written in that spirit: it maps where a deployed system meets the specification, and marks two places where the specification states a requirement it does not itself resolve.

Nothing on this page claims compliance with SAFR, alignment endorsed by MAS, or any status conferred by the paper. SAFR confers none. What follows is a component comparison, offered because the architecture SAFR describes and the architecture described in [the AgenticRail specification](https://agenticrail.nz/spec/) resolve the same problem in the same shape, and a reader evaluating either is served by seeing them side by side.

## 2. The four components

SAFR places a governance layer between an agent and the systems it acts on. In the paper's words, it sits “between the agent and the systems it acts on, evaluating proposed actions before execution, while working alongside existing payment rails, settlement protocols, compliance engines, and core banking systems.” Four components carry that:

| SAFR component | What SAFR says it does |
 | Agent Identity | Binds a proposed action to a recognised, registered agent, verified against that agent's registry entry before any other evaluation proceeds. |
 | Controls Repository | The institution's configurable rulebook — the controls against which a proposed action is checked, drawn from organisational policies, regulatory requirements, product rules and user-provided mandates. |
 | Disposition Engine | Evaluates each in-scope action against the retrieved controls and resolves it to one of four outcomes: Deny, Escalate, Auto-Execute, Observe. |
 | Audit Log | A tamper-evident, append-only record of every governance decision. |

The paper's summary of the four together: *“Together, these ensure that no agentic action reaches execution without having been declared, authorised, and assessed.”*

The four do not act on a proposed action directly. They act on a **Governance Envelope**: the components interact, in the paper's words, “through the Governance Envelope as a single, structured record of what the agent intends to do, why it intends to do it, and what evidence supports the decision”. The envelope carries three classes of information — the **action** (type, scope and parameters), the **action trace** (the steps the agent actually executed to arrive at the proposal, including tool calls made, data retrieved and checks performed), and **context metadata** (agent identity, applicable mandate, current state, operative policy constraints). The envelope is where the paper locates a problem worth its own section below.

## 3. Component mapping

SAFRAgent Identity

“For governance to be meaningful, the agent proposing an action must be who it claims to be… If the agent's identity cannot be verified, the Controls Repository cannot be correctly consulted, and the Audit Log cannot capture an accountable record.”

**AgenticRail:** every call carries an API key resolved to a client identity at the boundary, and the resolved identity is written into the signed receipt as `model_id`. An unrecognised credential is served on a clearly-labelled public demonstration lane rather than silently accepted as a known caller, so the identity attached to a receipt is either verified or explicitly marked as unverified. Sequences are scoped to the identity that opened them.

SAFRControls Repository

“The institution's configurable rulebook: the controls… against which a proposed action is checked.”

**AgenticRail:** the caller declares a `step_order` when a sequence opens, and that declared order is locked for the life of the sequence. Action types permitted at each step are resolved from a policy map. The rulebook is therefore supplied by the deploying party and fixed in advance rather than inferred at runtime — which is what makes a later absence detectable.

SAFRDisposition Engine

“The Disposition Engine evaluates the proposed action deterministically against the controls retrieved from the institution's Controls Repository.”

**AgenticRail:** the gate evaluates each step before it runs and returns ALLOW or DENY, with a denial code naming the rule that fired. The evaluation is deterministic: the same payload against the same sequence state produces the same verdict, and no language model is present anywhere in the decision path. SAFR's four outcomes and AgenticRail's decisions are not identical — Escalate and Observe are not implemented as distinct verdicts, and a refusal at the boundary produces a HALT status rather than an enforcement decision.

SAFRAudit Log

“Every governance decision produces an entry in the Audit Log… Once written at the point of decision, an entry cannot be modified by the agent or by any downstream system.”

**AgenticRail:** every decision, including every refusal, produces an Ed25519-signed receipt written at the point of decision and hash-chained to its predecessor. A step that was refused leaves a signed record rather than leaving nothing, which is the property an ordinary log cannot supply. The receipt carries the byte-exact signed preimage and the key identifier, so the signature can be verified offline with no callback.

SAFR names two integration patterns. **Native integration**, where “the agent is instrumented to emit a Governance Envelope before each proposed action”, and **gateway integration**, where “a SAFR gateway intercepts outbound API calls at the infrastructure layer, wrapping each call in a Governance Envelope and evaluating it without any changes to the agent code itself”. AgenticRail is reachable both ways: through client libraries the agent calls before each step, and as an HTTP boundary placed in front of an existing deployment. The paper recommends the gateway pattern as the practical starting point for institutions with agents already running.

## 4. The problem SAFR names inside the envelope

Having defined the envelope, the paper immediately identifies an integrity risk in it — and states that risk more sharply than specifications usually state their own:

SAFR, on the integrity of the envelope

“An agent that produces a governance envelope cannot guarantee that its contents faithfully represent what the original instruction produced. The action trace and action details are both agent-declared contents of the same envelope, and both can be fabricated together by a sophisticated adversarial injection that maintains internal consistency while departing from the original task. The envelope is therefore treated as a document to be authenticated against its origin, not merely as a record of what the agent reported.”

This is the self-attestation problem stated plainly. The party proposing the action is also the party describing it, and a description authored by the actor cannot corroborate the actor. SAFR sets the requirement — authenticate the envelope against its origin — and leaves the mechanism to the implementer, as it does with custody.

**AgenticRail:** the architecture separates the two roles rather than trusting the declaration. In the reference sequence the step that performs work is not permitted to record the result of it — `RECORD_RESULT` is not an allowed action type at the executing step, and witnessing happens at a later, distinct step. When a result is then recorded, it must name the artifact it witnesses, and that pointer is checked two ways: it must equal the last allowed decision that was durably written, and that record is re-fetched and confirmed to exist, to be an allowance, and to be the step immediately preceding the witness. A pointer that matches nothing is refused with a named denial code rather than accepted as an assertion.

What that buys is narrow, and worth stating narrowly. It does not authenticate an agent's account of its own reasoning, and no mechanism can: a trace is a claim by the thing being governed. What it does is stop the actor being the sole author of the record that the action occurred — which is the part of the envelope's integrity risk that a governance layer is actually positioned to address.

## 5. The requirement SAFR states, and what answers it

SAFR is explicit about what the Audit Log is for, and the wording goes further than tamper-evidence:

SAFR, on the purpose of the Audit Log

“For accountability, it is designed to ensure that every action an agent takes, and every decision to allow, deny, escalate, or observe that action, can be fully reconstructed and reviewed without relying on the agent's own account of what occurred. The log is the authoritative record, independent of any party with an interest in how events are characterised after the fact.”

That is a statement about *independence*, not only about integrity. A record can be append-only, cryptographically signed and perfectly tamper-evident, and still be held entirely by the party whose conduct it describes.

SAFR places the Audit Log inside the institution, alongside its compliance platforms, and is explicit that it is not something to be bought: *“Nor is SAFR a managed service. It serves as an industry reference for institutions to implement within their own infrastructure, using their own rule configurations and governance arrangements.”* Every case study in the paper bears that out — Ant International, Mastercard, Visa, Circle, OCBC and Manulife each describe a system they operate themselves. No third-party provider appears anywhere in it.

Which is what makes the requirement worth reading twice. The paper asks for a record independent of any party with an interest in how events are characterised, and then draws that record inside the party the requirement is about. Nothing in the architecture as specified closes that; it is left to be satisfied through deployment.

**AgenticRail's answer is that the evidence is a document, not a location.** A compliance report carries the raw signature, the byte-exact preimage that was signed, and the verifying public keys inline. Checking it needs no callback to AgenticRail, no key and no account — it is an ordinary Ed25519 verification against bytes the reader already holds. The record is therefore portable: the deploying party can give a copy to an auditor, a regulator, a counterparty or a trustee, and that holder can confirm it independently of everyone, including us.

Portability is what answers the custody question rather than deferring it. There is no custodian to appoint and no arrangement to negotiate, because the record does not have to stay anywhere in particular in order to stay checkable. The tamper-evident copy can be held by whoever the institution chooses, including parties the institution does not control.

That also settles the sharpest version of the problem. A party holding the signing keys could in principle re-sign a chain to say something different — which is the objection any hosted evidence service has to answer. What makes it detectable is not an assurance about the key-holder's conduct. It is that somebody else already has the document, and the two copies will not agree. Independence here is a property of where the copies are, not a claim about who we are.

A second measure covers the same risk from the other side. Each sealed sequence is copied to a separate archive under its own credential, with no update or delete route, so a rewrite of the primary store can be detected against a copy held apart from it.

What remains is a matter of practice, and it is worth stating exactly. A production sequence's report is released against the deploying party's API key: verification needs nothing from us, obtaining the document needs something from them. So where the deploying party is itself the party under scrutiny, the copy has to have been taken before the question is asked — at settle, on a schedule, or as a term of the arrangement. The mechanism depends on nobody's good faith. Whether a copy exists on the day it is needed is a deployment decision.

Limits, stated plainly

- SAFR is a white paper. It confers no status and this page claims none.
- SAFR states that it is *not* a managed service, and is intended for institutions to implement within their own infrastructure. AgenticRail is a hosted third party. That is a different deployment shape from the one the paper describes.
- SAFR specifies no ordering between an agent's actions, and no point at which a completed run is closed. Step-order enforcement and sealing are AgenticRail properties, not SAFR requirements.
- AgenticRail is hosted. Today the signing keys are held by AgenticRail, which is a deployment term and not a property of the design.
- The receipt timestamp is supplied by the caller and covered by the signature. It cannot be altered after signing, and the gate refuses any timestamp more than 300 seconds from its own clock; it is not independently attested.
- Escalate and Observe are SAFR outcomes with no direct AgenticRail equivalent. A deployment needing four graded outcomes would need to derive two of them.
- A production sequence's report is released against that deployment's API key. Verification needs nothing from us; obtaining the document needs something from the deploying party.
- No certification, accreditation or third-party assurance is claimed. AgenticRail holds none.

## 6. Where the shapes agree, and where they part

SAFR and AgenticRail were developed independently and converge on the same four requirements: an identity that must be established before evaluation, a rulebook fixed in advance rather than inferred, a deterministic evaluation of each proposed action before it executes, and a tamper-evident record of every decision including the refusals.

They part in one respect worth naming, and it runs the other way. SAFR governs each action independently and says so: *“An Auto-Execute or Observe outcome at one step carries no authority into the next.”* That is authority per action. The specification defines no ordering between actions, no sense in which a step can arrive out of place, and no point at which a run is finished. AgenticRail enforces a declared order across the whole sequence and seals it at the final step, so an action that is individually permissible is still refused if it comes in the wrong position, and a sealed sequence cannot be extended. Those are differences, not deficiencies in the paper — it does not ask for them.

That convergence is the useful part of this page. The architecture is not novel and does not need to be. What varies between implementations is who holds the record afterwards, and whether a party with an interest in the outcome is the only one able to produce it.

References and further reading

Safeguards for Agentic Finance at Runtime, White Paper v1.0, July 2026 — [mas.gov.sg](https://www.mas.gov.sg/publications/monographs-or-information-paper/2026/safeguards-for-agentic-finance-at-runtime)

MAS media release, 3 July 2026 — [MAS partners industry to develop safeguards for AI agents in finance](https://www.mas.gov.sg/news/media-releases/2026/mas-partners-industry-to-develop-safeguards-for-ai-agents-in-finance)

AgenticRail receipt schema — [agenticrail.nz/spec/receipt-schema-v3.json](https://agenticrail.nz/spec/receipt-schema-v3.json)

Worked example with a real sealed sequence — [agenticrail.nz/proof/](https://agenticrail.nz/proof/)

Live compliance report — [report.agenticrail.nz/report](https://report.agenticrail.nz/report)