Know Your Agent : qui a autorisé le bot qui vient de déplacer un security token

Un agent IA déplace un titre tokenisé. Le transfert passe. La couche de conformité enregistre un mouvement d'un détenteur vérifié vers un autre détenteur vérifié, et chaque mot de cet enregistrement est vrai.

Il y manque aussi le seul fait que quelqu'un demandera ensuite : quel humain a dit à l'agent de le faire.

J'ai écrit cette phrase en public le 30 mars 2026, dans le fil Ethereum Magicians d'une proposition appelée ERC-8118. Mes mots exacts, en anglais et avec les fautes de frappe d'origine : « 8118 handles the “what can this agent do” side well. theres a complementary gap tho: who authorized this agent? » Treize jours plus tard, ERC-8226 était créé pour répondre exactement à cela.

Cet article est un état des lieux de ce qui a été refermé, et de ce qui ne l'a pas été.

ERC-3643 a déjà un Agent. Ce n'est pas celui-là.

Il faut d'abord découper un mot en deux, car se tromper ici invalide tout l'article. ERC-3643 a déjà un Agent. Il en a un depuis 2021. Il définit ce rôle dans une interface appelée IAgentRole, et le standard est explicite : c'est le rôle de propriétaire, tel que défini par ERC-173, qui a la responsabilité de nommer et de révoquer les agents.

Cet Agent est un opérateur côté émetteur. Le propriétaire du token le nomme, et il peut émettre, brûler, geler des wallets et forcer des transferts. C'est un responsable conformité avec une clé privée. Ce n'est pas le délégué d'un investisseur, il n'a aucun donneur d'ordre, aucun périmètre, aucun plafond de dépense et aucune échéance.

Et cela va plus loin, et c'est plus étrange encore. Le Rationale d'ERC-3643 anticipait déjà l'automatisation : les auteurs y envisagent des scénarios où le rôle d'agent est tenu par des systèmes automatisés ou des contrats intelligents, capables d'exécuter par programme des fonctions opérationnelles comme l'émission, la destruction et le gel, en réponse à des critères définis ou à des déclencheurs réglementaires.

Donc dès 2021 nous avions imaginé des bots tenant des rôles privilégiés sur un token régulé. Nous les avions imaginés du côté émetteur de la table. Le manque dont parle cet article est du côté investisseur, et rien dans le standard n'a jamais été pointé là.

// ERC-3643 (Final since 2023-12-12). The Agent role, verbatim.
// Read the doc comment carefully: this is an ISSUER-side operator.
// It is NOT an investor's delegate, and it is NOT an AI agent.
interface IAgentRole {
  function addAgent(address _agent) external;
  function removeAgent(address _agent) external;
  function isAgent(address _agent) external view returns (bool);
}

// "it is the owner role, as defined by ERC-173, that has the
//  responsibility of appointing and removing agents."
//
// No principal. No scope. No spending cap. No expiry.

Dans la suite de ce texte, « le rôle Agent d'ERC-3643 » désigne toujours l'opérateur côté émetteur ci-dessus. « Agent IA » et « l'agent de l'investisseur » désignent toujours le logiciel qui agit pour un détenteur de tokens. Qui vous dit qu'ERC-3643 n'a aucune notion d'agent ne l'a pas lu, et qui vous dit qu'il résout déjà les mandats d'agents en a lu la mauvaise moitié.

Ce que la couche de conformité voit vraiment

Passons au mécanisme. ERC-3643 énonce les conditions d'un transfert sous forme de liste normative de MUST, et c'est la chose la plus propre à citer, parce qu'elle est courte et qu'elle engage.

Deux de ces six conditions sont des hooks vers d’autres contrats, et la différence entre les deux compte.

isVerified vit sur l'Identity Registry. Le standard le décrit comme vérifiant « le destinataire », à la fois dans la liste de MUST et dans la section qui le définit. Autant être précis, car on surestime constamment ce point : l'identité de l'expéditeur n'est pas revérifiée au moment du transfert. Seuls son statut de gel et son solde libre le sont. L'expéditeur, lui, a été vérifié au moment de son inscription.

canTransfer vit sur le contrat Compliance. Celui-là est la prise, et c'est la raison d'être de cet article.

Voici l'interface, mot pour mot. Je la cite plutôt que l'implémentation de transfert illustrative que l'EIP publie aussi, car cet exemple a des noms de variables incohérents et ne compilerait pas tel qu'imprimé. L'interface est normative. L'exemple ne l'est pas.

