Compromiso de tres vías: Cómo nuestra pila vincula la intención de pago, el transcript de ejecución y la liquidación en un recibo verificable

Puntos clave

• Un compromiso de tres vías combina la intención de pago, el digest del transcript de ejecución y el txid de liquidación en un recibo — un auditor verifica cada uno de forma independiente y confirma que el hash combinado cubre los tres — el compromiso cubre todos los pasos o no los cubre; no hay cobertura parcial (IETF draft-hopley-x402-retention-chain-06, 2026).
• El replay entre sesiones se detecta por discrepancia de hash, no se previene por política — porque binding_ref combina payment_hash Y action_ref juntos, intercambiar un pago de la sesión A con una ejecución de la sesión B produce un hash combinado diferente; el verificador recomputa y obtiene una discrepancia (x402 GitHub issue #2332, 2026).
• Los módulos MCP producen el transcript de ejecución de forma nativa — cada llamada a herramienta (screening de compliance de proveedor, lookup de proveedor, drafting de cotización) se registra con argumentos, resultados y timestamps; el digest del transcript es action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp})), recomputable por cualquier parte que tenga los cuatro campos (IETF draft-etcheverry-action-ref-02, 2026).
• La liquidación x402 en Base produce payment_hash en ~200ms — el hash de la transacción on-chain es verificable de forma independiente consultando la blockchain de Base; no se requiere confianza en el operador ni en el facilitador (Chainalysis, 2026).
• Todas las construcciones usan SHA-256 y JCS (RFC 8785) — el mismo estándar de canonización que usa el audit trail de Hermes Agent (GitHub issue #487), por lo que el digest del transcript de ejecución se produce de forma nativa por el propio sistema de auditoría del agente, no añadido como capa adicional.

El problema: auditar cada paso por separado es necesario pero no suficiente

La pila de seis protocolos para el comercio de agentes (UCP, A2A, MCP, ACP, AP2, x402) cubre discovery, comunicación, tooling, checkout, autorización y liquidación. Cada protocolo produce su propia evidencia: x402 produce un payment hash, MCP produce un log de llamadas a herramientas, AP2 produce un mandate de autorización. Auditar cada paso por separado es necesario — necesitas verificar que el pago se liquidó, que la ejecución ocurrió y que la autorización fue válida.

Pero audit trails separados no son suficientes. Sin vinculación, un atacante puede mezclar un pago real de la sesión A con una ejecución real de la sesión B. Ambos son artefactos genuinos. Ninguno está falsificado. Pero no ocurrieron en la misma sesión. El recibo de pago prueba que ocurrió un pago. El log de ejecución prueba que se ejecutó un screening. Sin una vinculación que los conecte criptográficamente, no hay evidencia de que sean la misma transacción.

Este es el ataque de replay entre sesiones: tomar un payment_hash genuino de una transacción completada y emparejarlo con un action_ref genuino de una transacción diferente. Si el sistema de auditoría confía en el emparejamiento porque ambos artefactos son válidos individualmente, acepta un compuesto fabricado. El recibo de pago prueba que ocurrió un pago. El log de ejecución prueba que se ejecutó un screening. El paso de vinculación es donde este ataque se detecta — o donde no se detecta.

La arquitectura: cómo nuestra pila produce cada componente

El diagrama de abajo muestra el flujo completo del compromiso de tres vías — qué sistema produce cada artefacto, cómo la capa de vinculación los compone y cómo el auditor los verifica:

Cómo se produce cada componente en nuestra pila

Intención de pago: la oferta firmada x402

Cuando el agente llama a una API de screening de compliance de proveedor de pago, el servidor devuelve HTTP 402 con una oferta firmada. La extensión offer-receipt (integrada en el protocolo x402) compromete al servidor a términos de pago específicos: amount, asset, payTo address, el recurso exacto que se está fulfilling y una ventana de validez. La oferta se firma con EIP-712 (basada en wallet de Ethereum) o JWS (cualquier clave asimétrica, incluyendo Solana Ed25519).

La oferta es la intención de pago — lo que el agente está a punto de pagar. El auditor la hashea de forma independiente:

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

El auditor recomputa esto desde los términos de la oferta firmada y verifica la firma del servidor. No se requiere contacto con el payment backend — la oferta es un artefacto firmado portable.

Transcript de ejecución: el log de llamadas a herramientas MCP

Nuestros módulos MCP conectan al agente con APIs de compliance de proveedores, catálogos de proveedores y rails de pago. Cada llamada a herramienta MCP se registra: qué módulo se invocó, qué argumentos se pasaron, qué resultado se devolvió, en qué timestamp, bajo qué versión de política. Este es el transcript de ejecución.

El audit trail de Hermes Agent (GitHub issue #487) implementa logging de acciones con hash chaining SHA-256 y canonización RFC 8785 (JCS) — el mismo estándar que usan action_ref y binding_ref. El digest del transcript de ejecución se produce de forma nativa por el propio sistema de auditoría del agente:

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"
}))

