💻 computer science

Free-Riding in the AI Economy: Demystifying Logic Flaws in x402-Enabled Payment Systems

Este artículo presenta el primer análisis de seguridad exhaustivo del protocolo x402, revelando vulnerabilidades críticas como brechas en el diseño de firmas y condiciones de carrera que permiten el uso gratuito (free-riding) y la fuga de recursos en sistemas de pago impulsados por IA, y propone mitigaciones arquitectónicas para asegurar las transacciones de máquina a máquina.

Autores originales: Shengchen Ling, Yihang Huang, Yuan Chen, Yajin Zhou, Lei Wu, Cong Wang

Publicado 2026-06-01

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Shengchen Ling, Yihang Huang, Yuan Chen, Yajin Zhou, Lei Wu, Cong Wang

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina un bullicioso mercado digital donde los robots (agentes de IA) compran y venden servicios entre sí a la velocidad del rayo. No tienen cajeros ni gerentes humanos; simplemente hablan entre sí e intercambian monedas digitales instantáneamente. Para que esto funcione, se inventó un nuevo sistema llamado x402. Es como un letrero universal de "Pague para Entrar" que los robots pueden leer y obedecer automáticamente.

Sin embargo, este documento es un informe de seguridad que dice: "Las cerraduras de este mercado están rotas".

Los investigadores descubrieron que, debido a que el sistema intenta ser demasiado rápido y demasiado flexible, ha creado un "vacío" entre el momento en que un robot dice que pagará y cuando el dinero realmente llega. Este vacío permite que actores malintencionados engañen al sistema para obtener trabajo gratis.

Aquí hay un desglose de las cuatro formas principales en que ocurre este "Free-Riding" (aprovecharse sin pagar), utilizando analogías sencillas:

1. El problema del "Ticket Equivocado" (Sustitución de Recursos Cruzados)

La Analogía: Imagina que compras una entrada para una película llamada The Matrix. La entrada dice: "Una entrada, $10". Pero el guardia de seguridad del cine solo revisa el precio ($10) y no el título de la película.
El Fallo: Un hacker compra una entrada para la película barata (The Matrix) pero se acerca a la entrada de la sala VIP de la película cara (Dune). El guardia ve la entrada de $10, asiente y lo deja pasar.
La Realidad: En el sistema x402, la "firma" digital que un robot utiliza para pagar no especifica estrictamente a qué servicio específico está pagando, sino solo cuánto y a quién. Un hacker puede tomar un comprobante de pago válido para una llamada de API barata y usarlo para desbloquear un servicio de IA premium y más caro. El sistema acepta el dinero pero entrega el producto equivero (y más valioso).

2. El problema de la "Doble Reserva" (Duplicación de Servicio Probabilística)

La Analogía: Imagina un hotel con una recepción muy lenta. Te acercas y dices: "Tengo una reservación". El empleado revisa la computadora, ve que tu nombre está libre y dice: "¡Genial, vaya a su habitación!".
Mientras el empleado aún está escribiendo el registro en el libro contable principal, tú regresas a la recepción con un amigo y dices: "Yo también tengo una reservación". Debido a que el empleado aún no ha terminado de escribir la primera, la computadora todavía parece "libre" para la segunda persona. Ambos obtienen una llave de habitación, pero el hotel solo les cobró una vez.
El Fallo: El sistema x402 verifica si un pago es válido (el "chequeo"), pero no bloquea inmediatamente la transacción para que nadie más pueda usarla (el "bloqueo"). Un hacker puede enviar la misma solicitud de pago 20 veces en una fracción de segundo. El servidor, moviéndose rápido, dice "Sí" a las 20 solicitudes antes de que la blockchain (el libro contable principal) tenga tiempo de decir: "¡Espera, ese pago ya fue usado!". El comerciante entrega 20 servicios pero solo recibe el pago de uno.

3. El problema del "Cheque en Blanco" (Sobregiro de Asignación)