// ERC-3643 (Final since 2023-12-12). The compliance hook, verbatim.
// ICompliance is a SEPARATE CONTRACT that the token calls into.
interface ICompliance {
    function canTransfer(address _from, address _to, uint256 _amount) external view returns (bool);
    function transferred(address _from, address _to, uint256 _amount) external;
    function created(address _to, uint256 _amount) external;
    function destroyed(address _from, uint256 _amount) external;
}

// How the token reaches it, from the EIP's own example:
//   require(_tokenCompliance.canTransfer(from, to, amount), "ERC-3643: Compliance failure");
//
// Three values arrive. The caller is not one of them.
// Inside ICompliance, msg.sender is the TOKEN address, never the agent.

C'est le constat porteur, et il vient des interfaces normatives, pas de l'opinion de quelqu'un. ICompliance est un contrat séparé. Le token l'appelle. canTransfer reçoit exactement trois valeurs, sans appelant et sans calldata. transferred, created et destroyed ne reçoivent pas plus l'initiateur que canTransfer.

Donc quand un agent déplace un security token via transferFrom, la couche de conformité d'ERC-3643 est structurellement incapable de remarquer qu'un agent est intervenu.

Et l'allowance ERC-20 qui a autorisé l'agent au départ lui est invisible. approve et allowance sont hérités d'ERC-20 et n'apparaissent dans aucune interface ni aucune exigence de conformité du standard. Le seul endroit où toute la pile régulée s'intéresse à l'autorité est le seul endroit où l'autorité n'a jamais été acheminée.

Cinq standards d'agents fusionnés. Aucun n'est Final.

La réponse évidente serait qu'un standard plus récent referme ce manque. Plusieurs essaient, et aucun n'a terminé. Voici l'instantané des statuts, tous lus dans le frontmatter brut des EIP et dans l'historique git d'ethereum/ERCs le 5 août 2026.

Les deux standards de token dans lesquels ces propositions doivent se brancher sont Final : ERC-3643 depuis le 12 décembre 2023, et ERC-7943 (uRWA) depuis mai 2026. Cinq ERC liés aux agents sont fusionnés dans le dépôt : ERC-8004 Trustless Agents, ERC-8183 Agentic Commerce, ERC-8217 Agent NFT Identity Bindings, ERC-8226 Regulated Agent Mandate et ERC-8273 Attestation-Gated Agentic Actions. Les cinq sont au statut Draft.

Cinq fusionnés, zéro Final. Voilà le chiffre à retenir.

Deux de ces lignes appellent une correction, parce qu'internet se trompe dessus. ERC-8118 n'est pas un standard. eips.ethereum.org renvoie un 404 pour lui, et la PR #1450 est ouverte et non fusionnée depuis le 6 janvier 2026, dernière activité le 25 janvier 2026. C'est une proposition à l'arrêt depuis plus de six mois. Son mécanisme est d'ailleurs l'inverse de ce que la plupart supposent : le signataire est l'agent, pas le donneur d'ordre, et la raison invoquée est l'anti-squattage, pas la conformité. Le proposant l'a dit clairement dans le fil : sans la signature de l'agent, n'importe qui pourrait revendiquer une adresse comme son agent et la bloquer, ce qui est un vecteur de déni de service. Le donneur d'ordre est authentifié par le fait d'être msg.sender, ce qui authentifie que quelqu'un a appelé, pas qui il est.

ACTA est une note de recherche publiée sur ethresear.ch le 5 mai 2026, ni un EIP ni une proposition au dépôt ERCs. C'est une couche de confidentialité au-dessus d'ERC-8004 et elle traite bien des attestations de personnalité. Je l'ai vue attribuée à l'Ethereum Foundation. Je n'ai pas pu le vérifier, donc je ne le répète pas.

Et ERC-7943, le standard Final le plus récent de ce domaine, contient les mots agent, delegate, principal et operator exactement zéro fois dans tout son texte. Ce n'est pas qu'uRWA aurait mal répondu à la question. Il ne l'a jamais posée.

ERC-8226 est le seul qui essaie vraiment

ERC-8226, Regulated Agent Mandate, est écrit spécifiquement pour refermer ce manque, et je veux lui rendre justice avant d'être dur avec lui, parce que c'est un travail sérieux.

Il spécifie un vrai mandat. Pas un geste de la main, pas un registre de bonnes intentions. Deux interfaces : IComplianceProvider, qui octroie, révoque et vérifie un donneur d'ordre et renvoie un triplet éligibilité, code de motif et échéance ; et IAgentMandate, le registre lui-même, dont le stockage est indexé par le couple agent et donneur d'ordre, avec au plus un mandat actif par couple. Les codes de motif sont ceux qu'une équipe conformité écrirait vraiment, dont KYC_EXPIRED, AML_FLAG, NOT_ACCREDITED, NOT_QUALIFIED et JURISDICTION_BLOCKED. Octroyer un mandat DOIT échouer si aucun fournisseur de conformité n'est configuré.

