La liquidación sin prueba de ejecución es una caja negra pagada: cerrando el ciclo de auditoría de pagos del agente

Puntos clave

• x402 procesó 169 millones de pagos de agentes en Base en su primer año, pero payment_hash solo demuestra que una transacción se liquidó — no lo que hizo el agente — la extensión de recibo (OMA3/x402, fusionada en el protocolo) registra quién pagó, qué servicio, cuándo y una referencia de pago, pero no qué versión de screening, qué regla de política o qué versión de modelo se ejecutó en el lado del servidor (Chainalysis, 2026; OMA3, 2026).
• El borrador IETF action_ref (draft-etcheverry-action-ref-02, julio 2026) define un identificador direccionado por contenido — SHA-256 sobre JSON canónico de agent_id, action_type, scope, timestamp — que cualquier auditor recomputa sin confiar en el emisor — con campos opcionales para la auditabilidad de versiones de política, de modo que un auditor pueda determinar no solo que la regla 7 se disparó, sino qué versión de la regla 7 estaba activa en ese momento.
• El borrador IETF x402-retention-chain (draft-hopley-x402-retention-chain-06, junio 2026) formaliza la composición: un Settlement-Action Binding (binding_ref) vincula payment_hash con action_ref en un recibo — más un Policy Binding (policy_bound_ref) que vincula la versión de política vigente con la acción, y un Compliance Gate Binding (gate_ref) que vincula un veredicto ALLOW/REFER/DENY con la referencia de política.
• Todas las construcciones usan solo SHA-256 y JCS (RFC 8785), verificables por cualquier parte que tenga los recibos sin contactar al emisor — satisfaciendo los requisitos de pista de auditoría de MiCA Artículo 80, DORA Artículo 14 y AMLR Artículo 56 (IETF draft-hopley-x402-retention-chain-06, 2026).
• La liquidación sin prueba de ejecución es una caja negra pagada; la prueba de ejecución sin liquidación es una afirmación no verificable; los agentes necesitan ambas para cerrar el ciclo de confianza — x402 liquida el intercambio, action_ref vincula el contexto de ejecución y binding_ref los compone en un recibo auditable.

El problema: seis protocolos, cero recibos de ejecución

El stack de comercio de agentes convergió en 2026: UCP (descubrimiento), A2A (comunicación), MCP (herramientas), ACP (checkout), AP2 (autorización), x402 (liquidación). Seis capas, más de sesenta socios de lanzamiento — Google, Shopify, OpenAI, Stripe, Visa, Coinbase. Cada compra está cubierta: el agente descubre, negocia, usa herramientas, hace checkout, obtiene autorización y paga.

Excepto una cosa: la prueba de que el agente realmente hizo lo que se suponía que debía hacer.

x402 liquida el pago. El payment_hash demuestra que la transacción se completó en Base en aproximadamente 200ms. La extensión de recibo x402 (fusionada en el protocolo mediante la colaboración OMA3/x402) añade una prueba de compra firmada y portátil — quién pagó, qué servicio se accedió, cuándo y una referencia de pago. Este recibo está firmado digitalmente por el servicio, es a prueba de manipulaciones y verificable universalmente.

No registra qué ocurrió dentro del servicio. El recibo demuestra que el agente pagó. No demuestra qué versión de screening se ejecutó, qué regla de política se disparó o qué versión de modelo produjo la decisión. Para una verificación de cumplimiento de proveedor, el recibo demuestra que el agente pagó por la llamada al API de screening. No demuestra qué versión de la lógica de screening se ejecutó realmente.

Para aprovisionamiento regulado — EU AI Act Artículo 12, entrada en vigor el 2 de agosto de 2026, FCA SYSC 9.1, SOC 2 CC7.x — esa brecha es el bloqueador de cumplimiento. Los logs pueden reescribirse. Un recibo de pago que no se vincula a la ejecución es una caja negra pagada.

La solución: dos borradores IETF que componen liquidación y ejecución

action_ref — identidad de ejecución direccionada por contenido