El auditor recomputa action_ref desde estos cuatro campos preimage. No se requiere contacto con el agente ni su operador. La canonización está definida por RFC 8785, no por el serializador — por lo que el hash es determinista entre implementaciones.

El policy_bound_ref vincula la versión de política que estaba vigente cuando se ejecutó la acción. Si la lista de sanciones se actualizó entre junio y julio de 2026, el hash de política cambia y el auditor puede detectar qué versión estaba activa. El gate_ref vincula el veredicto ALLOW/DENY del screening de compliance con la referencia de política, por lo que el resultado está provablemente vinculado a la versión de regla que lo produjo.

Liquidación: el txid on-chain en Base

El facilitador x402 verifica la autorización de pago firmada del agente, construye la transacción on-chain y la transmite en Base. La liquidación se completa en aproximadamente 200ms. El facilitador devuelve el hash de la transacción (payment_hash) al servidor, que lo pasa al agente en el header PAYMENT-RESPONSE.

El auditor verifica payment_hash consultando la blockchain de Base — el txid es un registro público e inmutable. No se requiere confianza en el facilitador ni en el payment backend. El auditor confirma:

• La transacción existe en Base
• El amount coincide con los términos de la oferta
• La payTo address coincide con la oferta
• La transacción está confirmada (no pendiente)

La vinculación: cómo binding_ref compone los tres

El binding_ref (IETF draft-hopley-x402-retention-chain-06) compone los tres hashes en un compromiso:

binding_ref = SHA-256(JCS({
  offer_hash,      // lo que se prometió (intención de pago)
  action_ref,      // lo que se ejecutó (digest del transcript MCP)
  payment_hash     // lo que se liquidó (txid on-chain)
}))

Este es un compromiso de tres vías. El auditor verifica cada componente de forma independiente:

1. offer_hash — recomputar desde los términos de la oferta firmada, verificar la firma del servidor
2. action_ref — recomputar SHA-256 desde los cuatro campos preimage, sin contacto con el agente
3. payment_hash — consultar la blockchain de Base, confirmar que el txid existe y se liquidó

Luego el auditor recomputa binding_ref desde los tres y confirma que coincide. Si cualquier componente se intercambia — un pago de la sesión A emparejado con una ejecución de la sesión B — el hash combinado no coincidirá. El compromiso cubre los tres pasos o no los cubre. No hay cobertura parcial.

Cómo se detecta el replay entre sesiones

El ataque de replay entre sesiones funciona así: un atacante toma un payment_hash genuino de una transacción completada en la sesión A y lo empareja con un action_ref genuino de una transacción diferente en la sesión B. Ambos artefactos son reales. Ninguno está falsificado. Pero no ocurrieron en la misma sesión.

Sin vinculación, el sistema de auditoría verifica payment_hash y action_ref por separado, encuentra ambos válidos y acepta el compuesto. El audit trail muestra un pago que se liquidó y un screening que se ejecutó — pero son de transacciones diferentes.