La Analogía: Imagina que le das a un mesero una tarjeta de crédito con un límite de $100 y le dices: "Pida lo que quiera, solo no se pase de $100". El mesero comienza a pedir filetes caros.
El problema es que el mesero pide 10 filetes antes de que el banco tenga tiempo de verificar si realmente tienes el dinero. Para cuando el banco intenta cargar la tarjeta, ya has gastado $500. El banco rechaza el cargo, pero el mesero ya sirvió la comida. Te quedas con la comida gratis; el restaurante asume el costo.
El Fallo: En el mundo de la IA, el costo de una tarea no se conoce hasta que termina. Los hackers configuran un "límite de gasto" (asignación) que es justo lo suficiente para pasar un chequeo rápido. Luego activan tareas de IA masivas y costosas. El sistema comienza el trabajo inmediatamente (porque el chequeo pasó), pero para cuando se calcula la factura final, el hacker ha gastado más de su límite. La blockchain rechaza el pago, pero la IA ya realizó el trabajo.

4. El problema del "Atasco de Tráfico" (Denegación de Liquidación)

La Analogía: Imagina una cabina de peaje que solo puede procesar 10 autos por minuto. Un hacker envía 50 autos a través de la puerta a la vez. La puerta se abre para los 50 porque el chequeo de "entrada" es rápido. Pero cuando los autos intentan pagar en la cabina al final, la cabina está abrumada y solo puede procesar 10. Los otros 40 autos se van sin pagar.
El Falla: El sistema tiene un límite en cuántos pagos puede procesar por segundo. Los hackers inundan el sistema con solicitudes. El servidor entrega el servicio a todos ellos porque la "entrada" es rápida, pero el lado del "pago" se congestiona. El servidor termina entregando servicios gratuitos porque no puede procesar los pagos lo suficientemente rápido como para decir "No".

El Panorama General: Por qué esto importa

El documento argumenta que el sistema x402 intenta hacer dos cosas que no se mezclan bien:

Velocidad Web: Interacciones instantáneas de "confía en mí" (como las solicitudes HTTP).
Seguridad de Blockchain: Seguridad de "verifica todo primero" (como la finalidad de la blockchain).

Al intentar unir estas dos, el sistema creó un "vacío de tiempo". En ese vacío, los actores malintencionados pueden filtrarse.

Las Soluciones Propuestas

Los autores sugieren algunas formas de arreglar esto, esencialmente diciéndole al sistema que sea más cuidadoso:

Vincular el ticket al asiento específico: Asegurarse de que la firma digital diga exactamente qué servicio se está comprando, no solo el precio.
Poner un cartel de "No Molestar" en el libro contable: Cuando se está verificando un pago, bloquearlo inmediatamente para que nadie más pueda usarlo hasta que se confirme.
No servir la comida hasta que el cheque se liquide: Para las tareas de IA, no transmitir los resultados al usuario hasta que el pago esté realmente confirmado. Si el pago falla, el usuario no recibe nada.
Verificar la capacidad de la cabina de peaje: Si el sistema de pago está demasiado ocupado para procesar una factura, no dejar entrar al auto en absoluto.

En resumen: El documento revela que los "rieles económicos" para los agentes de IA están actualmente llenos de agujeros por donde la gente puede robar servicios. Para arreglarlo, necesitamos dejar de ser tan optimistas sobre los pagos y empezar a asegurar las cosas, incluso si eso hace que todo sea ligeramente más lento.

Resumen Técnico: El Aprovechamiento Gratuito en la Economía de la IA

1. Planteamiento del Problema

El surgimiento de la economía de agente a agente (A2A) requiere rieles financieros programáticos capaces de gestionar transacciones autónomas de alta frecuencia. El protocolo x402 ha emergido como el estándar de facto para los pagos de máquina a máquina, utilizando el código de estado HTTP 402 "Payment Required" para incrustar instrucciones de pago criptográficas directamente en las solicitudes de la capa de aplicación.

Sin embargo, la operacionalización de x402 introduce una disonancia arquitectónica fundamental: intenta unir ciclos de solicitud-respuesta HTTP sincrónicos y efímeros con la finalidad de blockchain asincrónica y probabilística. Este documento sostiene que las implementaciones actuales del ecosistema x402 no logran imponer invariantes de seguridad críticos debido a este vacío de sincronización de estado. Específicamente, el desacoplamiento de la verificación (off-chain) y la liquidación (on-chain) crea condiciones de carrera y ambigüedades semánticas que permiten a los atacantes "aprovecharse gratuitamente" (free-ride), obligando a los comerciantes a subsidiar los costos de cómputo y exponiendo al sistema a una explotación económica sistémica.

