Kostenloses Tool

SAFR-Reifegrad-Checkliste – Lückenanalyse für die Governance agentenbasierter KI

35 Fragen, aufgebaut auf dem MAS-BuildFin.ai-Whitepaper. Bewertung direkt im Browser. Ohne Anmeldung.

Safeguards for Agentic Finance at Runtime (SAFR) ist das Whitepaper, das die BuildFin.ai-Initiative der MAS im Juli 2026 gemeinsam mit Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC und Visa veröffentlicht hat. Es beschreibt eine Laufzeit-Governance-Schicht zwischen einem KI-Agenten und den Systemen, auf die er einwirkt, und setzt einen einheitlichen Standard für jede vorgeschlagene Aktion: „Keine agentenbasierte Aktion erreicht die Ausführung, ohne deklariert, autorisiert und bewertet worden zu sein.“

Diese Checkliste überträgt diesen Standard in 35 Fragen über acht Abschnitte, entlang der vier Laufzeitkomponenten des Whitepapers – Agentenidentität, Kontrollen-Repository, Dispositions-Engine, Prüfprotokoll – sowie seiner Behandlung von Mandaten, Governance-Umschlägen, Eskalation und Bereitstellung. Jede Frage benennt den Nachweis, den ein Prüfer anfordern würde, sodass eine Antwort mit Ja bedeutet, dass Sie den Nachweis diese Woche vorlegen können.

Antworten Sie mit Ja, Teilweise oder Nein. Die Ergebnisse werden in Ihrem Browser berechnet, pro Abschnitt und insgesamt. Der vollständige Fragenkatalog steht auf dieser Seite; die E-Mail-Abfrage gilt nur für den Download der bearbeitbaren Tabelle. Wenn Ihnen das Rahmenwerk neu ist, beginnen Sie mit SAFR erklärt. Sobald Ihr Ergebnis vorliegt, zeigt der SAFR-Umsetzungsleitfaden, wie Sie jede Lücke schließen, und die Seite SAFR-Umsetzung zeigt, wie KLA Control Plane das Rahmenwerk abbildet.

SAFR readiness: 0%

Assessed 0/35 · 0 gaps

Agent inventory and identity

SAFR's Agent Identity component binds each proposed action to a recognized, registered agent, verified against a registry entry before any other evaluation proceeds.

Do you maintain a complete inventory of every AI agent able to initiate actions against production systems — payments, trading orders, credit approvals, regulatory filings, claims?

Evidence: An export of the inventory listing each agent, the systems it acts on, and its current release state.

SAFR A1

Does every agent in that inventory have a named human owner accountable for its behavior?

Evidence: The registry records showing an owner field populated with a named individual for each agent.

SAFR A2

Is every agent versioned, so any past action can be traced to the specific agent version that produced it?

Evidence: The version history for one agent, and a sample action record referencing the version that acted.

SAFR A3

Where an agent could appear in more than one registry — an internal registry, a payment network's agent registry, an inter-institutional directory — have you determined which registry is authoritative?

Evidence: A written designation of the authoritative registry per agent class, or confirmation that all agents operate in a closed-loop environment against a single internal registry.

SAFR A4

Is agent identity verified against the registry at runtime, before each proposed action is evaluated, with verification failures rejected and logged?

Evidence: A log entry for a rejected action showing failed identity verification as the recorded basis.

SAFR A5

Mandates and authorization

The paper defines a mandate as "the mechanism through which a user defines the bounds of the authority delegated to an agent" — explicit, structured, and machine-readable.

Is the authority delegated to each agent recorded as an explicit, machine-readable mandate stating what the agent may do, within what limits, and under what conditions?

Evidence: One production mandate in the machine-readable form the runtime actually consumes, with the issuing principal identified.

SAFR B1

Are the action types each agent may initiate enumerated in its mandate, with a scope the agent cannot extend through its own reasoning or inference?

Evidence: The mandate's permitted action-type list, plus a test or log showing an out-of-scope action rejected at the checkpoint.

