What SAFR is
SAFR puts a checkpoint between what an AI agent decides and what actually executes. The framework in plain language, then in detail.
- Agent proposes action
- Governance Envelopeaction · action trace · context metadata
- Agent Identityverified against the registryfail → Deny + logged
- Controls Repositorywhich controls apply
- Disposition Engineresolves to exactly one outcome
- Auto-Execute→ Financial rails
- Observe→ Financial rails (flagged)
- Escalate→ Human reviewer
- Deny→ Rejected with reason
In one paragraph
AI agents in finance increasingly act instead of advise: they initiate payments, submit orders, approve applications. SAFR puts a checkpoint between what an agent decides and what actually executes. Before any action goes through, the agent must declare what it wants to do and why. The system then checks who the agent is, what it's allowed to do, and how risky the action is, and decides one of four things: let it run, let it run but watch it, hold it for a human, or refuse it. Every decision is recorded in a log that can't be quietly edited.
Why it exists
Whitepaper pp. 3–6
- Agents are now capable of planning steps, selecting tools, and initiating actions without continuous human direction.
- In finance, actions are regulated, affect customers directly, and are often hard to reverse.
- Per-action human review is operationally impossible at agent volume and speed.
- Correlated agent behaviour across institutions is a potential systemic vulnerability, as the FSB has noted.
- Guardrails on model output are probabilistic. They can't on their own enforce the precise numerical and policy constraints that financial actions require.
The Governance Envelope
Whitepaper p. 8
The Governance Envelope is the single structured record an agent submits with every proposed action. It contains three classes of information:
Class | Contents |
|---|---|
Action | Action type, scope, parameters |
Action trace | The steps the agent actually executed: tool calls, data retrieved, checks performed |
Context metadata | Agent identity, applicable mandate, account or system state, operative policy constraints |
For technical readers: the envelope is agent-declared, so it can be fabricated in an internally consistent way by a sophisticated injection. The paper therefore treats it as a document to be authenticated against its origin, not simply as a report to be trusted.
The four components
Whitepaper pp. 7–12
- Agent Identity. Verifies the proposing agent against its registry entry before anything else happens. In closed-loop settings this is a direct lookup. In open networks, the component must also decide which of several registries is authoritative. Failure means rejection, and the rejection is logged.
- Controls Repository. The institution's configurable rulebook. Controls come from organisational policy, regulation, product rules, and user mandates. Generic controls (authorisation, exposure limits) are typically deterministic. AI-specific controls (evidence quality, envelope integrity) may involve probabilistic or semantic assessment.
- Disposition Engine. Evaluates the action against the retrieved controls and resolves it to exactly one outcome.
- Audit Log. A tamper-evident, append-only record of every governance decision, regardless of outcome.
The four outcomes
Whitepaper pp. 10–11
Outcome | Meaning |
|---|---|
Deny | Violates a hard constraint or exceeds risk thresholds. Rejected with a specific reason. |
Escalate | Within scope but above the autonomous threshold. Held for human review. |
Auto-Execute | Within scope, below hard constraints, within risk thresholds. Proceeds. |
Observe | Proceeds, but flagged and logged for later review. |
Calibration factors named in the paper: action reversibility, financial materiality, customer impact severity, regulatory sensitivity, and novelty or anomaly. Thresholds are set at design time and subject to review before deployment.
Mandates
Whitepaper p. 10
A mandate is the machine-readable record of the authority a user delegates to an agent: what it may do, within what limits, under what conditions. It follows the capability-based security model, in which authority is held in a bounded token. The agent can't widen a mandate through its own reasoning.
Per-action evaluation
Whitepaper p. 12
In multi-step workflows, every step is evaluated independently. An Auto-Execute at step 3 grants nothing at step 4. This is the single most important architectural rule for implementers.
Implementation patterns
Whitepaper p. 15
- Native integration: the agent emits an envelope before each action. Recommended for new builds.
- Gateway integration: a gateway intercepts outbound API calls and wraps them in envelopes. Suited to legacy and third-party agents.
Human escalation that actually works
Whitepaper p. 16
Three dimensions the paper says institutions must assess:
- Escalation volume: can reviewers keep up?
- Review turnaround: timeouts that default to block or to a senior reviewer.
- Reviewer authority: reviewers must be empowered to approve, modify, or decline.
Industry examples
Whitepaper pp. 17–20
The whitepaper illustrates the components with case studies from Ant International, Mastercard, Visa, Circle, OCBC/Bank of Singapore, and Manulife, plus a corporate banking example. Read them in the whitepaper itself.
[TODO: add a short table mapping each case study to the SAFR components it illustrates, in our own words, with page references.]