Il a été créé le 12 avril 2026, fusionné dans le dépôt ERCs au statut Draft le 12 mai 2026, et a reçu une implémentation de référence et un affinage de spec fusionnés le 29 juin 2026.

Un point de provenance, énoncé sans sous-entendu parce que c'est de la provenance et pas une faute. Les quatre auteurs d'ERC-8226 utilisent des adresses brickken.com, et l'un d'eux est aussi co-auteur d'ERC-7943, qui est Final. Une paternité d'entreprise unique est banale dans le monde des EIP. Cela compte ici pour une seule raison, très étroite, sur laquelle je reviens deux sections plus loin.

Le reste de cet article porte sur les questions que le standard n'a pas tranchées. C'est un Draft sans activité de spec depuis le 29 juin 2026, soit environ cinq semaines de silence à l'heure où j'écris, donc rien de ce qui suit n'est un reproche de lenteur. C'est la liste de ce qui resterait ouvert s'il sortait demain.

Un mandat valide ne dit jamais où vont les tokens

Commençons par le point le plus fort, parce qu'il sort directement de l'interface.

Un mandat ERC-8226 contraint l'actif, l'étiquette d'action, le montant et la fenêtre temporelle. Il ne contraint pas qui reçoit les tokens. La spec le dit ailleurs en prose, en notant qu'elle plafonne la quantité transférée et non des identifiants de tokens précis. Mais vous n'avez pas besoin de la prose. La signature vous le dit.

// ERC-8226 "Regulated Agent Mandate" (Draft, created 2026-04-12).
// The authorization check, verbatim. Read the parameter list twice.
function canExecute(
    address agent,
    address principal,
    address asset,
    bytes32 action,   // WHAT may be done
    uint256 amount    // HOW MUCH may move
) external view returns (bool);

function recordExecution(
    address agent,
    address principal,
    bytes32 action,
    uint256 amount
) external;

// Missing from both: any parameter naming WHERE the tokens end up.

Cinq paramètres entrent dans la vérification d'autorisation et quatre dans l'enregistrement d'exécution, et aucun des neuf n'est une destination. Un mandat valide peut dire « cet agent peut déplacer jusqu'à un million de cet actif par transferFrom pendant trente jours » et rester totalement muet sur l'endroit où ces tokens vont. C'est la question de la conservation, et elle est ici prouvée par l'interface normative plutôt que par la lecture que l'un ou l'autre fait du forum.

Ce n'est pas un piège tendu. Les auteurs l'ont listé comme ouvert dès le premier jour. Dans l'annonce d'avril 2026, sous un titre littéralement intitulé « Open topics », ils demandent qui est le propriétaire enregistré quand un agent acquiert des tokens pour le compte d'un donneur d'ordre, exposent les deux modèles, et disent chercher des avis sur la question de savoir si le standard doit prescrire un défaut ou rester agnostique. Puis, après avoir construit l'implémentation de référence, ils ont refusé de trancher. Le 29 juin 2026, dans ce qui reste le message le plus récent de ce fil, l'auteur principal écrit que la PR courante garde la spec agnostique sur la conservation, que prescrire un défaut contraindrait l'adoption pour des usages aux besoins opérationnels très différents, et qu'ils reverront cette position une fois qu'il y aura des déploiements en production dont apprendre.

Il y a dans le fil une tension qui mérite d'être nommée sans être surinterprétée. En juin, un autre auteur écrit que le mandat permet à l'agent d'agir sur le wallet du donneur d'ordre et jamais d'en prendre la conservation. Mais le message d'avril propose la conservation par l'agent comme un modèle pris en charge, et la mise à jour de juin dit que l'implémentation de référence démontre ce chemin. Les deux sont conciliables : un mandat ne déplace pas la conservation des avoirs que vous détenez déjà, et la question ouverte est celle de l'atterrissage des tokens nouvellement acquis. Le fil ne les concilie jamais par écrit, donc je ne ferai pas semblant du contraire.

Voici pourquoi c'est le centre de gravité pour quiconque est sur un token permissionné. ERC-3643 exige isVerified sur le destinataire. Si l'agent conserve, le wallet de l'agent est un investisseur inscrit et la couche de conformité enregistre l'agent comme détenteur. Savoir si un agent peut être le détenteur inscrit, et ce qu'un agent de transfert tenant le registre de titres en fait, est une question juridique vivante. Je suis ingénieur et je ne vais pas y répondre ici. Je vais seulement énoncer ce que l'ingénierie rend vrai : sur un token ERC-3643, celui qui reçoit est celui que le registre connaît.