SAFR B2

Is delegation depth defined — who may delegate authority to whom, and how many links a delegation chain may carry?

Evidence: The authorization rules covering delegation, with the maximum chain depth stated.

SAFR B3

Does every mandate carry a validity period, with actions proposed after expiry rejected until the mandate is renewed?

Evidence: A mandate showing its validity window, and the outcome recorded for an action proposed after expiry.

SAFR B4

Can a mandate be revoked or suspended with immediate effect, applying from the next proposed action?

Evidence: The revocation procedure, and a test record showing an action under a revoked mandate rejected.

SAFR B5

Controls repository

The Controls Repository is the institution's configurable rulebook, drawn from organizational policies, regulatory requirements, product rules, and user-provided mandates.

Are the controls governing agent actions held in one designated repository, and does the runtime evaluation read from it?

Evidence: The repository location, and a configuration or trace showing the evaluation path retrieves controls from it.

SAFR C1

Is every control versioned, so any past decision can be traced to the exact control version in force when it was made?

Evidence: The version history for one control, and a decision record citing the version applied.

SAFR C2

Is publishing a control change a governed release, reviewed and approved by a second person before it takes effect?

Evidence: The approval record for the most recent control change, showing author and approver as different people.

SAFR C3

Do the controls cover all four sources SAFR names — organizational policies, regulatory requirements, product rules, and user-provided mandates?

Evidence: One example control per source, mapped to its origin in the repository.

SAFR C4

Disposition engine

The Disposition Engine evaluates each in-scope action against the retrieved controls, producing "a defined, binding outcome for every proposed action calibrated to the specific risk it presents."

Is every in-scope proposed action evaluated deterministically against the controls before it executes — identical envelope, mandate, and control version producing an identical outcome?

Evidence: An execution trace showing the checkpoint positioned ahead of the action with no bypass route, plus a repeat-evaluation test confirming determinism.

SAFR D1

Can the evaluation return all four SAFR dispositions — Deny, Escalate, Auto-Execute, and Observe?

Evidence: One logged decision of each type, or configuration showing all four outcomes reachable.

SAFR D2

Does every outcome record the specific rules applied and a machine-readable reason for the result?

Evidence: A decision record showing rule identifiers and reason codes alongside the outcome.

SAFR D3

Are the thresholds that assign outcomes calibrated on the factors SAFR names — action reversibility, financial materiality, customer impact severity, regulatory sensitivity, and novelty?

Evidence: The calibration parameters for one agent workflow, with the rationale recorded for each threshold.

SAFR D4

If the evaluation service is unreachable or errors, is the proposed action blocked by default?

Evidence: A failover or chaos test record showing an action held or rejected while evaluation was unavailable.

SAFR D5

Governance envelope and lineage

Before an action executes it is packaged in a Governance Envelope — the action, the trace of how the agent arrived at it, and the context needed to assess it — "treated as a document to be authenticated against its origin."

Does each proposed action carry a trace of the actual steps the agent executed in arriving at it — tool calls made, data retrieved, checks performed?

Evidence: A captured action trace for one production or pilot action, showing the ordered tool-call sequence.

SAFR E1

Does the envelope carry context metadata: the agent identity, the applicable mandate, current account or system state, and operative policy constraints?

Evidence: A sample envelope with all four metadata fields populated.

SAFR E2

Is the envelope authenticated against its origin, so a trace and action declared together by a compromised agent would be caught before evaluation?

Evidence: A description of the authentication mechanism — for example, envelope assembly at an interception point in the execution path — and the adversarial test that exercised it.

SAFR E3

Can the full lineage of any completed action be reconstructed afterward — every step, decision, and data access, in order, from the stored record alone?

Evidence: A lineage reconstruction for one past action, produced without reference to application logs or to the agent itself.

SAFR E4

Escalation operations

SAFR names three operational dimensions for escalation — volume, turnaround, and reviewer authority — and warns that ad hoc escalation yields "the appearance of human oversight without the substance of it."

