How to Implement SAFR: Architecture, Patterns, and Build vs Buy

The SAFR reference architecture¶

SAFR "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." The design goal, in the paper's words: "no agentic action reaches execution without having been declared, authorised, and assessed." An implementation is a pipeline with a fixed order, and an audit log that records every stage of it.

The pipeline runs as follows. The agent proposes an action. Before anything executes, the proposal is packaged in a Governance Envelope carrying three classes of information: the action itself (type, scope, parameters), the action trace (the steps the agent actually executed in arriving at the proposal, including tool calls made, data retrieved, and checks performed), and context metadata (agent identity, applicable mandate, current account or system state, and operative policy constraints). The envelope is validated for completeness and coherence. Agent Identity then verifies the proposing agent against the authoritative registry; a failed verification means immediate rejection, recorded in the Audit Log. The Controls Repository identifies which of the institution's controls apply. The Disposition Engine evaluates the action against those controls and returns one of four binding outcomes: Deny, Escalate, Auto-Execute, or Observe. Financial rails execute if and only if the outcome permits, and the Audit Log records the full governance trace for every outcome, denials included.

Envelope integrity is a first-order design problem. The action trace and the action details are both agent-declared, and a sophisticated adversarial injection can fabricate them together. The paper's requirement: "The envelope is therefore treated as a document to be authenticated against its origin, not merely as a record of what the agent reported." In practice this pushes implementers toward capturing the envelope at a point the agent cannot forge — inside the execution path, or at the network boundary — and it is the strongest argument for choosing your deployment pattern deliberately.

Native or gateway: choosing a deployment pattern¶

The white paper defines two integration patterns, and most institutions will end up running both. SAFR, explained covers the mechanics of each pattern, envelope emission in the agent and gateway interception at the infrastructure layer; the implementation decision is when to choose which.

The sequencing guidance comes straight from the paper: "For institutions with many existing agents, the gateway pattern serves as a practical starting point by establishing coverage first and native instrumentation can follow for new builds." Concretely: new capabilities get native instrumentation from day one, and the existing estate gets a gateway in front of it. Run both patterns against one controls repository, one disposition engine, and one audit log, so a mixed estate produces a single consistent governance record.

What to encode in SAFR controls¶

A control in SAFR encodes five things: permitted action types, decision logic, escalation conditions, a validity period, and the principal authority under which the agent acts. Controls draw on four sources: organizational policies, regulatory requirements, product rules, and user-provided mandates.

The mandate is the anchor. "A mandate is the mechanism through which a user defines the bounds of the authority delegated to an agent" — explicit and machine-readable: what the agent may do, within what limits, under what conditions. "An agent cannot extend the scope of a mandate through its own reasoning or inference." The design lineage is capability-based security, the model that underlies OAuth 2.0; the paper cites the Agent Payments Protocol (AP2), with its cryptographically signed mandates, as a prominent industry example.

The paper groups controls into four categories:

Calibrating controls for a treasury payments agent¶

Here is what that looks like calibrated for a treasury payments agent. The values are illustrative; set yours from your delegated authority framework.

For a compliance-triage agent — alert enrichment, risk disposition proposals, filing preparation — the controls that carry the load are evidence-quality thresholds: auto-closure of an alert requires the evidence contract to be met at or above threshold, proposed high-risk dispositions escalate to a named reviewer, and any action that would suppress an open alert is denied outright. We walk that workflow end to end, through all four components, in SAFR for AML and compliance triage.

Calibrating the four dispositions¶

Every in-scope action resolves to one of four outcomes from the Disposition Engine:

All four outcomes feed the Audit Log. Assignment is driven by five calibration factors the paper names: action reversibility, financial materiality, customer impact severity, regulatory sensitivity, and novelty or anomaly — departure from 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, which is why the pilot plan below budgets a full week for tuning against real traffic.

Observe deserves deliberate design attention: it lets a new control run against live traffic and generate structured review material while execution continues, the natural setting for thresholds you intend to tighten after seeing real behavior.

Escalation operations: design them before go-live¶

The paper describes today's typical escalation as a notification, an email alert, or a dashboard flag — no deadline, no standard decision format, no audit record: "the appearance of human oversight without the substance of it." A SAFR implementation replaces that with a designed operation, along three dimensions.