El borrador IETF action_ref (draft-etcheverry-action-ref-02, 23 de julio de 2026) define un identificador determinista direccionado por contenido para acciones de agentes. El identificador se calcula como:

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

Donde JCS es el JSON Canonicalization Scheme (RFC 8785), que produce una secuencia de bytes única para cualquier valor JSON. Los cuatro campos de preimagen:

Campo	Qué captura
agent_id	El ejecutor terminal tras la resolución de delegación (en una cadena A→B→C, agent_id es C)
action_type	Etiqueta semántica (payment.send, compliance.screen, oracle.signal)
scope	El alcance de intención solicitada por el agente en el punto de acción
timestamp	RFC 3339 UTC con exactamente 3 dígitos de milisegundos

El objetivo de diseño es la independencia del operador: un verificador que tenga los cuatro campos puede recomputar action_ref sin llamar a la infraestructura del emisor. El borrador incluye campos opcionales para auditabilidad de rotación de política — de modo que un auditor pueda determinar no solo que la regla 7 se disparó, sino qué versión de la regla 7 estaba activa en ese momento.

x402-retention-chain — la capa de vinculación

El borrador IETF x402-retention-chain (draft-hopley-x402-retention-chain-06, 24 de junio de 2026) define siete construcciones criptográficas. Tres son directamente relevantes para el ciclo pago → liquidación → auditoría:

1. Settlement-Action Binding (binding_ref) — vincula el payment_hash de x402 con action_ref en un recibo. Una atestación de liquidación ahora demuestra no solo que ocurrió un pago, sino a qué acción verificada del agente corresponde. Un auditor que tiene el recibo sigue la cadena desde payment_hash hasta action_ref y luego al registro de la acción, confirmando ambos sin contactar al emisor.

2. Policy Binding (policy_bound_ref) — vincula una instantánea direccionada por contenido de la política vigente con la acción. Una decisión de screening es verificable contra la versión exacta de la política en vigor cuando se tomó. Una rotación de política es detectable por recomputación — el hash cambia cuando la política cambia, de modo que el auditor ve la transición.

3. Compliance Gate Binding (gate_ref) — vincula un veredicto de cumplimiento ALLOW/REFER/DENY y una referencia de pagador sin PII con la referencia de política. El resultado del screening está probadamente vinculado a la versión de la regla que lo produjo, sin datos personales en el registro vinculado.

Todas las construcciones usan solo SHA-256 y JCS. No se requiere infraestructura externa. No hay contacto con el emisor. Cualquier parte que tenga los recibos puede verificar.

El ciclo de auditoría: pago → liquidación → registros auditables

El ciclo completo para una transacción de comercio de agentes regulada:

1. Pago — el agente llama a un API de pago (screening de cumplimiento de proveedor, verificación de proveedor, búsqueda de producto). El servidor devuelve HTTP 402 con los términos de pago.

2. Liquidación — el agente firma una autorización, reintenta con PAYMENT-SIGNATURE, el facilitador verifica y liquida en Base en aproximadamente 200ms. El servidor devuelve el recurso con un recibo de liquidación que contiene payment_hash.

3. Ejecución — el agente realiza la acción (screening, búsqueda, decisión). Emite action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp})) — un identificador direccionado por contenido que cualquier tercero puede recomputar a partir de los cuatro campos de preimagen.

4. Vinculación — el binding_ref enlaza payment_hash con action_ref en un recibo. El policy_bound_ref enlaza la versión de política vigente con la acción. El gate_ref enlaza el veredicto de cumplimiento con la referencia de política.

5. Auditoría — un auditor (regulador, contraparte, cumplimiento interno) tiene el recibo compuesto. Recomputa action_ref a partir de los cuatro campos. Verifica payment_hash contra la blockchain Base. Comprueba policy_bound_ref para confirmar que el screening se ejecutó bajo la versión de política correcta. Comprueba gate_ref para confirmar que el veredicto coincide. Sin llamar al operador. Sin confianza requerida.

El ciclo responde: pago liquidado, esta versión específica de screening se ejecutó, bajo esta versión de política, en este timestamp, con este veredicto. Dos capas, un recibo.

Por qué cada capa por sí sola falla