Does an escalated action pause and route to a named, authorized reviewer as a structured decision request with the full action context attached?

Evidence: One escalation record showing the held action, the assigned reviewer, and the context packaged with the request.

SAFR F1

Do reviewers hold clear authority to approve, modify, or decline, with their decisions carrying the same institutional weight as the original agent decision?

Evidence: A role definition granting reviewers that authority, with their decisions binding on the workflow.

SAFR F2

Is maker-checker separation enforced by the system, barring the initiator of an action from approving it?

Evidence: A test record showing a self-approval attempt rejected by the platform.

SAFR F3

Does every escalation carry a timeout window with a defined default when no decision arrives in time — block, or escalation to a senior reviewer?

Evidence: The timeout and default outcome configured per decision class, with coverage rules for overnight and weekend hours.

SAFR F4

Have you sized expected escalation volume against actual reviewer capacity, including peak periods?

Evidence: A volume forecast at expected traffic set beside the reviewer roster, with turnaround data from a pilot or production period.

SAFR F5

Audit and evidence

The Audit Log is the record every other component feeds — "the authoritative record, independent of any party with an interest in how events are characterised after the fact."

Is every governance decision — all four outcomes, including Auto-Execute and Observe — written to an append-only, tamper-evident log?

Evidence: The log design (hash chaining or equivalent) and one sample entry per outcome type.

SAFR G1

Does each entry capture what SAFR requires: the envelope as submitted, the mandate checked against, the outcome, the specific rules applied, the basis for the outcome, and the time elapsed at each stage?

Evidence: One complete log entry showing all six elements.

SAFR G2

Can you export the governance record for a given agent, period, or case in a form an auditor or supervisor can work with?

Evidence: One export produced end to end, with the elapsed time to produce it.

SAFR G3

Can a third party verify the integrity of an exported record without access to your systems?

Evidence: An offline verification run against an exported bundle, with the verifier's output attached.

SAFR G4

Deployment pattern

SAFR defines two integration patterns — native instrumentation and gateway interception — and requires per-action authorization across multi-step work.

Have you chosen an integration pattern for each part of the agent estate: native instrumentation for agents you build, gateway interception for existing and third-party agents?

Evidence: The pattern decision recorded per agent class, with the rationale for each.

SAFR H1

Does a coverage plan establish governance over the existing agent estate first, with native instrumentation following for new builds?

Evidence: The rollout plan listing every currently ungoverned agent and its target coverage date.

SAFR H2

In multi-step workflows, is each action authorized independently, with an Auto-Execute or Observe outcome at one step carrying no authority into the next?

Evidence: A multi-step run record showing a separate evaluation and outcome at every step.

SAFR H3

Prioritised gaps

35 item(s) to address

Do you maintain a complete inventory of every AI agent able to initiate actions against production systems — payments, trading orders, credit approvals, regulatory filings, claims? — Not assessed
Does every agent in that inventory have a named human owner accountable for its behavior? — Not assessed
Is every agent versioned, so any past action can be traced to the specific agent version that produced it? — Not assessed
Where an agent could appear in more than one registry — an internal registry, a payment network's agent registry, an inter-institutional directory — have you determined which registry is authoritative? — Not assessed
Is agent identity verified against the registry at runtime, before each proposed action is evaluated, with verification failures rejected and logged? — Not assessed
Is the authority delegated to each agent recorded as an explicit, machine-readable mandate stating what the agent may do, within what limits, and under what conditions? — Not assessed
Are the action types each agent may initiate enumerated in its mandate, with a scope the agent cannot extend through its own reasoning or inference? — Not assessed
Is delegation depth defined — who may delegate authority to whom, and how many links a delegation chain may carry? — Not assessed
Does every mandate carry a validity period, with actions proposed after expiry rejected until the mandate is renewed? — Not assessed
Can a mandate be revoked or suspended with immediate effect, applying from the next proposed action? — Not assessed
Are the controls governing agent actions held in one designated repository, and does the runtime evaluation read from it? — Not assessed
Is every control versioned, so any past decision can be traced to the exact control version in force when it was made? — Not assessed
+ 23 more in the export.

