Engagement tripartite : Comment notre pile lie l'intention de paiement, le transcrit d'execution et le reglement en un recu verifiable

Points cles

• Un engagement tripartite hache l'intention de paiement, le digest du transcrit d'execution et le txid de reglement en un recu — un auditeur verifie chaque element independamment, puis confirme que le hachage combine couvre les trois — l'engagement couvre toutes les etapes ou aucune ; il n'y a pas de couverture partielle (IETF draft-hopley-x402-retention-chain-06, 2026).
• Le replay inter-session est detecte par une discordance de hachage, non prevenu par une politique — parce que binding_ref hache payment_hash ET action_ref ensemble, echanger un paiement de la session A avec une execution de la session B produit un hachage combine different ; le verificateur recalcule et obtient une discordance (x402 GitHub issue #2332, 2026).
• Les modules MCP produisent le transcrit d'execution nativement — chaque appel d'outil (screening de conformite fournisseur, recherche fournisseur, redaction de devis) est journalise avec les arguments, les resultats et les horodatages ; le digest du transcrit est action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp})), recalculable par toute partie detenant les quatre champs (IETF draft-etcheverry-action-ref-02, 2026).
• Le reglement x402 sur Base produit payment_hash en ~200ms — le hachage de la transaction on-chain est verifiable independamment en interrogant la blockchain Base ; aucune confiance en l'operateur ni dans le facilitateur n'est requise (Chainalysis, 2026).
• Toutes les constructions utilisent SHA-256 et JCS (RFC 8785) — le meme standard de canonisation utilise par le audit trail de Hermes Agent (GitHub issue #487), de sorte que le digest du transcrit d'execution est produit nativement par le systeme d'audit de l'agent lui-meme, non ajoute ulterieurement.

Le probleme : auditer chaque etape separement est necessaire mais pas suffisant

La pile de six protocoles pour le commerce d'agents (UCP, A2A, MCP, ACP, AP2, x402) couvre la decouverte, la communication, le tooling, le checkout, l'autorisation et le reglement. Chaque protocole produit sa propre evidence : x402 produit un hachage de paiement, MCP produit un journal d'appels d'outils, AP2 produit un mandat d'autorisation. Auditer chaque etape separement est necessaire — vous devez verifier que le paiement a ete regle, que l'execution a eu lieu et que l'autorisation etait valide.

Mais des pistes d'audit separees ne sont pas suffisantes. Sans liaison, un attaquant peut melanger un paiement reel de la session A avec une execution reelle de la session B. Les deux sont des artefacts authentiques. Aucun n'est forge. Mais ils ne se sont pas produits dans la meme session. Le recu de paiement prouve qu'un paiement a eu lieu. Le journal d'execution prouve qu'un screening a ete execute. Sans une liaison qui les relie cryptographiquement, il n'y a aucune preuve qu'il s'agit de la meme transaction.

C'est l'attaque de replay inter-session : prendre un payment_hash authentique d'une transaction completee et le coupler avec un action_ref authentique d'une transaction differente. Si le systeme d'audit fait confiance au couplage parce que les deux artefacts sont valides individuellement, il accepte un composite fabrique. La piste d'audit montre un paiement qui a ete regle et un screening qui a ete execute — mais ils proviennent de transactions differentes.

L'etape de liaison est l'endroit ou cette attaque est detectee — ou ne l'est pas.

L'architecture : comment notre pile produit chaque composant

Le diagramme ci-dessous montre le flux complet de l'engagement tripartite — quel systeme produit chaque artefact, comment la couche de liaison les compose, et comment l'auditeur les verifie :

Comment chaque composant est produit dans notre pile

Intention de paiement : l'offre signee x402

Quand l'agent appelle une API de screening de conformite fournisseur payante, le serveur renvoie HTTP 402 avec une offre signee. L'extension offer-receipt (fusionnee dans le protocole x402) engage le serveur a des termes de paiement specifiques : amount, asset, payTo address, la ressource exacte en cours de fulfillment, et une fenetre de validite. L'offre est signee avec EIP-712 (base sur wallet Ethereum) ou JWS (toute cle asymetrique, y compris Solana Ed25519).

L'offre est l'intention de paiement — ce que l'agent est sur le point de payer. L'auditeur la hache independamment :

offer_hash = SHA-256(JCS(signed offer terms))

L'auditeur recalcule cela depuis les termes de l'offre signee et verifie la signature du serveur. Aucun contact avec le payment backend n'est requis — l'offre est un artefact signe portable.

Transcrit d'execution : le journal d'appels d'outils MCP

Nos modules MCP connectent l'agent aux APIs de conformite fournisseur, aux catalogues de fournisseurs et aux rails de paiement. Chaque appel d'outil MCP est journalise : quel module a ete invoque, quels arguments ont ete passes, quel resultat a ete renvoye, a quel horodatage, sous quelle version de politique. C'est le transcrit d'execution.

Le audit trail de Hermes Agent (GitHub issue #487) implemente la journalisation d'actions avec chainage de hachage SHA-256 et canonisation RFC 8785 (JCS) — le meme standard que action_ref et binding_ref utilisent. Le digest du transcrit d'execution est produit nativement par le systeme d'audit de l'agent lui-meme :

action_ref = SHA-256(JCS({
  agent_id: "procurement-agent-001",
  action_type: "compliance.screen",
  scope: "vendor:acme-corp screening-type:sanctions",
  timestamp: "2026-07-31T19:45:23.482Z"
}))

L'auditeur recalcule action_ref depuis ces quatre champs preimage. Aucun contact avec l'agent ou son operateur n'est requis. La canonisation est definie par RFC 8785, non par le serializeur — de sorte que le hachage est deterministe entre les implementations.

Le policy_bound_ref lie la version de politique qui etait en vigueur quand l'action a ete executee. Si la liste des sanctions a ete mise a jour entre juin et juillet 2026, le hachage de politique change, et l'auditeur peut detecter quelle version etait active. Le gate_ref lie le verdict ALLOW/DENY du screening de conformite a la reference de politique, de sorte que le resultat est provablement lie a la version de regle qui l'a produit.

Reglement : le txid on-chain sur Base

Le facilitateur x402 verifie l'autorisation de paiement signee de l'agent, construit la transaction on-chain, et la diffuse sur Base. Le reglement se complete en environ 200ms. Le facilitateur renvoie le hachage de la transaction (payment_hash) au serveur, qui le passe a l'agent dans le header PAYMENT-RESPONSE.

L'auditeur verifie payment_hash en interrogeant la blockchain Base — le txid est un enregistrement public et immutable. Aucune confiance dans le facilitateur ni dans le payment backend n'est requise. L'auditeur confirme :

• La transaction existe sur Base
• Le amount correspond aux termes de l'offre
• La payTo address correspond a l'offre
• La transaction est confirmee (non en attente)

La liaison : comment binding_ref compose les trois

Le binding_ref (IETF draft-hopley-x402-retention-chain-06) compose les trois hachages en un engagement :

binding_ref = SHA-256(JCS({
  offer_hash,      // ce qui a ete promis (intention de paiement)
  action_ref,      // ce qui a ete execute (digest du transcrit MCP)
  payment_hash     // ce qui a ete regle (txid on-chain)
}))

C'est un engagement tripartite. L'auditeur verifie chaque composant independamment :

1. offer_hash — recalculer depuis les termes de l'offre signee, verifier la signature du serveur
2. action_ref — recalculer SHA-256 depuis les quatre champs preimage, sans contact avec l'agent
3. payment_hash — interroger la blockchain Base, confirmer que le txid existe et est regle

Puis l'auditeur recalcule binding_ref depuis les trois et confirme qu'il correspond. Si un composant est echange — un paiement de la session A couple avec une execution de la session B — le hachage combine ne correspondra pas. L'engagement couvre les trois etapes ou aucune. Il n'y a pas de couverture partielle.

Comment le replay inter-session est detecte

L'attaque de replay inter-session fonctionne comme suit : un attaquant prend un payment_hash authentique d'une transaction completee dans la session A et le couple avec un action_ref authentique d'une transaction differente dans la session B. Les deux artefacts sont reels. Aucun n'est forge. Mais ils ne se sont pas produits dans la meme session.

Sans liaison, le systeme d'audit verifie payment_hash et action_ref separement, trouve les deux valides, et accepte le composite. La piste d'audit montre un paiement qui a ete regle et un screening qui a ete execute — mais ils proviennent de transactions differentes.

Avec binding_ref, l'auditeur recalcule le hachage combine depuis le payment_hash et le action_ref reels dans le recu. Si l'attaquant a echange l'un d'une session differente, les hachages proviennent de contextes preimage differents, et le binding_ref combine ne correspondra pas a la valeur dans le recu. Le verificateur detecte la discordance. L'engagement ne couvre pas toutes les etapes, il est donc rejete.

C'est ce qui fait de l'etape de liaison la primitive de confiance : elle n'ajoute pas de nouvelle evidence, elle relie l'evidence existante cryptographiquement. Le hachage de paiement sur Base est verifiable. Le journal d'execution est verifiable. La preuve de liaison rend le lien entre eux verifiable. Sans le lien, chacun est une revendication autonome. Avec le lien, ils sont un recu compose qu'un auditeur peut verifier de bout en bout.

Ce que cela signifie pour la construction

Un agent d'approvisionnement qui screening 85 fournisseurs par semaine pour la conformite a besoin de l'engagement tripartite dans sa piste d'audit. L'implementation dans notre pile :

• Les modules MCP produisent le transcrit d'execution. Chaque appel d'outil est journalise avec les arguments, les resultats, les horodatages et la version de politique. Le digest du transcrit est action_ref, calcule nativement par le systeme d'audit de Hermes Agent utilisant la canonisation JCS.
• x402 gere le reglement. Le facilitateur regle sur Base et renvoie payment_hash. L'extension offer-receipt signe l'intention de paiement a la reponse 402.
• La couche d'audit (ni l'agent, ni le payment backend) calcule binding_ref depuis offer_hash, action_ref et payment_hash. Elle calcule aussi policy_bound_ref et gate_ref pour lier la version de politique et le verdict de conformite.
• Le point de controle human-in-the-loop a l'autorisation de paiement voit le recu compose : termes de l'offre, resultat d'execution, confirmation de reglement, version de politique et verdict — tous lies par binding_ref.
• Un auditeur externe (regulateur, contrepartie, conformite interne) verifie le recu compose en recalculant chaque hachage independamment. Aucun contact avec l'agent, le payment backend ou l'operateur de la couche d'audit n'est requis.

La verification prend des secondes : interroger Base pour le txid, recalculer action_ref depuis quatre champs, recalculer offer_hash depuis les termes signes, recalculer binding_ref depuis les trois. L'engagement couvre toutes les etapes ou aucune. C'est la primitive qui rend le commerce d'agents auditable de bout en bout.

Lectures connexes

• La liquidation sans preuve d'execution est une boite noire payante : fermer la boucle d'audit des paiements d'agents — la boucle d'audit en cinq etapes et les projets IETF qui definissent binding_ref, policy_bound_ref et gate_ref
• Quand l'agent place la commande : comment les paiements agentiques ferment la boucle d'approvisionnement B2B — le cycle procure-to-pay avec des protocoles de paiement agentique (Mastercard Agent Pay, x402, Stripe agentic tokens)
• Kill-Switch by Design : architecture de gouvernance de l'agent — la couche de gouvernance qui decide quand un agent peut agir et quand il doit s'arreter
• Checklist de durcissement de securite MCP : 1,467 serveurs exposes et les controles qui les ferment — OWASP MCP08 (Lack of Audit and Telemetry) et les controles qui le ferment

---

Un distributeur mid-market executant un agent qui screening 85 fournisseurs par semaine pour la conformite a besoin de plus que des pistes d'audit separees. Il a besoin d'un engagement tripartite qui lie ce qui a ete promis (l'offre signee), ce qui a ete execute (le transcrit MCP) et ce qui a ete regle (le txid on-chain) en un recu. Un auditeur recalcule chaque hachage independamment, puis confirme que la liaison couvre les trois. Le replay inter-session est detecte par une discordance de hachage, non prevenu par une politique. C'est l'architecture que nous construisons : les modules MCP produisent le transcrit, x402 produit le reglement, la couche d'audit compose la liaison, et le verificateur verifie tout sans faire confiance a aucune partie de la chaine.

Demandez une construction delimitree. Decouverte d'une semaine. Vous obtenez un inventaire systeme, une cartographie des flux de travail et un perimetre fixe — que vous construisiez avec nous ou non.