Ce même sujet ouvert a un jumeau sur lequel personne n'est revenu. Le message d'avril signalait aussi la conformité côté réception, en notant que la spec couvre les transferts sortants initiés par l'agent et que, pour les transferts entrants, le token doit décider s'il applique l'éligibilité investisseur à l'agent ou au donneur d'ordre. Aucun message ultérieur du fil ne le traite, et la liste de mises à jour de juin ne le mentionne pas. L'interface le confirme : canExecute n'a pas non plus de destinataire. Petite parenthèse : ce passage d'avril nomme un hook de token appelé canTransact, qui n'existe dans aucun des standards concernés. ERC-7943 a canSend, canReceive et canTransfer ; ERC-3643 a isVerified et canTransfer. Je le cite tel qu'écrit plutôt que de le corriger en silence.

Le motif qu'il publie n'atteint pas ERC-3643

Vient maintenant la partie que je n'ai vu personne d'autre formuler, et aussi celle dont je suis le plus sûr, parce qu'elle découle de deux interfaces que je peux montrer du doigt.

ERC-8226 dit fonctionner avec n'importe quel standard de token régulé, en nommant ERC-7943 et ERC-3643, et il liste ERC-3643 dans son tableau de couches. Sa règle d'intégration tient en une phrase : le token régulé intègre la vérification du mandat dans son hook de pré-transfert existant, le donneur d'ordre est le détenteur, l'agent est l'appelant au sens de msg.sender, et un transfert où l'appelant n'est pas le détenteur est initié par un agent et DOIT satisfaire le mandat de ce couple. Cette règle enferme une exigence dure. Le hook doit pouvoir voir msg.sender comme étant l'agent.

Remarquez aussi l'asymétrie dans cette même phrase. Pour ERC-7943, elle nomme la fonction exacte, canTransfer. Pour ERC-3643, elle dit seulement « transfer restrictions », sans nommer de fonction. Et le seul code abouti de tout l'EIP vise ERC-7943.

// ERC-8226's ONLY worked integration example, verbatim from the EIP.
// Note the target: ERC-7943, not ERC-3643.
// Pseudocode: canTransfer for RAMS-aware ERC-7943 tokens.
function canTransfer(address from, address to, uint256 amount) public view returns (bool) {
    require(canSend(from), ERC7943CannotTransfer(from, to, amount));
    require(canReceive(to), ERC7943CannotTransfer(from, to, amount));
    if (msg.sender == from) return true;
    if (ramsRegistry.getMandate(msg.sender, from).principal == address(0)) return true; // plain allowance, no mandate
    bytes32 action = bytes32(IERC20.transferFrom.selector);
    return ramsRegistry.canExecute(msg.sender, from, address(this), action, amount);
}

// This works because ERC-7943 declares canTransfer ON THE TOKEN,
// so msg.sender inside it really is the agent.
// ERC-3643 declares canTransfer on ICompliance, a different contract,
// where msg.sender is the token. The pattern does not port.

Ce pseudocode est correct pour le standard qu'il vise. ERC-7943 déclare canTransfer sur le token lui-même, donc msg.sender à l'intérieur est vraiment l'agent et la vérification a tout ce qu'il lui faut. ERC-3643 déclare canTransfer sur ICompliance, un autre contrat, donc msg.sender à l'intérieur est le token. Le motif publié n'y voit pas l'agent. Ce n'est pas qu'il fonctionne mal. Il ne peut pas s'exécuter.

Alors, que faudrait-il vraiment pour intégrer une couche de mandat à ERC-3643 ? La vérification doit vivre dans le transferFrom du token lui-même, avant l'appel vers la conformité, parce que c'est le dernier endroit où l'appelant existe encore. L'EIP ne le dit jamais. Son implémentation de référence livre une intégration d'actif ERC-7943, un exécuteur et un fournisseur de conformité, et aucun chemin ERC-3643.

Je ne pense pas qu'on ait caché quoi que ce soit. Je pense que c'est ce qui arrive quand une histoire de composition est testée face au standard que les auteurs connaissaient déjà bien. C'est l'unique endroit étroit où la paternité partagée compte : l'intégration est la mieux testée face à ERC-7943 et la moins testée face à ERC-3643, qui est pourtant le plus déployé des deux.

Personne dans le fil ne l'a soulevé. Ce n'est pas une question sans réponse dans le corpus, c'est une hypothèse non examinée, et je la soulève ici en tant que personne qui doit vivre avec la prise, pas en tant que personne qui marque un point.