Export your scored assessment and prioritised gap list. Everything stays in your browser — nothing is uploaded.

So lesen Sie Ihr Ergebnis

Ja = 2, Teilweise = 1, Nein = 0. Die Ergebnisse sind Prozentsätze der verfügbaren Punkte, pro Abschnitt und insgesamt.

Grundlegende Lücken

0–39 %

Ergebnisse in dieser Spanne weisen auf fehlende Strukturen hin: ein Agenteninventar mit benannten Verantwortlichen, maschinenlesbare Mandate und einen Kontrollpunkt, der Aktionen vor ihrer Ausführung bewertet. Solange diese fehlen, haben Dispositionskalibrierung und Nachweis-Tools nichts, woran sie ansetzen könnten. Beginnen Sie mit den Abschnitten A und B – erfassen Sie jeden Agenten, der eine Aktion auslösen kann, benennen Sie für jeden einen Verantwortlichen, und halten Sie seine delegierte Befugnis als Mandat fest. Der SAFR-Umsetzungsleitfaden gibt die Reihenfolge vor.

Teilweise Abdeckung

40–75 %

Die Kernstrukturen sind vorhanden, mit Lücken, die ein Prüfer bereits in der ersten Stunde findet: über den Agentencode verstreute Kontrollen, Eskalationen ohne Standard-Timeout, ein Prüfprotokoll, das keine externe Partei verifizieren kann. Schließen Sie zuerst den am schlechtesten bewerteten Abschnitt; jeder Abschnitt entspricht einem Arbeitsstrang in dem Umsetzungsleitfaden. Bewerten Sie nach jedem Arbeitsstrang neu.

Pilotbereit

76–100 %

Die von SAFR beschriebenen Strukturen sind weitgehend vorhanden. Die verbleibende Arbeit ist Kalibrierung: Dispositionsschwellen, abgestimmt auf den Live-Verkehr, Eskalationsvolumen, dimensioniert auf die Kapazität der Prüfer, Nachweis-Exporte, getestet mit den Auditoren, die sie später nutzen. Ein vierwöchiger, gesteuerter Pilot für einen Agenten-Workflow ist ein realistischer nächster Schritt; die Seite SAFR-Umsetzung stellt einen davon Woche für Woche vor.

Verwandeln Sie das Ergebnis in eine Arbeitssitzung

Eine 30-minütige Lückenanalyse-Sitzung gleicht Ihre am schlechtesten bewerteten Abschnitte mit KLA Control Plane ab, das das SAFR-Muster umsetzt und bereits im Einsatz ist. Die Sitzung greift Ihre Ergebnisse pro Abschnitt auf und ordnet jede Lücke einer konkreten Kontrolle zu.

30-minütige SAFR-Lückenanalyse buchen

Bearbeitbare Checkliste herunterladen

Dieselben 35 Fragen als Tabelle: eine Zeile pro Frage mit Nachweishinweis sowie Spalten für Status, Verantwortlichen und Notizen und eine Bewertung pro Abschnitt. Für interne Lückenanalysen konzipiert.

Wird verwendet, um die Datei zu senden, und für höchstens eine Nachfrage.

Über das Rahmenwerk

SAFR – Safeguards for Agentic Finance at Runtime – wurde im Juli 2026 von der BuildFin.ai-Initiative der MAS veröffentlicht, gemeinsam mit acht Branchenmitgliedern, darunter HSBC, J.P. Morgan Chase, Mastercard und Visa. Es ist ein Referenzansatz, den Institute innerhalb ihrer eigenen Infrastruktur umsetzen können. Das Whitepaper stellt klar, dass es „keine regulatorische Vorgabe oder aufsichtsrechtliche Erwartung darstellt“.

SAFR erklärt – das vollständige Rahmenwerk

Was ein gutes Ergebnis liefert

