La liquidation sans preuve d'exécution est une boîte noire payante : fermer la boucle d'audit des paiements d'agents

Points clés

• x402 a traité 169 millions de paiements d'agents sur Base la première année, mais payment_hash prouve seulement qu'une transaction a été liquidée — pas ce que l'agent a fait — l'extension de reçu (OMA3/x402, fusionnée dans le protocole) enregistre qui a payé, quel service, quand, et une référence de paiement, mais pas quelle version de screening, quelle règle de politique, ou quelle version de modèle a tourné côté serveur (Chainalysis, 2026; OMA3, 2026).
• Le projet IETF action_ref (draft-etcheverry-action-ref-02, juillet 2026) définit un identifiant adressé par contenu — SHA-256 sur JSON canonique de agent_id, action_type, scope, timestamp — que tout auditeur recompute sans faire confiance à l'émetteur — avec des champs optionnels pour l'auditabilité des versions de politique, de sorte qu'un auditeur peut déterminer non seulement que la règle 7 s'est déclenchée, mais quelle version de la règle 7 était active à ce moment.
• Le projet IETF x402-retention-chain (draft-hopley-x402-retention-chain-06, juin 2026) formalise la composition : un Settlement-Action Binding (binding_ref) lie payment_hash à action_ref dans un reçu — plus un Policy Binding (policy_bound_ref) qui lie la version de politique gouvernante à l'action, et un Compliance Gate Binding (gate_ref) qui lie un verdict ALLOW/REFER/DENY à la référence de politique.
• Toutes les constructions utilisent uniquement SHA-256 et JCS (RFC 8785), vérifiables par toute partie détenant les reçus sans contacter l'émetteur — satisfaisant les exigences de piste d'audit de MiCA Article 80, DORA Article 14 et AMLR Article 56 (IETF draft-hopley-x402-retention-chain-06, 2026).
• La liquidation sans preuve d'exécution est une boîte noire payante ; la preuve d'exécution sans liquidation est une affirmation non vérifiable ; les agents ont besoin des deux pour fermer la boucle de confiance — x402 liquide l'échange, action_ref lie le contexte d'exécution, et binding_ref les compose en un reçu auditable.

Le problème : six protocoles, zéro reçu d'exécution

La pile de commerce d'agents a convergé en 2026 : UCP (découverte), A2A (communication), MCP (outillage), ACP (checkout), AP2 (autorisation), x402 (liquidation). Six couches, plus de soixante partenaires de lancement — Google, Shopify, OpenAI, Stripe, Visa, Coinbase. Chaque achat est couvert : l'agent découvre, négocie, utilise des outils, fait le checkout, obtient l'autorisation et paie.

Sauf une chose : la preuve que l'agent a réellement fait ce qu'il était censé faire.

x402 liquide le paiement. Le payment_hash prouve que la transaction s'est complétée sur Base en environ 200ms. L'extension de reçu x402 (fusionnée dans le protocole via la collaboration OMA3/x402) ajoute une preuve d'achat signée et portable — qui a payé, quel service a été accédé, quand, et une référence de paiement. Ce reçu est signé numériquement par le service, infalsifiable et universellement vérifiable.

Il n'enregistre pas ce qui s'est passé à l'intérieur du service. Le reçu prouve que l'agent a payé. Il ne prouve pas quelle version de screening a tourné, quelle règle de politique s'est déclenchée, ou quelle version de modèle a produit la décision. Pour un contrôle de conformité fournisseur, le reçu prouve que l'agent a payé pour l'appel API de screening. Il ne prouve pas quelle version de la logique de screening s'est réellement exécutée.

Pour l'approvisionnement réglementé — EU AI Act Article 12, application le 2 août 2026, FCA SYSC 9.1, SOC 2 CC7.x — cette lacune est le bloqueur de conformité. Les logs peuvent être réécrits. Un reçu de paiement qui ne se lie pas à l'exécution est une boîte noire payante.

La solution : deux projets IETF qui composent liquidation et exécution

action_ref — identité d'exécution adressée par contenu

Le projet IETF action_ref (draft-etcheverry-action-ref-02, 23 juillet 2026) définit un identifiant déterministe adressé par contenu pour les actions d'agents. L'identifiant est calculé comme suit :