2. Metodología

Los autores emplean un marco de análisis de seguridad riguroso que combina el modelado formal y la validación empírica:

Modelado Formal del Sistema: El flujo de trabajo de pago se modela como un sistema de transición de estados que involucra a cuatro entidades: Comprador ( $S$ ), Comerciante ( $M$ ), Facilitador ( $F$ ) y Blockchain ( $B$ ).
Invariantes de Seguridad: Los autores definen cinco Invariantes de Seguridad fundamentales que una implementación segura debe mantener:
1. Integridad de Pago (I1): La entrega implica la confirmación de la liquidación on-chain.
2. Consistencia de Valor (I2): El valor de la transacción debe satisfacer la lógica de precios del recurso.
3. Vinculación de Contexto (I3): La autorización de pago debe estar vinculada criptográficamente al identificador de recurso específico.
4. Unicidad de Autorización (I4): Un nonce de pago debe consumirse exactamente una vez.
5. Conservación de Ejecución (I5): No se debe iniciar un trabajo computacional significativo a menos que el pago esté asegurado.
Análisis de Vulnerabilidades: Los autores analizan la especificación del protocolo y auditan los SDK oficiales (TypeScript, Python, Java, Go) y los despliegues de middleware en vivo (Thirdweb, Coinbase).
Validación Empírica: Se realizaron experimentos controlados en múltiples testnets (Base Sepolia, Solana Devnet, Arbitrum Sepolia) y contra despliegues oficiales para cuantificar las tasas de éxito de los ataques identificados.

3. Hallazgos Clave y Vulnerabilidades

El análisis revela que las implementaciones actuales violan sistemáticamente los invariantes definidos, lo que conduce a tres clases primarias de vulnerabilidades:

A. Sustitución de Recursos Cruzados (Violación de I3)

Mecanismo: El diseño del protocolo x402 depende de firmas EIP-712 que vinculan los fondos a una dirección de comerciante, pero son agnósticas al contexto respecto al identificador de recurso específico ( $ID_r$ ).
Defecto: Los SDK oficiales no vinculan criptográficamente la firma al contexto de la solicitud HTTP (URI, método, cuerpo).
Exploit: Un atacante puede generar una firma de pago válida para un recurso de bajo valor o sin restricciones ( $r_A$ ) y sustituirla para acceder a un recurso diferente, de alto valor o restringido ( $r_B$ ), con el mismo precio.
Resultado: En los experimentos, esto condujo a una tasa de éxito del 100% en la sustitución de recursos. En escenarios concurrentes, permitió la "duplicación de servicio" donde un solo pago desbloqueó múltiples recursos.

B. Duplicación de Servicio Probabilística (Violación de I4)

Mecanismo: Existe una condición de carrera de tipo Time-of-Check to Time-of-Use (TOCTOU) entre la verificación off-chain de un nonce y su liquidación on-chain.
Defecto: La lógica de verificación del Facilitador es sin estado (stateless) y de solo lectura; no bloquea el nonce.
Exploit: Un atacante lanza $N$ solicitudes concurrentes con el mismo payload firmado. Múltiples hilos del servidor verifican el nonce como "no utilizado" simultáneamente antes de que el primer hilo actualice con éxito el estado de la blockchain.
Resultado: El comerciante entrega el servicio $N$ veces, pero solo una transacción se liquida on-chain. Los experimentos en la testnet de Base Sepolia demostraron una tasa de éxito del 6% para la duplicación de servicios, lo que plantea un riesgo de arbitraje escalable para agentes de IA de alta frecuencia.

C. Derivas de Estado Específicas de la IA (Violación de I2 e I5)

En el dominio de la inferencia de IA, el cambio hacia el precio dinámico (usando esquemas de autorización "hasta" o upto) exacerba las vulnerabilidades:

