SAFR-aligned runtime governance for one financial agent
A SAFR-aligned runtime governance approach for one financial agent. See KLA Runtime capabilities, development status, and a four-week implementation plan.
What SAFR is
SAFR (Safeguards for Agentic Finance at Runtime) is a white paper published in July 2026 under MAS's BuildFin.ai program, written with Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC, and Visa. It describes a reference approach for a runtime governance layer that "sits between the agent and the systems it acts on, evaluating proposed actions before execution." Its central requirement: "no agentic action reaches execution without having been declared, authorised, and assessed." SAFR is an industry reference for institutions to implement within their own infrastructure; the paper states it "does not constitute regulatory guidance or supervisory expectations."
KLA Control Plane provides the controls and evidence patterns used in a SAFR-aligned implementation. The four-week SAFR Production Sprint is a KLA-led engagement around one existing financial agent. Customer-owned-agent governance remains in development while KLA completes its end-to-end qualification. This page separates KLA Runtime capabilities from that path. For a full walkthrough of the framework itself, read SAFR, explained.
The SAFR component map
SAFR defines four runtime components that interact through a Governance Envelope. Each answers one question about a proposed action before it executes. The table maps each component to the KLA Runtime capability that implements it.
| SAFR component | The question it answers | KLA capability | Status |
|---|---|---|---|
| Agent Identity | Is the actor a recognized, registered agent acting under a verified identity? | Agent Registry | KLA Runtime: shipped |
| Controls Repository | What is this agent permitted to do, within what limits, under what conditions? | Policy Builder | KLA Runtime: shipped |
| Disposition Engine | Does this specific action proceed, proceed flagged, pause for review, or stop? | KLA Policy Engine | KLA Runtime: shipped |
| Audit Log | What was decided, on what basis, and can a third party verify it later? | Audit Trail | KLA Runtime: shipped |
Agent Identity → Agent Registry. SAFR requires each proposed action to be bound to a recognized, registered agent, verified against a registry entry before any other evaluation proceeds; a failed check is rejected and recorded. In KLA, every agent is a registered, versioned entity with a named human owner and a release state. The runtime is authenticated and tenant-isolated, and each proposed action arrives bound to a verified agent identity.
Controls Repository → Policy Builder. SAFR's controls repository is the institution's configurable rulebook, drawn from organizational policies, regulatory requirements, product rules, and user-provided mandates. In KLA, policies are versioned and machine-readable, covering permitted tools and action types, decision logic, and escalation conditions. Publishing is a governed release: policies are linted fail-closed, and publication requires two-person approval on the Decision Desk.
Disposition Engine → KLA Policy Engine. SAFR requires deterministic evaluation producing "a defined, binding outcome for every proposed action calibrated to the specific risk it presents." In KLA, every proposed action is evaluated against the published policy version before execution and resolves to one of four decisions. Machine-readable reason codes are required on every decision, and the engine fails closed if the decision service is unreachable.
Audit Log → Audit Trail. SAFR requires an immutable, tamper-evident, append-only record of every governance decision, capturing the envelope as submitted, the mandate checked, the outcome, the rules applied, the basis for the outcome, and the time elapsed at each stage. KLA's Audit Trail is append-only and tamper-evident, recording the action and its parameters, the policy version, the rules fired, the decision with reason codes, and any human approval. It exports as Sealed Evidence Bundles that verify offline, independent of KLA.
The four SAFR dispositions
SAFR's Disposition Engine resolves every in-scope action to one of four outcomes. KLA's decision vocabulary maps to them one to one.
| SAFR disposition | KLA decision | Behavior |
|---|---|---|
| Deny | block | The action is stopped in the execution path. Reason codes are mandatory. |
| Escalate | require_approval | The action pauses. A Decision Request routes to a named, authorized reviewer on the Decision Desk. |
| Auto-Execute | allow | The action proceeds. The decision, its context, and its policy basis are recorded in full. |
| Observe | warn | The action proceeds flagged. A sampling review queue routes sampled runs to a scheduled human spot check. |
All four outcomes are recorded in the Audit Trail. SAFR names five calibration factors that drive outcome assignment: action reversibility, financial materiality, customer impact severity, regulatory sensitivity, and novelty or anomaly relative to established patterns within the mandate. Higher-risk profiles shift outcomes toward Deny or Escalate. Calibration is set at design time through the governance parameters of the controls; in KLA that means the thresholds you author in Policy Builder.
SAFR operating requirements A–H
These are the requirements a SAFR implementation has to meet in operation, and how KLA Runtime meets each one. The customer-owned-agent SAFR Production Sprint remains in development while KLA completes its end-to-end qualification.
| # | Requirement | How KLA meets it | Status |
|---|---|---|---|
| A | Governance Envelope, authenticated by construction: the envelope is "a document to be authenticated against its origin" | KLA Runtime assembles the checkpoint record in the execution path. The customer-owned-agent canonical Governance Envelope is in development. | KLA Runtime: shipped. Customer-owned agent: in development |
| B | Per-action authorization in multi-step work: prior authorization "should not carry forward" between steps | Every KLA Runtime tool call is re-authorized. allow at one step confers no authority at the next. Multi-step Processes permit declared transitions only, require the actor class to match, and keep human-reserved steps architecturally closed to agents. | KLA Runtime: shipped |
| C | Authorization and mandates: explicit, machine-readable delegated authority | KLA Runtime policies bind agents to permitted tools and action types via the Tool Catalog. Connector credentials live per-connection in the Secrets Vault, scoped server-side. Customer-owned-agent mandate lifecycle qualification is in development. | KLA Runtime: shipped. Customer-owned agent: in development |
| D | Exposure limits and rate limits, per-action and aggregate value thresholds, maximum action rates | Per-action thresholds are policy decision logic today. Execution budgets cap steps, spend, and wall clock per run, with an enforced kill switch and incident levers. Aggregate exposure windows and per-window rate limits are being built as policy primitives. | KLA Runtime containment: shipped. Windowed limits: in development |
| E | Evidence quality: minimum evidence and confidence for autonomous execution | Policy can require an AI-judge match between agent output and the expected evidence contract; a mismatch resolves to escalation or block. Content rails for injection, jailbreak, and sensitive-data patterns run in the same path. Confidence thresholds as a first-class routing primitive are being built. | KLA Runtime semantic checks: shipped. Confidence thresholds: in development |
| F | Substantive human escalation: routing, reviewer authority, turnaround | KLA Runtime Decision Requests carry full action context to role-gated, named reviewers. Maker-checker separation is enforced server-side. The bounded SAFR Production Sprint escalation profile is in development. | KLA Runtime: shipped. Sprint profile: in development |
| G | The audit record: tamper-evident, independently verifiable | KLA Runtime returns the decision only once evidence has persisted and fails closed on write failure. The ledger is hash-chained. Customer-owned-agent evidence export qualification is in development. | KLA Runtime: shipped. Customer-owned agent: in development |
| H | Deployment patterns: native instrumentation and gateway interception | Agents on KLA Runtime are governed natively by construction. KLA is qualifying a customer-owned-agent ingress on dev. | KLA Runtime: shipped. Customer-owned agent: in development |
For architecture detail, deployment-pattern selection, and a SAFR vendor build-vs-buy analysis, see How to implement SAFR.
The four SAFR evidence artifacts
A verified SAFR implementation is judged by the records it produces. The white paper puts it directly: "The log is the authoritative record, independent of any party with an interest in how events are characterised after the fact." KLA Runtime produces four kinds of artifact on demand.
- Decision record with reason codes. Every evaluated action resolves to
allow,warn,require_approval, orblock, with machine-readable reason codes, the policy version applied, and the specific rules that fired. - Lineage Record of the action trace. The steps the agent actually executed in arriving at the proposed action (tool calls made, data retrieved, checks performed) preserved as tamper-evident lineage and reconstructable in the Lineage Explorer.
- Decision Desk approval record. For every escalated action: the named reviewer, their role-gated authority, the approve-or-decline outcome, and the recorded rationale, with maker-checker separation enforced server-side.
- Sealed Evidence Bundle, verifiable offline. An export carrying a signed manifest, per-artifact inclusion proofs, and an external timestamp commitment. An auditor, assessor, or counterparty can verify it with no access to KLA.
If a SAFR software vendor or an in-house build cannot produce all four, the audit record has gaps an inspector will find.
The four-week SAFR Production Sprint
The SAFR Production Sprint is a fixed four-week, KLA-led implementation engagement for one qualified financial agent. KLA handles the integration and configuration. The customer brings an existing agent, accountable technical and risk or compliance owners, an authorized reviewer, representative cases or test traffic, and an intended production decision. KLA begins after the gap review confirms a verified integration route.
| Week | Work | Output |
|---|---|---|
| 1 | Confirm the Day 0 scope: one agent, one consequential action, accountable owners, reviewer, systems and data path, deployment route, success measures, and production decision date. | A documented sprint scope and implementation plan |
| 2 | KLA installs the selected path, registers the Agent and mandate, configures controls, and calibrates allow / warn / require_approval / block in Simulation. | A configured path and disposition calibration record |
| 3 | Run representative governed traffic. Named reviewers work Decision Requests. KLA records approvals, no-decision handling, failures, retries, latency, and evidence completeness. | Measured operating results and a reviewable escalation record |
| 4 | Export a Sealed Evidence Bundle for the sprint period. An independent reviewer verifies it offline and records the go, conditional-go, or no-go production recommendation. | An offline verification result and production decision |
For a worked example on a compliance-triage workload (the application class the SAFR paper names among those where governance concerns are heightened) see SAFR for AML.
Downloads and next steps
SAFR: The Executive Briefing (PDF)
Nine pages for decision-makers: what the framework asks of an institution, who owns each part, SAFR beside the EU AI Act and FINMA 08/2024, and a first quarter that ends in verifiable evidence.
Get the briefingSAFR Implementation Map (PDF)
Two pages: the component map, the disposition grammar, and operating requirements A–H with statuses.
SAFR Readiness Checklist
Score your current estate across eight sections: agent identity, mandates, controls, dispositions, envelope and lineage, escalation operations, audit and evidence, deployment pattern. Ungated on the page; the editable sheet downloads via email.
Open the checklistBook a 30-minute SAFR gap review
Bring one existing financial agent, a prospective production window, and the people who can approve its controls. We confirm the integration route and scope the next step.
Book a 30-minute SAFR gap reviewFrequently asked questions
- Is SAFR mandatory?
- No. SAFR is an industry reference that "does not constitute regulatory guidance or supervisory expectations," and adopting it is each institution's own decision. For an implementer the consequence is that the alignment burden sits with you: each institution remains responsible for determining how its deployment aligns with applicable supervisory expectations and internal governance requirements. The operating requirements table on this page is a working checklist for that determination, and the SAFR Readiness Checklist scores your current estate against the same ground.
- Who published SAFR?
- MAS's BuildFin.ai program, with industry members Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC, and Visa: white paper version 1.0, July 2026. For an implementer the working form of that answer is the citation line to carry in internal governance papers that reference a SAFR-aligned build: "Safeguards for Agentic Finance at Runtime, white paper v1.0, MAS BuildFin.ai, July 2026": the same attribution this page carries in its footer. Program background and authorship detail are in SAFR, explained.
- What are the four SAFR dispositions?
- In a KLA implementation they land as the four decisions a published policy resolves to: Deny maps to
block(the action is stopped in the execution path, reason codes mandatory), Escalate torequire_approval(the action pauses while a Decision Request routes to a named reviewer on the Decision Desk), Auto-Execute toallow(the action proceeds with the decision and its policy basis recorded in full), and Observe towarn(the action proceeds flagged, with sampled runs routed to scheduled human spot checks). SAFR's Disposition Engine defines the four outcomes and the five calibration factors that drive them; SAFR, explained covers the definitions. The implementation work is calibration: the thresholds you author in Policy Builder decide where each action class lands, and week two of the pilot plan above is dedicated to tuning that split. - Does KLA replace our compliance platform?
- No. SAFR scopes the runtime governance layer to generate the structured governance record that existing compliance platforms can draw on; it does not replicate their assessments. KLA follows that scoping: transaction monitoring, screening, and case management keep running where they run today, and KLA supplies the per-action decision and evidence record beneath them.
- How long does a SAFR pilot take?
- Four weeks after a gap review confirms one verified integration route and the Day 0 inputs. The sprint covers scope, installation and calibration, representative governed traffic, independent offline verification, and a documented production decision.
- Can existing agents be brought under SAFR governance?
- KLA governs agents on KLA Runtime today. The customer-owned-agent route is in development and is being qualified on dev. KLA scopes an external-agent SAFR Production Sprint after that route has passed its full disposition, approval, revocation, evidence, and offline-verification run.
Source: Safeguards for Agentic Finance at Runtime, white paper v1.0, MAS BuildFin.ai, July 2026. Quoted passages © Monetary Authority of Singapore. SAFR is an industry reference and does not constitute regulatory guidance or supervisory expectations. KLA is independent of and not affiliated with, endorsed by, or certified by MAS or BuildFin.ai.