action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))

Où JCS est le JSON Canonicalization Scheme (RFC 8785), qui produit une séquence d'octets unique pour toute valeur JSON. Les quatre champs de préimage :

Champ	Ce qu'il capture
agent_id	L'exécuteur terminal après résolution de délégation (dans une chaîne A→B→C, agent_id est C)
action_type	Étiquette sémantique (payment.send, compliance.screen, oracle.signal)
scope	Le périmètre d'intention demandée par l'agent au point d'action
timestamp	RFC 3339 UTC avec exactement 3 chiffres de millisecondes

L'objectif de conception est l'indépendance de l'opérateur : un vérificateur détenant les quatre champs peut recomputer action_ref sans appeler l'infrastructure de l'émetteur. Le projet inclut des champs optionnels pour l'auditabilité de rotation de politique — de sorte qu'un auditeur peut déterminer non seulement que la règle 7 s'est déclenchée, mais quelle version de la règle 7 était active à ce moment.

x402-retention-chain — la couche de liaison

Le projet IETF x402-retention-chain (draft-hopley-x402-retention-chain-06, 24 juin 2026) définit sept constructions cryptographiques. Trois sont directement pertinentes pour la boucle paiement → liquidation → audit :

1. Settlement-Action Binding (binding_ref) — lie le payment_hash de x402 à action_ref dans un reçu. Une attestation de liquidation prouve désormais non seulement qu'un paiement a eu lieu, mais à quelle action d'agent vérifiée il correspond. Un auditeur détenant le reçu suit la chaîne de payment_hash à action_ref puis à l'enregistrement d'action, confirmant les deux sans contacter l'émetteur.

2. Policy Binding (policy_bound_ref) — lie un instantané adressé par contenu de la politique gouvernante à l'action. Une décision de screening est vérifiable contre la version exacte de la politique en vigueur au moment où elle a été prise. Une rotation de politique est détectable par recomputation — le hachage change quand la politique change, de sorte que l'auditeur voit la transition.

3. Compliance Gate Binding (gate_ref) — lie un verdict de conformité ALLOW/REFER/DENY et une référence de payeur sans PII à la référence de politique. Le résultat du screening est prouvablement lié à la version de règle qui l'a produit, sans données personnelles dans l'enregistrement lié.

Toutes les constructions utilisent uniquement SHA-256 et JCS. Aucune infrastructure externe requise. Aucun contact avec l'émetteur. Toute partie détenant les reçus peut vérifier.

La boucle d'audit : paiement → liquidation → logs auditables

La boucle complète pour une transaction de commerce d'agents réglementé :

1. Paiement — l'agent appelle une API payante (screening de conformité fournisseur, vérification fournisseur, lookup produit). Le serveur renvoie HTTP 402 avec les conditions de paiement.

2. Liquidation — l'agent signe une autorisation, réessaie avec PAYMENT-SIGNATURE, le facilitateur vérifie et liquide sur Base en environ 200ms. Le serveur renvoie la ressource avec un reçu de liquidation contenant payment_hash.

3. Exécution — l'agent effectue l'action (screening, lookup, décision). Il émet action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp})) — un identifiant adressé par contenu que tout tiers peut recomputer à partir des quatre champs de préimage.

4. Liaison — le binding_ref relie payment_hash à action_ref dans un reçu. Le policy_bound_ref relie la version de politique gouvernante à l'action. Le gate_ref relie le verdict de conformité à la référence de politique.

5. Audit — un auditeur (régulateur, contrepartie, conformité interne) détient le reçu composé. Il recompute action_ref à partir des quatre champs. Il vérifie payment_hash contre la blockchain Base. Il vérifie policy_bound_ref pour confirmer que le screening a tourné sous la bonne version de politique. Il vérifie gate_ref pour confirmer que le verdict correspond. Aucun appel à l'opérateur. Aucune confiance requise.

La boucle répond : paiement liquidé, cette version spécifique de screening a tourné, sous cette version de politique, à ce timestamp, avec ce verdict. Deux couches, un reçu.

Pourquoi chaque couche seule échoue

Le diagramme ci-dessous montre la boucle complète — paiement, liquidation, exécution, liaison et audit — et pourquoi chaque couche seule est insuffisante :