Eine hier gut bewertete Umsetzung kann einem Prüfer auf Anfrage vier Artefakte vorlegen: einen Entscheidungsdatensatz mit maschinenlesbaren Gründen, eine rekonstruierbare Spur der tatsächlich vom Agenten ausgeführten Schritte, einen Genehmigungsdatensatz mit Namen des Prüfers und seiner Begründung sowie einen Nachweis-Export, den ein Dritter offline verifizieren kann. Die Abschnitte D bis G prüfen jeweils dafür.

SAFR-Umsetzung, Komponente für Komponente

Lücken schließen

KLA Control Plane setzt das SAFR-Muster um und ist bereits im Einsatz: Agent Registry für die Identität, Policy Builder für das Kontrollen-Repository, KLA Policy Engine für die Dispositionen, Audit Trail für den Nachweisdatensatz. Eine dreißigminütige Sitzung deckt einen gesteuerten Durchlauf von Anfang bis Ende ab: Richtlinie, Entscheidung, Eskalation, versiegelter Nachweis.

SAFR-Umsetzung mit KLA Control Plane 30-minütige SAFR-Lückenanalyse buchen

FAQ

Häufig gestellte Fragen

Ist dies eine offizielle MAS-Bewertung?

Nein. Dies ist eine Selbstbewertung, aufgebaut auf den im SAFR-Whitepaper definierten Strukturen, ohne offiziellen Status. SAFR selbst ist eine Branchenreferenz – das Whitepaper stellt klar, dass es „keine regulatorische Vorgabe oder aufsichtsrechtliche Erwartung darstellt“ – und jedes Institut bleibt selbst dafür verantwortlich, zu bestimmen, wie seine Umsetzung mit den geltenden aufsichtsrechtlichen Erwartungen und internen Governance-Anforderungen übereinstimmt. KLA ist unabhängig von der MAS und BuildFin.ai.

Wann sollten wir mit Teilweise antworten?

Antworten Sie mit Teilweise, wenn die Fähigkeit nur einen Teil des Agentenbestands abdeckt, nur in einem Pilotprojekt läuft oder ohne den unter der Frage genannten Nachweis vorliegt. Der Nachweishinweis ist der Test: Ja bedeutet, dass Sie das Artefakt einem Prüfer diese Woche übergeben könnten.

Wer sollte die Checkliste ausfüllen?

Drei Rollen decken sie ab: die Person, die die Agentenplattform verantwortet, die Person, die die relevanten Compliance-Kontrollen verantwortet, und die Person, die den Prüfbetrieb leitet. Jede Frage wird mit Ja, Teilweise oder Nein beantwortet, ein erster Durchgang geht also schnell; die eigentliche Prüfzeit steckt in den Nachweishinweisen. Die Ergebnisse werden in Ihrem Browser berechnet; die E-Mail-Abfrage gilt nur für den Tabellen-Download.

Was sollten wir mit den vom Ergebnis aufgezeigten Lücken tun?

Nehmen Sie zuerst den am schlechtesten bewerteten Abschnitt. Jeder Abschnitt entspricht einem Arbeitsstrang in dem SAFR-Umsetzungsleitfaden; bewerten Sie nach jedem Arbeitsstrang neu, und die Aufschlüsselung nach Abschnitt zeigt, wo sich das Ergebnis verändert hat. Eine Lücke gilt als geschlossen, sobald Sie das unter der Frage genannte Nachweisartefakt vorlegen können.

Haftungsausschluss: Selbstbewertung anhand von Safeguards for Agentic Finance at Runtime, Whitepaper v1.0 (Juli 2026), MAS BuildFin.ai. Zitierte Passagen unterliegen dem Urheberrecht der Monetary Authority of Singapore. SAFR ist eine Branchenreferenz und stellt keine regulatorische Vorgabe oder aufsichtsrechtliche Erwartung dar. KLA ist unabhängig von der MAS und BuildFin.ai und steht mit keiner der beiden in Verbindung, wird von ihnen nicht unterstützt und ist von ihnen nicht zertifiziert.