La pile agentique comporte quatre couches. La plupart des déploiements en omettent trois

L’identité, la réputation, le mandat et le paiement doivent vivre sur la chaîne. Dans de nombreux déploiements en production, ils ne le font toujours pas, et c’est un problème d’architecture, pas une réflexion après coup de conformité.

Je passe beaucoup de temps à examiner comment les déploiements d’agents en production sont réellement câblés, et le schéma est souvent le même: le modèle est performant, le cadre d’orchestration est raisonnable, mais la couche d’authentification reste une clé API partagée qui n’a pas été renouvelée depuis des mois.

L’infrastructure des agents autonomes n’a pas suivi le rythme des modèles qui s’exécutent dessus. La pile agentique comporte quatre composants qui doivent être natifs de la chaîne: identité, réputation, mandat et paiement. Dans la plupart des déploiements en production que je vois, ils sont encore ajoutés a posteriori, voire inexistants.

Et cela est encore plus important dans la finance réglementée que partout ailleurs. Un agent capable de transiger sur des titres tokenisés, d’approuver des actions de trésorerie ou d’allouer des positions doit pouvoir démontrer ce qu’il était autorisé à faire, qui l’a autorisé, dans quelles limites, et où se trouve l’enregistrement on‑chain de cette autorité. La plupart des déploiements ne peuvent pas répondre clairement à cela aujourd’hui. Sans cet enregistrement, l’agent lui‑même représente un risque d’audit et de conformité.

Pourquoi les clés API partagées sont la mauvaise primitive

Le modèle d’authentification que la plupart des déploiements d’agents héritent du SaaS est un secret partagé transmis dans un en‑tête. Il authentifie le service appelant mais ne dit rien sur l’agent spécifique qui effectue l’appel, ni sur ce que cet agent est autorisé à faire, et il ne laisse aucun enregistrement survivant à l’audit sous une forme exploitable par un régulateur. Chaque action d’agent n’est attribuable qu’à celui qui possède la clé, ce qui, en pratique, fait s’effondrer l’attribution dès qu’il y a plus d’un agent ou plus d’un opérateur.

L’alternative est le règlement par signature à chaque requête. Chaque requête est signée par le portefeuille propre de l’agent et réglée cryptographiquement au moment de l’appel. C’est pour cela que x402 est conçu, avec l’authentification et le paiement gérés ensemble. Cela fournit aux institutions un enregistrement du portefeuille qui a agi, du moment où il a agi et de ce qu’il a payé, un registre capable de résister à l’examen d’audit.

Le fossé d’identité

ERC-8004 définit l’identité on‑chain pour les agents sans confiance: un registre où un agent est enregistré avec un portefeuille de contrôle, un point de terminaison de service et une référence de modèle. Aujourd’hui, cet agent n’est qu’un processus opaque fonctionnant au sein de l’infrastructure d’un fournisseur. L’entrée du registre en fait un acteur on‑chain de première classe avec une origine vérifiable — que un contrat intelligent ou un tableau de bord de conformité peut vérifier directement, sans faire confiance à un intermédiaire.

La couche de réputation s’appuie sur cela. Les signaux de rétroaction écrits dans le registre ERC-8004 sont immuables, horodatés et attribuables. Tout système qui souhaite prendre des décisions de confiance concernant un agent peut lire ce registre directement. Contrairement à un score géré par le fournisseur ou à une notation Discord, la confiance ici est une propriété du réseau plutôt que de celui qui contrôle la base de données.

Les deux couches sont implémentables dès aujourd’hui sans ingénierie exotique. La plupart des déploiements ne les possèdent pas parce que le chemin d’implémentation le plus simple consiste encore à traiter les agents comme des comptes de service plutôt que comme des acteurs de première classe. Un raccourci raisonnable dans un prototype devient une dette architecturale qui se cumule en production.

Le problème de mandat est l’endroit où la finance réglementée diverge de tout le reste

L’identité et la réputation vous indiquent qui est un agent et comment il s’est comporté. Elles n’établissent pas ce que l’agent est autorisé à faire. Dans de nombreux cas d’utilisation d’agents, les contrôles au niveau de l’application peuvent combler cette lacune. Pour les agents opérant sur des actifs réglementés, la question de l’autorisation devient une question juridique. La réponse doit exister sous une forme qui puisse satisfaire un régulateur.