El diagrama de abajo muestra el ciclo completo — pago, liquidación, ejecución, vinculación y auditoría — y por qué cada capa por sí sola es insuficiente:

La liquidación sin prueba de ejecución es una caja negra pagada. El recibo dice que el agente pagó por un screening de cumplimiento. No dice qué versión de la lógica de screening se ejecutó, si la política estaba vigente o si el veredicto fue correcto. Un regulador que pregunta "¿verificó a este proveedor contra la lista de sanciones de julio de 2026 o la de junio de 2026?" no obtiene respuesta de payment_hash solo.

La prueba de ejecución sin liquidación es una afirmación no verificable. El agente dice que verificó al proveedor. Sin un recibo de pago que vincule el screening a una transacción liquidada, no hay evidencia económica de que el screening realmente ocurrió. La afirmación es gratis de hacer e inútil de auditar.

La combinación cierra el ciclo de confianza. La liquidación ancla el evento económico — prueba de que el dinero se movió. La prueba de ejecución ancla el evento semántico — prueba de qué se hizo. La vinculación los enlaza. Un auditor verifica ambos desde un recibo, recomputando hashes sin confiar en ninguna parte de la cadena.

Qué significa esto para un build B2B

Un agente de aprovisionamiento que realiza pedidos, autoriza pagos y verifica proveedores necesita el ciclo completo en su pista de auditoría. La arquitectura:

• x402 maneja la liquidación. El agente encuentra una respuesta 402 del API de cumplimiento de proveedor, paga en USDC en Base y recibe un recibo de liquidación con payment_hash.
• action_ref maneja la identidad de ejecución. El agente emite action_ref para cada acción de screening de cumplimiento, registrando agent_id, action_type (compliance.screen), scope (ID de proveedor y tipo de screening) y timestamp.
• binding_ref los compone. El recibo de liquidación lleva payment_hash y action_ref en un sobre. El policy_bound_ref registra qué versión de política gobernó el screening. El gate_ref registra el veredicto ALLOW/DENY.
• La pista de auditoría es la cadena de recibos compuestos. Un auditor recomputa action_ref a partir de los cuatro campos, verifica payment_hash on-chain, comprueba el hash de la versión de política y confirma el veredicto — todo sin contactar al operador del agente, al facilitador de pago o al servicio de screening.

Para una industria regulada — cumplimiento GMP farmacéutico, screening ITAR aeroespacial, verificaciones de sanciones de servicios financieros — esta es la diferencia entre un agente auditable y un agente que es un pasivo de cumplimiento. El requisito de mantenimiento de registros del Artículo 12 del EU AI Act (entrada en vigor el 2 de agosto de 2026) exige trazabilidad de las decisiones del sistema de IA. El Artículo 80 de MiCA requiere registros de transacciones. El Artículo 14 de DORA requiere pistas de auditoría para la resiliencia operativa. La construcción binding_ref satisface los tres desde un recibo.

Lecturas relacionadas

• Cuando el agente realiza el pedido: cómo los pagos agénticos cierran el ciclo de aprovisionamiento B2B — el ciclo de procure-to-pay desde RFQ hasta conciliación de pagos con protocolos de pago agéntico
• 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
• Gobernanza proporcional del agente: por qué la confianza binaria falla — correspondencia entre niveles de autonomía y riesgo, incluyendo el punto de autorización de pago
• Cumplimiento del EU AI Act para despliegues de agentes — el requisito de mantenimiento de registros del Artículo 12 que el ciclo de auditoría satisface

---

Un distribuidor mid-market que ejecuta un agente que verifica 85 proveedores por semana para cumplimiento necesita más que un recibo de pago. Necesita prueba de que el screening se ejecutó bajo la versión de política correcta, en el momento correcto, con el veredicto correcto — vinculado al pago que lo financió. La construcción binding_ref compone la liquidación x402 y la ejecución action_ref en un recibo que cualquier auditor puede verificar sin confiar en el operador. Ese es el ciclo de auditoría: pago → liquidación → registros auditables. Dos capas, un recibo, cero confianza en el emisor.