Con binding_ref, el auditor recomputa el hash combinado desde el payment_hash y action_ref reales en el recibo. Si el atacante intercambió uno de una sesión diferente, los hashes son de contextos preimage diferentes y el binding_ref combinado no coincidirá con el valor del recibo. El verificador detecta la discrepancia. El compromiso no cubre todos los pasos, por lo que se rechaza.

Esto es lo que hace que el paso de vinculación sea la primitiva de confianza: no añade nueva evidencia, vincula evidencia existente criptográficamente. El payment hash en Base es verificable. El log de ejecución es verificable. La prueba de vinculación hace que el enlace entre ellos sea verificable. Sin el enlace, cada uno es una claim standalone. Con el enlace, son un recibo compuesto que un auditor puede verificar end to end.

Qué significa esto para la construcción

Un agente de procurement que hace screening de 85 proveedores por semana para compliance necesita el compromiso de tres vías en su audit trail. La implementación en nuestra pila:

• Los módulos MCP producen el transcript de ejecución. Cada llamada a herramienta se registra con argumentos, resultados, timestamps y versión de política. El digest del transcript es action_ref, computado de forma nativa por el sistema de auditoría de Hermes Agent usando canonización JCS.
• x402 maneja la liquidación. El facilitador liquida en Base y devuelve payment_hash. La extensión offer-receipt firma la intención de pago en la respuesta 402.
• La capa de auditoría (no el agente, no el payment backend) computa binding_ref desde offer_hash, action_ref y payment_hash. También computa policy_bound_ref y gate_ref para vincular la versión de política y el veredicto de compliance.
• El checkpoint human-in-the-loop en la autorización de pago ve el recibo compuesto: términos de oferta, resultado de ejecución, confirmación de liquidación, versión de política y veredicto — todos vinculados por binding_ref.
• Un auditor externo (regulador, contraparte, compliance interno) verifica el recibo compuesto recomputando cada hash de forma independiente. No se requiere contacto con el agente, el payment backend ni el operador de la capa de auditoría.

La verificación toma segundos: consultar Base para el txid, recomputar action_ref desde cuatro campos, recomputar offer_hash desde los términos firmados, recomputar binding_ref desde los tres. El compromiso cubre todos los pasos o no los cubre. Esa es la primitiva que hace que el comercio de agentes sea auditable end to end.

Lecturas relacionadas

• La liquidación sin prueba de ejecución es una caja negra pagada: cerrando el ciclo de auditoría de pagos del agente — el ciclo de auditoría de cinco pasos y los drafts IETF que definen binding_ref, policy_bound_ref y gate_ref
• Cuando el agente realiza el pedido: cómo los pagos agénticos cierran el ciclo de aprovisionamiento B2B — el ciclo de procure-to-pay con protocolos de pago agéntico (Mastercard Agent Pay, x402, Stripe agentic tokens)
• Kill-Switch by Design: arquitectura de gobernanza del agente — la capa de gobernanza que decide cuándo un agente puede actuar y cuándo debe detenerse
• MCP Security Hardening Checklist: 1,467 servidores expuestos y los controles que los cierran — OWASP MCP08 (Lack of Audit and Telemetry) y los controles que lo cierran

---

Un distribuidor mid-market que ejecuta un agente que hace screening de 85 proveedores por semana para compliance necesita más que audit trails separados. Necesita un compromiso de tres vías que vincule lo que se prometió (la oferta firmada), lo que se ejecutó (el transcript MCP) y lo que se liquidó (el txid on-chain) en un recibo. Un auditor recomputa cada hash de forma independiente, luego confirma que la vinculación cubre los tres. El replay entre sesiones se detecta por discrepancia de hash, no se previene por política. Esa es la arquitectura que construimos: los módulos MCP producen el transcript, x402 produce la liquidación, la capa de auditoría compone la vinculación y el verificador verifica todo sin confiar en ninguna parte de la cadena.

Solicita una construcción delimitada. Descubrimiento de una semana. Obtienes un inventario de sistemas, un mapa de flujo de trabajo y un alcance fijo — construyas o no con nosotros.