Volume. "An escalation function that generates more reviews than the institution can meaningfully process defeats its own purpose." Size thresholds against actual reviewer capacity; if simulation produces more Escalate outcomes than the team can clear, fix the controls before launch.

Turnaround. Every escalation should carry a timeout window. If no decision arrives within it, the default is to block the action or escalate to a senior reviewer. Set the window from realistic reviewer availability, including overnight and weekend coverage.

Authority. Reviewers need clear authority to approve, modify, or decline, and their decisions "carry the same institutional weight as the original agent decision." That implies named individual reviewers, recorded rationale on every decision, and role definitions that map onto your existing approval hierarchy.

Re-authorize every step¶

In multi-step workflows, the control flow applies to each agent action independently. "An Auto-Execute or Observe outcome at one step carries no authority into the next," because the agent adapts to intermediate results and changing conditions as it works.

This single sentence has large implementation consequences. The evaluation path must be fast enough to run on every action, so latency belongs in the engineering budget from the start. Mandates must be resolvable per action. Session-level approval caching is ruled out by design. And a ten-step workflow produces ten governance traces, each with its own envelope, disposition, and basis — exactly what an inspector reconstructing the run will want.

The evidence layer: the SAFR Audit Log¶

Each Audit Log entry captures six things: the governance envelope as submitted, the mandate against which the action was checked, the outcome produced by the Disposition Engine, the specific rules applied, the basis for that outcome, and the time elapsed at each stage. The log is immutable, tamper-evident, and append-only. The paper's standard: "The log is the authoritative record, independent of any party with an interest in how events are characterised after the fact."

That standard sits above what ordinary application logging provides, and three properties need engineering from the outset: append-only writes, so records accumulate and never mutate; tamper evidence, in practice cryptographic chaining, so any alteration of a past record is detectable; and independent verifiability, meaning an auditor can confirm the integrity of an exported record without access to the platform that produced it. Persist the evidence before returning the disposition. If an action can execute while its record is still in flight, a crash can leave executed actions with no governance trace.

Build vs buy for the SAFR runtime layer¶

SAFR is a reference approach, and the software choice is left open. Disclosure before the analysis: KLA is a vendor in this category. KLA Control Plane implements the SAFR pattern, shipping today. Read what follows with that in mind.

Building in-house means standing up six subsystems:

The six subsystems together are a platform-scale build, and the realistic planning unit is team-quarters. The work also continues after launch: calibration is an operating activity, because thresholds move with transaction volumes, product changes, and reviewer capacity.

Building makes sense when you have a deep in-house platform team that will own the layer as a product, when your rails or settlement infrastructure are bespoke enough that an off-the-shelf checkpoint cannot sit in front of them, or when adjacent systems you already operate (entitlements, case management, policy tooling) cover real parts of the table above.

Buying makes sense when the priority is governed coverage and exportable evidence within a quarter, when there is no platform team available to own six subsystems, or when auditors will ask for independently verifiable records sooner than an in-house roadmap can deliver them.

The hybrid is often the honest answer: buy the runtime checkpoint — registry, disposition engine, escalation workflow, evidence store — and keep controls authoring in-house. The split matches SAFR itself: the framework standardizes the data structures and contracts, while rule configurations and governance arrangements remain the institution's. Under a hybrid, your risk and compliance teams own what the controls say, and the vendor operates the machinery that enforces and evidences them.

For the record on KLA specifically: KLA Control Plane maps component for component — Agent Registry, Policy Builder, KLA Policy Engine, Audit Trail — with the four dispositions expressed as allow, warn, require_approval, and block. Per-action authorization, fail-closed evaluation, and Sealed Evidence Bundles with offline verification are shipped. Aggregate exposure windows, per-window rate limits, confidence thresholds as a routing primitive, per-class escalation timeout defaults, and the standalone gateway are in development. The component-by-component map, with status flags on every requirement, is on our SAFR implementation page.

A four-week SAFR pilot¶

A credible first implementation fits in four weeks on one scoped workflow, and the plan works whether the layer underneath is built, bought, or hybrid.

Before week one, score where you stand. The SAFR Readiness Checklist is an interactive gap assessment across eight sections, from agent identity through deployment pattern, with the evidence an assessor would ask for attached to every question.