Sobregiro de Asignación (Allowance Overdraft): Debido a que el costo de la inferencia de un LLM es desconocido hasta su finalización, los comerciantes deben verificar un límite de gasto ( $V_{max}$ $V_{ma x}$ ) en lugar de un monto exacto. Los atacantes explotan la falta de bloqueo atómico de la asignación. Al lanzar $N$ $N$ solicitudes concurrentes donde $\sum v_i \gg V_{max}$ $\sum v_{i} ≫ V_{ma x}$ , el atacante consume recursos para todas las solicitudes. La blockchain revierte las transacciones excedentes, pero el comerciante ya ha entregado el output computacional.
- Impacto: Los experimentos mostraron una relación de fuga ( $\rho$ ) de hasta el 97.76%, lo que significa que los atacantes recibieron casi el 100% de los recursos computacionales mientras pagaban solo una fracción del costo.
Denegación de Liquidación: Los atacantes pueden inundar el sistema con solicitudes válidas que exceden los límites de tasa de liquidación del Facilitador (por ejemplo, 10 tx/s). La capa de verificación acepta la ráfaga y el comerciante entrega el servicio, pero la API de liquidación rechaza las transacciones excedentes.
- Impacto: En casos extremos, esto resultó en una relación de fuga del 100%, donde el comerciante proporcionó el servicio completo por cero pago.

4. Mitigaciones Propuestas

El documento propone cuatro estrategias de defensa jerárquicas para restaurar los invariantes de seguridad:

Vinculación de Contexto Criptográfico: Extender los esquemas EIP-712 para incluir un hash de la solicitud HTTP completa (Método, URI, Cuerpo) en la firma. Esto elimina la brecha semántica, haciendo que las firmas sean inválidas si se replican contra diferentes recursos.
Linealización de Nonce con Estado: Implementar un modelo de "Verificar y Establecer" (Check-and-Set) a nivel del Facilitador utilizando bloqueos distribuidos (por ejemplo, SETNX). Esto asegura que incluso si múltiples hilos verifican un nonce, solo el primero en adquirir el bloqueo proceda a la liquidación, eliminando las condiciones de carrera.
Entrega de Recursos Pesimista:
- Entrega Diferida: Almacenar en búfer el output de la inferencia de IA hasta que la liquidación sea confirmada. Esto neutraliza el incentivo económico para el robo (el atacante no obtiene datos si el pago falla).
- Bloqueo de Dos Fases: Para escenarios de alto riesgo, transferir el tope máximo a un contrato de custodia (escrow) antes de la ejecución para atomizar la verificación de la asignación.
- Anti-Griefing Criptoeconómico: Requerir que los agentes depositen una "fianza de gas" (gas bond) para cubrir posibles reversiones de liquidación, penalizando la fianza si el agente intenta realizar un griefing al comerciante.
Diseño de Fallo Cerrado (Failure-Closed): Sincronizar los límites de tasa y las verificaciones de facturación con la entrada de la solicitud. Si la capacidad de liquidación se excede, la solicitud debe ser rechazada inmediatamente (429) en lugar de procesarse y entregarse gratuitamente.

5. Significación y Reivindicaciones

El documento afirma ser el primer análisis de seguridad integral del ecosistema x402. Su significancia radica en:

Identificación de Riesgo Sistémico: Demuestra que la disonancia arquitectónica entre los protocolos web y las blockchains no es simplemente un error de implementación, sino un fallo estructural que socava el modelo de confianza económica de la web de agentes.
Formalización de Invariantes de Seguridad: Establece un marco formal (los cinco invariantes) necesario para asegurar sistemas híbridos de agentes, proporcionando una base para el diseño de protocolos futuros.
Exposición de la Amenaza de "Aprovechamiento Gratuito": Cuantifica cómo los modelos actuales de precios dinámicos en la IA pueden ser instrumentalizados para forzar a los comerciantes a subsidiar los costos de cómputo a escala, amenazando la viabilidad de la economía de la IA.
Divulgación Responsable: Todos los problemas identificados han sido comunicados a Coinbase y Thirdweb, resaltando la necesidad inmediata de cambios arquitectónicos desde la "laxitud ergonómica" hacia una "vinculación criptográfica rigurosa".

Los autores conclizan que, sin la adopción de middleware con gestión de estado y mecanismos de bloqueo pesimista, la economía de la IA corre el riesgo de construir su base financiera sobre rieles propensos al aprovechamiento gratuito sistémico.