Les paliers de régulateur annoncés puis disparus

Une dernière chose a changé entre l'annonce et la spec fusionnée, et c'est celle qui devrait le plus intéresser une entreprise régulée.

L'annonce de forum d'avril 2026 faisait deux promesses réglementaires. Aucune n'a survécu jusqu'au standard.

La deuxième ligne est la plus intéressante, et ce n'est pas une critique du revirement. La règle d'un seul donneur d'ordre a été abandonnée pour une bonne raison : un lecteur a demandé en juin comment fonctionneraient les gérants multi-clients, et la réponse, un mandat par couple autorisant de nombreux donneurs d'ordre par agent, est manifestement le meilleur design. Mais la justification est partie avec la règle. Le design initial était défendu en nommant trois cadres réglementaires et leurs exigences de ségrégation des comptes. La règle a changé, personne n'a demandé ce qui satisfait la ségrégation désormais, et ces trois noms n'apparaissent nulle part dans le standard.

Je ne vais pas vous dire ce que ces réglementations exigent. Je ne suis pas juriste, et cet article reste du côté ingénierie de cette ligne. La question d'ingénierie est celle que personne dans le fil n'a posée, et je peux la poser depuis la place de quelqu'un qui a dû y répondre dans une entreprise régulée : si une règle existait à cause d'une obligation de ségrégation, et que la règle a disparu, qu'est-ce qui porte l'obligation maintenant ? « L'interface est agnostique » n'a jamais été une réponse acceptable à cette question, parce qu'au bout du compte, quelqu'un signe.

La troisième ligne mérite sa propre phrase. Le mandat peut pointer vers la procuration, et le standard vous interdit de vous fier au pointeur. La chaîne détient une référence au document juridique et aucun intégrateur n'a le droit d'en tirer une décision d'application. C'est de l'ingénierie honnête. C'est aussi exactement la couture où un auditeur vous demandera ce que vous avez fait à la place.

Votre token peut-il vérifier cet agent ?

Un mot sur l'expression du titre, car elle a déjà un propriétaire commercial. Sumsub a lancé le 29 janvier 2026 un produit de vérification d'agents IA appelé Know Your Agent, qui lie les agents IA à des identités humaines vérifiées afin que chaque action soit rattachée à la personne responsable, avec un test de vivacité dans les cas à risque élevé.

Je n'ai cherché qu'une seule chose dans cette annonce : est-ce que quoi que ce soit atterrit on-chain. Elle ne mentionne la blockchain nulle part. Ce n'est pas une critique du produit, qui résout un vrai problème. C'est tout le problème en une phrase. Le principal contrôle commercial de type Know Your Agent est entièrement hors chaîne, et un token permissionné qui prend une décision au sein d'un transfert ne peut pas le consommer.

Voici donc la réponse honnête pour quiconque livre dans les douze prochains mois.

Ce que je livrerais pendant que les standards se disputent

Trois gestes, dont aucun n'exige un standard d'agent Final, et qui deviennent tous plus durs à mesure que vous les repoussez.

À quoi cette preuve doit ressembler quand on vous la demande est un sujet à part entière, et j'ai écrit un épisode sur la façon de prouver le travail d'un agent à un auditeur à ce sujet précis.

Le volet confinement du même problème, borner ce qu'un agent peut faire avant qu'il ne le fasse, se trouve dans le moindre privilège pour les agents qui paient, et le rail de paiement qui court sous tout cela est dans l'épisode précédent.

Retour à mars. J'ai proposé quatre fonctions dans ce message de forum : authorize, revoke, principalOf et getAuthority, avec l'idée que principalOf renverrait son entrée inchangée pour les non-agents, si bien que l'intégration tiendrait en une ligne sans branchement. L'auteur principal d'ERC-8226 m'a répondu directement, a dit que le manque était réel et bien formulé, puis a expliqué pourquoi quatre fonctions ne suffisaient pas. Il avait raison, et je préfère le citer que l'esquiver.

Ce que je continue de croire vrai est plus étroit que ce que j'ai posté en mars, et plus difficile. Résoudre le donneur d'ordre est la moitié facile. La moitié que personne n'a refermée, c'est que la couche de conformité du standard de token permissionné le plus déployé, celle qui décide vraiment oui ou non, ne voit pas l'appelant du tout. Cinq propositions fusionnées, zéro Final, un Draft qui essaie, et une prise à trois arguments.

Voilà où nous en sommes au 5 août 2026. Je mettrai ceci à jour quand le compte changera.

FAQ