Paiements par agents, x402 et responsabilité

Quand un agent autonome paie une facture, personne n'est clairement responsable s'il paie la mauvaise. Ce manque, pas la technologie de paiement, est le vrai problème des paiements par agents. Le mois dernier, un agent IA a acheté des crédits d'API pour moi : il a trouvé le point d'accès, s'est heurté à un paywall, a payé, puis a continué. Le paiement a fonctionné. La question de la responsabilité n'avait aucun propriétaire.

x402 et les protocoles qui l'entourent ont résolu la manière dont un agent remet l'argent. Ils n'ont pas résolu qui répond de cet argent quand il part de travers. La couche qui enregistre le donneur d'ordre, la limite de dépense et la preuve que le paiement était autorisé manque toujours.

Je n'écris pas ceci en spectateur. J'ai livré les trois pièces dont cette couche a besoin : l'identité on-chain chez Tokeny, le transfert filtré par l'identité avec ERC-3643, et les rails d'abstraction de compte chez Biconomy qui ont déplacé $441M sur 38M+ transactions. Voici l'argument pour transformer le KYC en Know Your Agent, par quelqu'un qui a mis le KYC on-chain.

Ce que fait x402, et ce qu'il laisse ouvert

Soyons précis sur ce qu'est x402, car le battage l'embrouille. x402 est un protocole de paiement présenté par Coinbase en 2025 qui ranime le vieux code de statut HTTP 402 << Payment Required >>. Un serveur répond à une requête par 402 et un prix ; le client, souvent un agent, paie en stablecoins et réessaie. C'est une façon propre pour un logiciel de payer un logiciel.

C'est vraiment utile, et ce n'est pas la même chose que résoudre la responsabilité. x402 standardise la requête et le règlement d'un paiement unique. Il ne standardise ni l'identité de l'agent qui paie, ni l'autorité qui lui a été accordée, ni la trace qu'un régulateur demanderait plus tard. Un traceur public, x402scan, recense l'activité x402 en direct à la mi-2026. La question sans réponse est celle de savoir qui répond de chacun de ces paiements.

Le Know Your Agent, c'est le KYC déplacé vers l'agent

Voici le recadrage qui rend le problème abordable. Nous avons déjà résolu une version de ceci pour les humains. Cela s'appelle le KYC : avant qu'une personne puisse déplacer de l'argent régulé, une institution vérifie qui elle est et ce qu'elle a le droit de faire. Les paiements par agents ont besoin de la même chose, appliquée à l'agent. Appelez cela Know Your Agent.

La différence, c'est l'endroit où vit l'identité. Le dossier KYC d'un humain se trouve dans la base de données privée d'une banque. Un agent opère à travers des services qui ne partagent pas de base de données, donc son identité doit être portable et vérifiable par n'importe qui, ce qui est exactement ce qu'est une identité on-chain. J'ai construit cette primitive chez Tokeny sous le nom d'OnchainID, avec ERC-734 et ERC-735, avant que les agents ne soient la raison pour laquelle on en voulait.

Les trois pièces que j'ai déjà livrées

Le Know Your Agent n'est pas un projet de recherche pour moi. Ce sont trois standards et systèmes livrés, empilés. Chacun tourne déjà en production pour des actifs régulés. Les paiements par agents ne font que les pointer vers un nouveau payeur.

Empilez ces trois pièces et un paiement d'agent cesse d'être un simple transfert. Il devient un transfert depuis un compte intelligent au périmètre limité, par un agent au donneur d'ordre nommé, filtré par une règle d'identité. Les mécanismes de ce filtre sont ceux que je détaille dans ERC-3643 : le transfert filtré par l'identité, expliqué.

ERC-8203 : la couche de règlement que j'ai aidé à prototyper

Il reste une pièce manquante, et c'est celle dont je suis le plus proche en ce moment. L'identité dit qui est l'agent. Les comptes au périmètre limité disent ce qu'il peut dépenser. Aucun des deux ne dit : ne règle ce paiement que si une condition hors chaîne est ensuite prouvée vraie. Cette étape conditionnelle est là où vit une grande partie du vrai commerce entre agents, et c'est ce qu'ERC-8203 tente de standardiser.

ERC-8203, << Agent Offchain Conditional Settlement >>, est un projet à un stade précoce. Je dois être exact sur mon rôle, car il est facile de le surestimer. L'auteur principal du standard est Xianrui Qin. J'ai écrit l'implémentation de référence, le code qui montre que l'interface peut être construite, soumise via PR #1614. J'ai écrit trois standards Ethereum : ERC-3643, ERC-6960 et ERC-7410. ERC-8203 n'est pas un quatrième. C'est une contribution à la proposition de quelqu'un d'autre.

L'implémentation de référence esquisse une interface à peu près comme ceci. Voyez-la comme une forme, pas le texte normatif, qui appartient à Xianrui Qin.

// ERC-8203 (draft): Agent Offchain Conditional Settlement.
// Primary author: Xianrui Qin. This is the reference-implementation
// shape I submitted as PR #1614, simplified. Illustrative, not the spec.
interface IAgentConditionalSettlement {
    // An agent opens a settlement it will honor IF a condition is later proven.
    function openSettlement(
        bytes32 agentId,        // the agent's on-chain identity
        address principal,      // who is liable if this settles
        bytes32 conditionHash,  // hash of the off-chain condition to satisfy
        uint256 maxAmount       // the ceiling the principal authorized
    ) external returns (bytes32 settlementId);

    // Settlement executes only when the proof matches, and within maxAmount.
    function settle(bytes32 settlementId, bytes calldata proof) external;
}

Deux lignes portent l'argument de responsabilité. Le champ principal enregistre la personne ou l'entreprise engagée si le paiement se règle. Le champ maxAmount enregistre le plafond qu'elle a autorisé. Le règlement ne se déclenche que lorsqu'une preuve satisfait la condition engagée, si bien que rien ne bouge hors du périmètre fixé par le donneur d'ordre.

Un modèle de responsabilité qui pourrait vraiment marcher

Assemblez les pièces et vous pouvez écrire un modèle de responsabilité qu'un régulateur, un ingénieur et un assureur pourraient tous lire. Il a trois ancres, et tout dépend de la présence des trois.

C'est le schéma sur lequel je reviens sans cesse. Chaque ancre correspond à un standard que j'ai déjà nommé. Le point n'est pas qu'il soit fini. Le point est que chaque partie existe déjà en production quelque part, en attente d'être pointée vers les paiements par agents.

Ce que cela débloque, et pourquoi maintenant

Alors, qu'est-ce que cela vous apporte, et pourquoi l'écrire maintenant ? Parce que les standards arrivent plus vite que la conversation sur la responsabilité. x402 a rendu les paiements entre machines faciles cette année. La couche d'identité et de règlement en dessous est en cours de rédaction en ce moment même, en public, dans des fils comme la discussion ERC-8203.

Si vous construisez des agents qui touchent à l'argent, le geste pratique n'est pas d'attendre que le standard de règlement se fige. Donnez dès aujourd'hui à chaque agent qui déplace de l'argent une vraie identité et un compte au périmètre limité, avec les pièces déjà Final. J'approfondis le volet confinement dans le moindre privilège pour les agents qui paient.

FAQ