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

L'architecture de référence SAFR¶

SAFR "se situe entre l'agent et les systèmes sur lesquels il agit, évaluant les actions proposées avant leur exécution, tout en travaillant aux côtés des rails de paiement, des protocoles de règlement, des moteurs de conformité et des systèmes bancaires de base existants." L'objectif de la conception, selon les termes de l'article : « aucune action agentique n'atteint l'exécution 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] (/glossaire/gouvernance-enveloppe) 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. L'exigence du journal : "L'enveloppe est donc traitée comme un document à authentifier quant à son origine, et non simplement comme un enregistrement de ce que l'agent a déclaré." 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.

Les conseils de séquençage proviennent directement du document : "Pour les institutions comptant de nombreux agents existants, le modèle de passerelle sert de point de départ pratique en établissant 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 par lequel un utilisateur définit les limites de l'autorité déléguée à un agent » : explicite et 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 inférence." 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.

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 : "l'apparence d'une surveillance 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 génère plus d'avis que ce que l'institution peut traiter de manière significative 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 n'a aucune autorité sur la 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 : « Le journal est le document faisant autorité, indépendant de toute partie intéressée par la façon dont les événements sont caractérisé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.

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.