Comment implémenter SAFR : architecture, modèles et construction par rapport à l'achat

L'architecture de référence SAFR¶

SAFR se place entre l'agent et les systèmes sur lesquels il agit : il évalue les actions proposées avant leur exécution et fonctionne aux côtés des rails de paiement, des protocoles de règlement, des moteurs de conformité et des systèmes bancaires centraux existants. L'objectif de conception énoncé par l'article : aucune action agentique n'est exécutée sans avoir été déclarée, autorisée et évaluée. Une implémentation est un pipeline avec un ordre fixe et un journal d'audit qui en enregistre chaque étape.

Le pipeline fonctionne comme suit. L'agent propose une action. Avant que quoi que ce soit ne soit exécuté, la proposition est conditionnée dans une enveloppe de gouvernance contenant trois classes d'informations : l'action elle-même (type, portée, paramètres), la trace de l'action (les étapes réellement exécutées par l'agent pour arriver à la proposition, y compris les appels d'outils effectués, les données récupérées et les vérifications effectuées) et les métadonnées de contexte (identité de l'agent, mandat applicable, compte actuel ou état du système et contraintes de politique opérationnelle). L'enveloppe est validée pour son exhaustivité et sa cohérence. Agent Identity vérifie ensuite l'agent proposant par rapport au registre faisant autorité ; un échec de vérification signifie un rejet immédiat, enregistré dans le journal d'audit. Le référentiel de contrôles identifie les contrôles de l'institution qui s'appliquent. Le moteur de disposition évalue l'action par rapport à ces contrôles et renvoie l'un des quatre résultats obligatoires : Refuser, Escalader, Exécuter automatiquement ou Observer. Les rails financiers s'exécutent si et seulement si le résultat le permet, et le journal d'audit enregistre la trace complète de gouvernance pour chaque résultat, refus inclus. Sources : source

L'intégrité des enveloppes est un problème de conception de premier ordre. La trace de l’action et les détails de l’action sont tous deux déclarés par l’agent, et une injection contradictoire sophistiquée peut les fabriquer ensemble. La version 1.1 est directe sur ce point : l'enveloppe de gouvernance ne doit pas être tenue pour auto-vérifiante. Lorsque c'est possible, les champs fournis par l'agent doivent être vérifiés par rapport à des enregistrements capturés indépendamment de l'agent, tels que l'instruction initiale, la charge utile réelle de l'action et les enregistrements générés par le système des appels d'outils et des accès aux données, et l'enveloppe doit être liée à l'agent, à la session et au mandat vérifiés. En pratique, cela pousse les implémenteurs à capturer l'enveloppe à un point que l'agent ne peut pas forger (à l'intérieur du chemin d'exécution ou à la limite du réseau) et c'est l'argument le plus fort en faveur du choix délibéré de votre modèle de déploiement.

Natif ou passerelle : choisir un modèle de déploiement¶

Le livre blanc définit deux modèles d'intégration, et la plupart des institutions finiront par utiliser les deux. SAFR, expliqué couvre la mécanique de chaque modèle, l'émission d'enveloppe dans l'agent et l'interception de passerelle au niveau de la couche infrastructure ; la décision de mise en œuvre est de savoir quand choisir lequel.

La version 1.1 ajoute un point sur la topologie : SAFR n'impose pas de le mettre en œuvre sous la forme d'une plateforme centrale unique au sein de l'institution. Ses composants peuvent fonctionner comme un service central, au sein de déploiements d'agents individuels, comme des services institutionnels partagés ou de manière hybride, à condition que chaque action dans le périmètre passe par les fonctions SAFR requises avant exécution et que chaque mise en œuvre suive des normes communes pour les enveloppes, les résultats de disposition, la sémantique des contrôles et l'auditabilité.

Les conseils de séquençage proviennent directement du document : pour les institutions qui comptent déjà de nombreux agents, le modèle de passerelle est un point de départ pratique, car il établit d'abord la couverture, et l'instrumentation native peut suivre pour les nouvelles versions. Concrètement : les nouvelles capacités bénéficient d'une instrumentation native dès le premier jour, et le parc existant dispose d'une passerelle devant lui. Exécutez les deux modèles sur un référentiel de contrôles, un moteur de disposition et un journal d'audit, afin qu'un domaine mixte produise un seul enregistrement de gouvernance cohérent.

Ce qu'il faut encoder dans les contrôles SAFR¶

Un contrôle dans SAFR code cinq éléments : les types d'actions autorisés, la logique de décision, les conditions d'escalade, une période de validité et l'autorité principale sous laquelle l'agent agit. Les contrôles s'appuient sur quatre sources : les politiques organisationnelles, les exigences réglementaires, les règles relatives aux produits et les mandats fournis par les utilisateurs.

Le mandat est l'ancre. Un mandat est le mécanisme qui délimite l'autorité déléguée et l'exprime sous une forme lisible par machine : ce que l'agent peut faire, dans quelles limites, sous quelles conditions. Un agent ne peut pas étendre la portée d'un mandat par son propre raisonnement ou ses propres inférences. La lignée de conception est la sécurité basée sur les capacités, le modèle qui sous-tend OAuth 2.0 ; le document cite le Protocole de paiement des agents (AP2), avec ses mandats signés cryptographiquement, comme exemple marquant du secteur.

Le document regroupe les contrôles en quatre catégories :

Calibrage des contrôles pour un agent de paiement du Trésor¶

Voici à quoi cela ressemble calibré pour un agent de paiement du Trésor. Les valeurs sont illustratives ; définissez le vôtre à partir de votre cadre d’autorité déléguée.

Pour un agent de tri de conformité (enrichissement des alertes, propositions de disposition à risque, préparation du dépôt), les contrôles qui portent la charge sont des seuils de qualité des preuves : la clôture automatique d'une alerte nécessite que le contrat de preuve soit respecté au niveau ou au-dessus du seuil, les dispositions à haut risque proposées sont transmises à un réviseur nommé et toute action qui supprimerait une alerte ouverte est purement et simplement refusée. Nous parcourons ce processus de bout en bout, à travers les quatre composants, dans SAFR pour AML et triage de conformité.

Calibrage des quatre dispositions¶

Chaque action dans le champ d'application se résout en l'un des quatre résultats du Disposition Engine :

Les quatre résultats alimentent le journal d'audit. L'attribution est déterminée par cinq facteurs d'étalonnage que le document nomme : la réversibilité de l'action, la matérialité financière, la gravité de l'impact sur les clients, la sensibilité réglementaire et la nouveauté ou l'anomalie : écart par rapport aux modèles établis au sein du mandat. Les profils à risque plus élevé orientent les résultats vers Refuser ou Escalader. L'étalonnage est défini au moment de la conception via les paramètres de gouvernance des contrôles, c'est pourquoi le plan pilote ci-dessous prévoit une semaine complète pour l'ajustement du trafic réel.

Observe mérite une attention particulière en matière de conception : il permet à un nouveau contrôle de s'exécuter sur le trafic en direct et de générer du matériel de révision structuré pendant que l'exécution se poursuit, le paramètre naturel pour les seuils que vous avez l'intention de resserrer après avoir constaté un comportement réel.

Calibrez à partir de l'historique. Lors d'un exercice d'intégration bancaire mené dans nos propres tenants de test en octobre 2026, avec des personas scriptés pour l'administrateur de la banque, le responsable conformité et l'approbateur, nous avons conclu que les cas de test de politique construits à la main avec de nombreux champs ne sont pas praticables : un responsable conformité n'écrira pas de tests unitaires pour une politique. Ce qui fonctionne, c'est de rejouer les exécutions récentes contre les contrôles en projet et de montrer l'écart avec ce qui s'est passé, par exemple combien d'actions supplémentaires seraient passées en examen humain. Ce chiffre répond à la question de la capacité des examinateurs, et il doit être présenté aux personnes qui staffent la file d'attente.

Opérations de remontée : concevez-les avant la mise en service¶

Le document décrit l'escalade typique d'aujourd'hui comme une notification, une alerte par courrier électronique ou un indicateur de tableau de bord, sans date limite, sans format de décision standard, sans enregistrement d'audit, soit l'apparence d'une supervision humaine sans sa substance. Une mise en œuvre SAFR remplace cela par une opération conçue, selon trois dimensions.

Volume. Une fonction d'escalade qui produit plus d'avis que l'institution ne peut en traiter sérieusement va à l'encontre de son propre objectif. Seuils de taille par rapport à la capacité réelle des évaluateurs ; si la simulation produit plus de résultats d'escalade que l'équipe ne peut en obtenir, corrigez les contrôles avant le lancement.

Redressement. Chaque escalade doit comporter une fenêtre de délai d'attente. Si aucune décision n’y parvient, la valeur par défaut est de bloquer l’action ou de la transmettre à un réviseur senior. Définissez la fenêtre de disponibilité réaliste des évaluateurs, y compris la couverture de nuit et de week-end.

Autorité. Les évaluateurs ont besoin d'une autorité claire pour approuver, modifier ou refuser, et leurs décisions ont le même poids institutionnel que la décision initiale de l'agent. Cela implique des évaluateurs individuels nommés, une justification enregistrée pour chaque décision et des définitions de rôles qui correspondent à votre hiérarchie d'approbation existante.

Réautoriser chaque étape¶

Dans les processus en plusieurs étapes, le flux de contrôle s'applique indépendamment à chaque action d'agent. Un résultat d'exécution automatique ou d'observation à une étape ne vaut pas autorisation pour l'étape suivante, car l'agent s'adapte aux résultats intermédiaires et aux conditions changeantes au fur et à mesure de son fonctionnement.

Cette seule phrase a d'importantes conséquences sur la mise en œuvre. Le chemin d’évaluation doit être suffisamment rapide pour s’exécuter sur chaque action, de sorte que la latence fait partie du budget d’ingénierie dès le départ. Les mandats doivent pouvoir être résolus par action. La mise en cache d’approbation au niveau de la session est exclue par conception. Et un flux de travail en dix étapes produit dix traces de gouvernance, chacune avec sa propre enveloppe, disposition et base : exactement ce que voudra un inspecteur reconstruisant l'analyse.

La couche de preuves : le journal d'audit SAFR¶

Chaque entrée du journal d'audit capture six éléments : l'enveloppe de gouvernance telle que soumise, le mandat par rapport auquel l'action a été vérifiée, le résultat produit par le moteur de disposition, les règles spécifiques appliquées, la base de ce résultat et le temps écoulé à chaque étape. Le journal est immuable, inviolable et ne peut être ajouté qu'en ajout. La norme du journal : il fait autorité et reste indépendant de toute partie intéressée par la façon dont les événements seront qualifiés après coup.

Cette norme se situe au-dessus de ce que fournit la journalisation d'application ordinaire, et trois propriétés nécessitent une ingénierie dès le départ : les écritures en ajout uniquement, de sorte que les enregistrements s'accumulent et ne subissent jamais de mutation ; preuve d'altération, en pratique chaînage cryptographique, de sorte que toute altération d'un enregistrement passé soit détectable ; et vérifiabilité indépendante, ce qui signifie qu'un auditeur peut confirmer l'intégrité d'un enregistrement exporté sans accéder à la plateforme qui l'a produit. Conservez les preuves avant de rendre la décision. Si une action peut s'exécuter alors que son enregistrement est encore en cours de vol, un crash peut laisser les actions exécutées sans trace de gouvernance.

Un mandat et un enregistrement de décision détaillés¶

L'exemple ci-dessous est synthétique. Northbridge Bank est fictive, et les noms, montants et identifiants sont illustratifs. Il reprend le calibrage de trésorerie ci-dessus et suit un mandat de la délégation jusqu'aux preuves.

Le mandat. Le responsable des opérations de trésorerie de Northbridge délègue les paiements fournisseurs et intragroupe à un agent enregistré, treasury-payments, version 3.2. Le mandat est la limite écrite de cette délégation. L'institution le rédige à partir de son cadre de délégation de pouvoirs existant, le versionne et l'approuve selon la même revue que pour les changements de politique.

La limite de délégation et les quatre résultats¶

Les deux dernières lignes du mandat tracent la limite de délégation. Tout ce qui se trouve au-delà est refusé, quel que soit le raisonnement de l'agent, car un agent ne peut pas étendre la portée d'un mandat par son propre raisonnement ou ses propres inférences. À l'intérieur de la limite, les contrôles classent chaque action proposée dans l'une des quatre dispositions SAFR. KLA Control Plane exprime ces quatre mêmes résultats sous la forme allow, warn, require_approval et block.

Quatre actions proposées par l'agent au cours d'une même matinée illustrent chaque résultat. Chaque ligne a été évaluée isolément, sans aucune autorité reprise de la ligne précédente.

Un cas d'approbation de bout en bout¶

09:41. L'agent propose le paiement de 118 000 US$. L'enveloppe contient l'ordre de paiement, la trace d'action (recherche de facture, recherche de contrat, vérification du bénéficiaire) et le contexte : identité de l'agent, mandat version 2 et total sur 24 heures à ce stade de 212 000 US$. La vérification d'identité réussit. Le contrôle par action renvoie Escalate ; le contrôle cumulé passe, avec une marge restante de 170 000 US$ après ce paiement.

09:41. L'action est retenue. Une demande d'examen part vers le groupe d'approbateurs de la trésorerie avec l'action proposée, la facture et les contrôles déclenchés. Northbridge fixe un délai de quatre heures pour cette catégorie d'escalade, avec block par défaut.

10:17. Un responsable de trésorerie ouvre la demande, compare la facture au bon de commande et au contrat-cadre de services, et approuve avec la justification « Renouvellement annuel de licence ; PO 4471 et clause 6.2 du MSA conformes à la facture INV-20931. » L'approbation porte sur ce seul paiement.

10:17. Le paiement est transmis au rail, qui renvoie une référence de paiement. L'enregistrement se clôt avec le résultat d'exécution.

Deux choix de conception de ce cas viennent d'un Process de libération de paiements retenus que nous avons construit dans notre propre tenant de démonstration pour un briefing d'analystes en octobre 2026, avec des paiements synthétiques. D'abord, chaque décision humaine a exactement une porte d'approbation. Notre première soumission de ce Process en revue a été rejetée parce que deux étapes humaines portaient aussi un indicateur d'approbation distinct, ce qui aurait créé deux tâches d'approbation pour une seule décision ; nous avons retiré les indicateurs et gardé une porte par décision. Ensuite, la politique dirige tout cas qu'aucune règle n'a prévu vers require_approval. Dans notre toute première politique de test LCB-FT, le résultat par défaut sans correspondance était block, si bien que les cas imprévus s'arrêtaient sans jamais atteindre un examinateur.

Si le responsable n'avait pas répondu avant 13:41, la demande aurait expiré et l'action aurait été bloquée, avec l'expiration enregistrée. S'il avait refusé, l'agent aurait reçu un block accompagné du motif de l'examinateur, et une nouvelle proposition pour le même paiement aurait été évaluée depuis le début.

Les preuves laissées par le cas¶

SAFR liste les éléments que chaque entrée d'audit doit capturer : l'enveloppe telle que soumise, le mandat au regard duquel l'action a été vérifiée, le résultat, les règles spécifiques appliquées, le fondement du résultat et le temps écoulé à chaque étape. Le cas d'approbation y ajoute la décision humaine et le résultat d'exécution. Le tableau présente l'enregistrement du paiement de 118 000 US$.

L'approbation et le règlement sont des enregistrements distincts. Dans la démonstration des paiements retenus, l'approbation de libération et le statut de règlement confirmé sont deux entrées séparées, et un paiement n'est terminé que lorsque la référence de règlement est enregistrée. Nous les séparons parce qu'une approbation prouve une décision et que seul le rail peut confirmer que l'argent a circulé.

Trois limites font partie de toute lecture honnête de cet enregistrement. Il montre ce que l'agent a proposé, quelles règles se sont appliquées, qui a décidé et ce que le rail a renvoyé. Il ne montre pas que le fournisseur a reçu les fonds ; cela relève des enregistrements de règlement et de rapprochement. Il ne prouve pas non plus que la facture est authentique ; le contrôle de qualité des preuves vérifie la correspondance, et les contrôles antifraude se situent ailleurs dans le processus de paiement. Un auditeur doit pouvoir lire ces limites dans l'enregistrement sans avoir à poser la question.

Créer ou acheter pour la couche d'exécution SAFR¶

SAFR est une approche de référence et le choix du logiciel reste ouvert. Divulgation avant l'analyse : KLA est un fournisseur dans cette catégorie. KLA Control Plane implémente le modèle SAFR, disponible aujourd'hui. Lisez ce qui suit en gardant cela à l’esprit.

Construire en interne signifie mettre en place six sous-systèmes :

Les six sous-systèmes constituent ensemble une construction à l'échelle d'une plate-forme, et l'unité de planification réaliste est constituée des quartiers d'équipe. Le travail se poursuit également après le lancement : l'étalonnage est une activité opérationnelle, car les seuils évoluent avec les volumes de transactions, les changements de produits et la capacité des examinateurs.

La construction a du sens lorsque vous disposez d'une équipe de plate-forme interne approfondie qui sera propriétaire de la couche en tant que produit, lorsque vos rails ou votre infrastructure de règlement sont suffisamment sur mesure pour qu'un point de contrôle standard ne puisse pas s'asseoir devant eux, ou lorsque les systèmes adjacents que vous exploitez déjà (droits, gestion de cas, outils politiques) couvrent de vraies parties du tableau ci-dessus.

L'achat a du sens lorsque la priorité est une couverture régie et des preuves exportables dans un délai d'un trimestre, lorsqu'il n'y a pas d'équipe de plate-forme disponible pour posséder six sous-systèmes, ou lorsque les auditeurs demandent des enregistrements vérifiables de manière indépendante plus tôt qu'une feuille de route interne ne peut les fournir.

L'hybride est souvent la réponse honnête : achetez le point de contrôle d'exécution (registre, moteur de disposition, processus d'escalade, magasin de preuves) et conservez la création des contrôles en interne. Cette répartition correspond à celle du SAFR lui-même : le cadre standardise les structures de données et les contrats, tandis que les configurations de règles et les modalités de gouvernance restent celles de l'institution. Dans un système hybride, vos équipes de gestion des risques et de conformité sont propriétaires de ce que disent les contrôles, et le fournisseur exploite les mécanismes qui les appliquent et les prouvent.

Pour l'enregistrement sur KLA en particulier : KLA Control Plane mappe composant pour composant (Agent Registry, Policy Builder, KLA Policy Engine, Audit Trail) avec les quatre dispositions exprimées comme autoriser, avertir, require_approval et bloquer. L'autorisation par action, l'évaluation fermée après échec et les Sealed Evidence Bundle avec vérification hors ligne sont expédiés. Les fenêtres d'exposition globales, les limites de débit par fenêtre, les seuils de confiance en tant que primitive de routage, les délais d'expiration par classe par classe et la passerelle autonome sont en cours de développement. La carte composant par composant, avec des indicateurs d'état pour chaque exigence, se trouve sur notre page implémentation SAFR.

Un pilote SAFR de quatre semaines¶

Une première mise en œuvre crédible s'inscrit en quatre semaines sur un processus ciblé, et le plan fonctionne si le la couche en dessous est construite, achetée ou hybride.

Avant la première semaine, marquez votre position. La Liste de contrôle de préparation SAFR est une évaluation interactive des lacunes répartie en huit sections, de l'identité de l'agent au modèle de déploiement, avec les preuves qu'un évaluateur demanderait en pièce jointe à chaque question.