ERC-8226, la norme Regulated Agent Mandate Standard (RAMS), est conçue pour combler cette lacune. RAMS définit une couche de délégation de conformité qui se situe entre l’identité de l’agent et les cadres de conformité au niveau des tokens. Un principal vérifié KYC accorde à un agent un mandat avec un périmètre défini, une juridiction, des limites de valeur et une date d’expiration. En pratique, cela fonctionne comme une procuration on‑chain qui peut être vérifiée avant le règlement. Le contrat de token réglementé vérifie alors ce mandat de façon atomique dans son hook de conformité pré‑transfert avant tout règlement.

Deux interfaces portent la conception. `ComplianceProvider` est implémentée par tout opérateur KYC ou d’attestation et garantit l’éligibilité du principal pour un périmètre donné. `IAgentMandate` est le registre qui consigne les attributions, extensions, révocations, exécutions et gel de niveau régulateur. L’application se fait via `recordExecution`, qui vérifie les plafonds du mandat actif au moment du transfert et annule la transaction si celle‑ci les violerait.

Cette architecture se situe entre l’identité ERC-8004 et les cadres de conformité des tokens comme ERC-7943 plutôt que de remplacer l’un ou l’autre. L’identité indique que l’agent existe et est vérifiable ; la conformité du token, que le principal est éligible à détenir cet actif spécifique. RAMS ajoute la partie que ni l’un ni l’autre ne couvre: l’autorité de ce principal, pour ce périmètre, dans ces limites, jusqu’à cette date. La couche de délégation juridiquement contraignante qui vit actuellement uniquement dans des PDF et des feuilles de calcul back‑office passe on‑chain, où elle peut réellement être appliquée au moment du transfert.

La séparation préparation‑exécution n’est pas une friction

Une décision de conception mérite une défense directe: séparer la préparation de la transaction de la signature et de la diffusion. Cette séparation est souvent supprimée dans de nombreux systèmes qui essaient de rendre les agents plus fluides.

L’instinct est de fusionner ces étapes en une seule parce que cela semble plus efficace. Mais l’écart entre la préparation et la diffusion est exactement l’endroit où la supervision institutionnelle doit intervenir. C’est là qu’un responsable conformité examine ce qu’un agent s’apprête à faire avant que la chaîne n’en prenne connaissance, où la vérification du mandat RAMS valide la charge utile préparée contre le périmètre actif, les plafonds de valeur et la juridiction avant toute signature, et où un directeur financier approuve une action de trésorerie que l’agent a préparée mais pas encore engagée.

De nombreuses institutions qui déploient des agents autonomes à grande échelle finissent par reconstruire cette séparation lorsqu’elles découvrent son absence. L’intégrer comme une primitive architecturale délibérée plutôt que comme une adaptation qui porte un système à travers sa première revue de conformité.

À quoi ressemble la pile lorsqu’elle est complète

Lorsque les quatre couches sont en place, elles s’assemblent proprement. ERC-8004 ancre l’identité de l’agent et la réputation on‑chain, et ERC-8226 ajoute la couche de mandat qui délimite ce que chaque agent peut faire et pour qui. x402 gère le règlement, signant chaque requête afin que chaque action soit attribuable et auditable. En dessous, les cadres d’actifs réglementés comme ERC-7943 appliquent la conformité au moment du transfert contre à la fois l’éligibilité du principal et le mandat actif de l’agent.

Ces éléments sont à des niveaux de maturité différents, mais aucun n’est purement théorique. ERC-8004 est un ERC Draft Standards Track avec des primitives d’identité et de réputation déployables. ERC-7943 est une norme Ethereum finale. ERC-8226 est sur la voie des standards, et les interfaces principales sont suffisamment stables pour un travail d’implémentation précoce. x402 est en production et déjà conçu autour de paiements HTTP programmatiques pour les humains et les agents.

Les équipes qui réussissent cela peuvent construire cette pile dès maintenant ou attendre que la pression d’audit et de conformité impose la rétrofit. Les institutions qui réussissent seront celles qui traitent les couches de mandat et d’identité comme des exigences d’infrastructure dès le premier jour, de la même manière qu’elles traitent le KYC et la garde. Les régulateurs n’ont peut‑être pas encore exigé explicitement chaque composant. Les équipes qui construisent des systèmes de production dans cet espace savent déjà à quel point ces contrôles sont coûteux à ajouter a posteriori.