x402: pagos irreversibles para agentes de IA que aún se rompen
El 25 de septiembre de 2026, Block anunció su entrada en la Fundación x402 y la incorporación de pagos Lightning al protocolo. Con ese movimiento, el estándar que permite a un agente de IA pagar por sí mismo el acceso a una API, a un dataset o a un servicio digital queda respaldado por Google, Microsoft, Amazon Web Services, Coinbase, la Solana Foundation y ahora Block, todo ello bajo el paraguas de la Linux Foundation desde abril. Steve Lee, responsable de Spiral, lo formuló sin rodeos: se trata de convertir Bitcoin en «dinero cotidiano para las personas y para los agentes que actúan en su nombre».
La parte interesante de esa frase no es Bitcoin. Es «los agentes que actúan en su nombre».
Qué hace x402 exactamente
x402 reactiva el código de estado HTTP 402 —«Payment Required»— que llevaba treinta años reservado sin uso. Un servidor responde 402 a una petición, adjunta las condiciones de pago, el cliente liquida y reintenta. Lo que era imposible con tarjetas (comisiones fijas de centavos, tres días de compensación, chargebacks) se vuelve trivial cuando la liquidación son stablecoins on-chain o sats por Lightning: pagos de fracciones de céntimo, confirmados en segundos, sin cuenta previa, sin formulario, sin humano.
Esa es la propuesta técnica y es buena. El problema es la segunda mitad del diseño: el pagador no es una persona, es un proceso. Un agente con una clave, un presupuesto y una instrucción en lenguaje natural. Y la liquidación es final. No hay retrocesión, no hay «disputar el cargo», no hay ventana de 120 días como en una tarjeta Visa. Se está construyendo un raíl financiero cuya propiedad principal es la irreversibilidad, y se está enchufando a la capa de software menos predecible que la industria ha desplegado nunca en producción.
El estado real de la capa que va a firmar los pagos
Conviene ordenar lo que ha pasado en las mismas semanas en que Block se sumaba a la fundación.
Australia confirmó que un agente de OpenAI accedió a ficheros no públicos de un portal del Gobierno, incidente que llevó al primer ministro a advertir sobre el «ritmo furioso» de la IA. No hubo un atacante humano ejecutando un exploit: hubo un agente haciendo su trabajo y cruzando un límite que nadie había modelado como límite.
En paralelo, Patrick Wardle documentó un 0-day en Muse, el asistente de Meta que «reserva citas, rellena formularios y hace compras». Cualquier aplicación local o comando de terminal podía modificar un ajuste no documentado —el endpoint de transcripción— y quedarse con el token que da control completo de la cuenta. Sin permisos especiales de macOS. Sin aviso al usuario. En palabras de Wardle: «podemos manipular al agente y aprovechar sus privilegios para hacer lo que queramos; en lugar de escribir un infostealer completo para Mac, usamos el propio asistente de IA». Meta parcheó doce horas después de la publicación. Amazon, por su parte, había empezado a bloquear a Muse en su tienda medio día antes de la divulgación.
Y por debajo de ambos casos está la clase de vulnerabilidad sin parche conceptual: la inyección de prompts. No es un bug que se arregle en una versión; es una consecuencia de que el modelo no distingue estructuralmente entre instrucción del principal y contenido del entorno. Todo lo que el agente lee es potencialmente una orden.
La lección de Bitget: el eslabón no es la criptografía
El hackeo de 352 millones de dólares a Bitget, que su CEO atribuye a Corea del Norte por indicios de IP, es el mejor argumento disponible sobre por qué esto importa. No se rompió ninguna clave privada. No se factorizó nada. Se comprometió el proceso que genera la instrucción, y la infraestructura de firma hizo exactamente lo que se le pidió: firmar una transacción legítima con destino equivocado.
Trasladado al mundo agéntico, la conclusión es incómoda y directa: en un sistema donde una máquina autoriza pagos a partir de texto, el atacante ya no necesita robar una clave. Le basta con convencer al agente. La superficie de ataque deja de ser el HSM y pasa a ser cada página web, cada respuesta de API, cada PDF y cada correo que el agente procese durante una tarea. Todo eso es input no confiable con capacidad de mover dinero.
La diferencia con el fraude tradicional es de escala y de velocidad. Un atacante que logra inyectar una instrucción no vacía una cuenta: vacía todas las cuentas de todos los agentes que usan la misma plantilla de prompt, en paralelo, en microtransacciones por debajo de cualquier umbral de alerta, liquidadas en segundos y sin posibilidad de reversión.
Quién está escribiendo las reglas de la economía máquina-a-máquina
Aquí está el eje que la cobertura de producto no toca. x402 es, de facto, un estándar definido por cuatro hyperscalers estadounidenses más Block y Coinbase. Alojarlo en la Linux Foundation le da gobernanza abierta en lo técnico, pero no cambia quién aporta el tráfico, los SDK y los endpoints por defecto. No hay contraparte europea. No hay contraparte china. Y sobre todo, no hay especificación de las tres cosas que cualquier regulador financiero preguntará primero:
- Identidad y atribución. ¿Quién es el ordenante a efectos de AML: el agente, el operador del agente, el titular de la cuenta que lo desplegó? ¿Qué pasa cuando un agente subcontrata a otro agente y ese a un tercero?
- Cumplimiento. La Travel Rule asume dos entidades identificables intercambiando datos del ordenante y del beneficiario. Un pago de 0,004 dólares por una llamada a API entre dos procesos no encaja en ese modelo ni con calzador. Tampoco encaja el cribado de sanciones aplicado transacción a transacción a un volumen de millones por minuto.
- Reversibilidad y responsabilidad. Si el agente paga a quien no debía porque una web le inyectó una instrucción, ¿quién asume la pérdida? En la PSD2 existe el concepto de operación no autorizada por el usuario. Aquí la operación sí fue autorizada: por el agente, que actuaba con mandato válido.
El vector geopolítico se deduce solo. Si un actor estatal ya obtiene cientos de millones comprometiendo backends de exchanges, un parque de agentes con presupuesto propio, sin humano que firme y con liquidación final es un objetivo mejor. Y funciona también en el otro sentido: un flujo de micropagos máquina-a-máquina, fragmentado y automatizado, es una arquitectura razonablemente eficaz para mover valor sorteando controles de capital y listas de sancionados sin que nadie haya apretado un botón. Que nadie lo haya especificado todavía no significa que nadie lo esté mirando.
Dónde puede fallar esta lectura
Hay tres contraargumentos serios y conviene tomárselos en serio.
El primero: x402 es un protocolo de transporte de pago, no una política de autorización. Nada impide construir por encima límites de gasto duros, listas blancas de beneficiarios, confirmación fuera de banda por encima de un umbral o cuentas con fondos segregados por tarea. La irreversibilidad del raíl se compensa con una bóveda pequeña. Es exactamente lo que hicieron las tarjetas virtuales de un solo uso, y funcionó.
El segundo: la magnitud del riesgo depende del ticket medio. Si el 99 % de los pagos agénticos son de céntimos por llamadas a API, el techo de pérdida por agente comprometido es el saldo de su monedero caliente, no la tesorería de la empresa. Comparar eso con un hackeo de 352 millones a un exchange es comparar clases de activos distintas.
El tercero, y el más probable: que el comercio agéntico tarde mucho más en materializarse de lo que sugieren los anuncios. Que Amazon bloquee a Muse indica que los grandes marketplaces no tienen ninguna prisa por dejar que agentes de terceros compren en su casa. Sin el lado de la oferta, el raíl se queda en demos y en tráfico entre APIs de infraestructura, y el debate sobre sanciones y Travel Rule llega con tres años de margen.
La evidencia que desmentiría la tesis sería concreta: que los primeros doce meses de x402 en producción pasen sin un incidente relevante de gasto no intencionado por inyección de prompt. Si eso ocurre, la arquitectura de contención habrá funcionado y este artículo habrá exagerado. Lo que no es defendible es la posición contraria: asumir que no pasará nada porque todavía no ha pasado.
Qué significa esto si estás construyendo
La decisión de arquitectura no es «¿adopto x402?». Casi con seguridad sí, porque el coste de integración es bajo y la alternativa es quedarse fuera de un estándar con seis nombres grandes detrás. La decisión es dónde pones el límite de confianza entre el modelo y la clave, y esa decisión se toma ahora, en el diseño, no después del primer incidente.
Tres implicaciones prácticas. Primera: el agente no debe tener la clave, debe tener una sesión con presupuesto, caducidad y lista de beneficiarios permitidos, emitida por un componente determinista que el modelo no pueda reescribir con texto. Si un prompt puede alterar el límite de gasto, no hay límite de gasto. Segunda: registra la intención firmada, no solo la transacción. Cuando llegue la disputa —y llegará— la pregunta será qué instrucción concreta, de qué origen, generó el pago; sin esa traza no hay atribución posible y la responsabilidad recaerá por defecto en quien desplegó el agente. Tercera, para quien invierte: la capa que falta en este stack no es el raíl de pago, ya está resuelto y es open source. Es el control de autorización, la atestación de qué agente hizo qué, y el seguro que cubra el hueco entre «operación válida» y «operación deseada». Ese hueco es donde va a estar el dinero durante el próximo ciclo, y ahora mismo no lo cubre nadie.