La liquidation sans preuve d'exécution est une boîte noire payante. Le reçu dit que l'agent a payé pour un screening de conformité. Il ne dit pas quelle version de la logique de screening a tourné, si la politique était à jour, ou si le verdict était correct. Un régulateur demandant « avez-vous screeningé ce fournisseur contre la liste de sanctions de juillet 2026 ou celle de juin 2026 ? » n'obtient aucune réponse de payment_hash seul.

La preuve d'exécution sans liquidation est une affirmation non vérifiable. L'agent dit qu'il a screeningé le fournisseur. Sans un reçu de paiement liant le screening à une transaction liquidée, il n'y a pas de preuve économique que le screening a réellement eu lieu. L'affirmation est gratuite à faire et sans valeur à auditer.

La combinaison ferme la boucle de confiance. La liquidation ancre l'événement économique — preuve que l'argent a circulé. La preuve d'exécution ancre l'événement sémantique — preuve de ce qui a été fait. La liaison les relie. Un auditeur vérifie les deux à partir d'un reçu, recomputant les hachages sans faire confiance à aucune partie de la chaîne.

Ce que cela signifie pour un build B2B

Un agent d'approvisionnement qui passe des commandes, autorise des paiements et screeninge des fournisseurs a besoin de la boucle complète dans sa piste d'audit. L'architecture :

• x402 gère la liquidation. L'agent rencontre une réponse 402 de l'API de conformité fournisseur, paie en USDC sur Base, et reçoit un reçu de liquidation avec payment_hash.
• action_ref gère l'identité d'exécution. L'agent émet action_ref pour chaque action de screening de conformité, enregistrant agent_id, action_type (compliance.screen), scope (ID fournisseur et type de screening) et timestamp.
• binding_ref les compose. Le reçu de liquidation porte payment_hash et action_ref dans une enveloppe. Le policy_bound_ref enregistre quelle version de politique a gouverné le screening. Le gate_ref enregistre le verdict ALLOW/DENY.
• La piste d'audit est la chaîne de reçus composés. Un auditeur recompute action_ref à partir des quatre champs, vérifie payment_hash on-chain, vérifie le hachage de la version de politique et confirme le verdict — le tout sans contacter l'opérateur de l'agent, le facilitateur de paiement ou le service de screening.

Pour une industrie réglementée — conformité GMP pharmaceutique, screening ITAR aérospatial, contrôles de sanctions de services financiers — c'est la différence entre un agent auditable et un agent qui est un passif de conformité. L'exigence de conservation des enregistrements de l'Article 12 de l'EU AI Act (application le 2 août 2026) exige la traçabilité des décisions du système d'IA. L'Article 80 de MiCA exige des enregistrements de transactions. L'Article 14 de DORA exige des pistes d'audit pour la résilience opérationnelle. La construction binding_ref satisfait les trois à partir d'un reçu.

Lectures connexes

• Quand l'agent passe la commande : comment les paiements agéntiques ferment la boucle d'approvisionnement B2B — le cycle procure-to-pay du RFQ au rapprochement des paiements avec des protocoles de paiement agéntique
• Kill-Switch by Design : architecture de gouvernance de l'agent — la couche de gouvernance qui décide quand un agent peut agir et quand il doit s'arrêter
• Gouvernance proportionnelle de l'agent : pourquoi la confiance binaire échoue — correspondance entre niveaux d'autonomie et risque, incluant le point de contrôle de l'autorisation de paiement
• Conformité EU AI Act pour les déploiements d'agents — l'exigence de conservation des enregistrements de l'Article 12 que la boucle d'audit satisfait

---

Un distributeur mid-market qui fait tourner un agent qui screeninge 85 fournisseurs par semaine pour la conformité a besoin de plus qu'un reçu de paiement. Il lui faut la preuve que le screening a tourné sous la bonne version de politique, au bon moment, avec le bon verdict — lié au paiement qui l'a financé. La construction binding_ref compose la liquidation x402 et l'exécution action_ref en un reçu que tout auditeur peut vérifier sans faire confiance à l'opérateur. C'est la boucle d'audit : paiement → liquidation → logs auditables. Deux couches, un reçu, zéro confiance en l'émetteur.