Permisos de agentes de IA en DeFi: EIP-7702, x402 y blast radius

Darle a un agente de IA (software que decide y ejecuta acciones solo, sin que un humano apruebe cada paso) permiso para firmar transacciones en DeFi crea un problema que ningún programa clásico tiene: si le entregas la llave de tu wallet, un solo prompt malicioso puede vaciarla en un bloque, de forma irreversible. En mayo de 2026, la brecha de Bankr comprometió 14 wallets: algunos usuarios reportaron pérdidas de hasta 150.000 dólares y el agregado ronda entre 170.000 y 440.000 dólares según la fuente, sin cifra oficial del propio Bankr — y las hipótesis de los expertos no apuntan al modelo de IA, sino al modelo de permisos: compromiso de tokens de sesión o aprobaciones con alcance sobre muchos usuarios. Al mismo tiempo, el protocolo x402 superó los 100 millones de transacciones de pago agéntico en la red Base, y el dinero migró de micropagos a pagos reales: las operaciones por encima de 1 dólar pasaron del 49 % al 95 % del volumen. Cada vez circula más dinero de verdad por manos de agentes, justo cuando el radio de daño de un permiso mal diseñado más importa. Este artículo construye el marco a fecha de 6 de julio de 2026: qué es el blast radius (radio de daño), los cuatro patrones de arquitectura de permisos, qué cambió con EIP-7702 y por qué el principio de "mínimo privilegio" es más difícil de aplicar on-chain que en cualquier otro software.

¿Qué significa darle permiso de firma a un agente de IA y qué es el "blast radius"?

Firmar una transacción en DeFi es una orden irrevocable: mueve fondos, autoriza a un smart contract a gastar tus tokens o cede control de una posición. Cuando quien firma es un humano, hay un ojo revisando la pantalla antes de pulsar. Cuando quien firma es un agente autónomo, ese ojo desaparece — y el agente puede encadenar cientos de firmas por segundo sin pedir permiso.

El concepto que ordena todo este debate viene de la ingeniería de seguridad: el blast radius (radio de daño) es cuánto puede destruir un componente comprometido antes de que alguien lo detenga. En software tradicional, ese radio está acotado por varias barreras: los permisos del sistema operativo, la posibilidad de deshacer una operación, la segmentación de red y un administrador que puede matar el proceso. On-chain, casi todas esas barreras desaparecen. Una firma no se deshace. No hay un botón de "revertir". Y si el agente tiene un allowance (autorización de gasto que concedes a un contrato para mover tus tokens) ilimitado, el radio de daño es el saldo entero del wallet.

Los vectores que convierten a un agente en peligro son tres, y ninguno requiere romper la criptografía. El primero es la prompt injection (inyección de instrucciones: texto malicioso escondido en los datos que el agente lee, que este ejecuta creyéndolo legítimo). El segundo es el tool call malicioso (una llamada a herramienta externa manipulada para que el agente firme algo que no debía). El tercero es un objetivo mal formulado: si le pides "maximiza mi rentabilidad" sin límites, un agente literal puede mover todo el colateral a un protocolo dudoso. En los tres casos, el problema no es que la IA sea "tonta": es que tiene demasiado permiso.

¿Cuáles son los cuatro patrones de permisos para agentes en DeFi?

No todos los agentes están expuestos igual. La diferencia está en cómo se les concede autoridad de firma. Existen cuatro patrones, ordenados de más peligroso a más contenido:

La mayoría de los agentes que operan hoy están entre el patrón naive y una llave de sesión mal configurada — que en la práctica es naive con un lazo. El intent (intención) es el salto conceptual importante: el agente deja de ser un firmante con poderes generales y pasa a ser un solicitante que propone operaciones concretas. El aislamiento total es el ideal de seguridad, pero sigue siendo el patrón menos maduro: cuanto más aíslas al agente, más lento y menos útil se vuelve, y ahí está la tensión de fondo de todo el diseño.

¿Qué resolvió EIP-7702 y qué sigue sin resolver?

EIP-7702 se activó en la actualización Pectra de Ethereum en mayo de 2025 y es la pieza técnica que hace viable el patrón de llave de sesión a nivel de cuenta. Antes, una EOA (cuenta externa: la wallet normal, controlada por una clave privada) solo podía hacer una cosa — firmar. EIP-7702 permite que esa misma EOA delegue su comportamiento a un smart contract; la delegación persiste hasta que el usuario firma una nueva autorización que la revoca — es el contrato delegado (o la wallet, con un patrón explícito) quien puede acotarla a una sesión, no un límite automático por transacción. Es una forma de abstracción de cuenta que habilita agrupar operaciones, pagar el gas por otro y, sobre todo, delegar permisos acotados a una sesión concreta.

Lo que resuelve: por fin se pueden conceder llaves de sesión nativas — "este agente puede gastar hasta 500 dólares en este protocolo durante las próximas dos horas, y luego el permiso muere". Eso reduce el radio de daño de forma estructural frente al patrón naive.

Lo que no resuelve: EIP-7702 es un mecanismo, no una política. No decide qué es un permiso razonable — eso lo decide el contrato al que delegas. Y ahí está el matiz incómodo: si delegas tu EOA a un contrato de delegación malicioso o con un bug, estás peor que antes, porque le has dado a ese código la capacidad de actuar como tu cuenta. La brecha de Bankr en mayo de 2026 es el ejemplo canónico: Bankr no ha publicado post-mortem oficial, pero las hipótesis de los expertos —compromiso de tokens de sesión o de aprobaciones con alcance sobre muchos usuarios en el custodio— apuntan todas al mismo sitio: no a la criptografía, sino a permisos que vivieron más de lo que debían. La herramienta estaba; la política, no.

¿Es x402 el patrón "intent-based" funcionando ya en producción?

Durante años, el patrón intent-based fue sobre todo teoría. En 2026 dejó de serlo, y el mejor ejemplo verificable es x402. El nombre viene de un código HTTP olvidado: el 402 Payment Required, un estado que la web reservó en los años noventa y casi nunca usó. x402 lo resucita para agentes: el agente pide un recurso, el servidor responde "402" con instrucciones de pago, el agente paga en stablecoin (casi siempre USDC) y reintenta. La clave de seguridad está en que el agente no tiene autoridad de firma general: firma un pago puntual contra una instrucción explícita del servidor. Eso es el patrón intent-based en estado puro.

En esa arquitectura aparece un actor nuevo, el facilitator (facilitador: el intermediario que verifica la solicitud y liquida el pago). El agente expresa la intención, el facilitador la ejecuta contra reglas. Nadie firma en abierto una autorización que un prompt malicioso pueda secuestrar para vaciar el wallet.

La pregunta natural es "¿quién controla ese estándar de permisos de pago?". La respuesta importa: en abril de 2026, Coinbase transfirió la custodia de x402 a la Linux Foundation, creando la x402 Foundation con más de 20 miembros fundadores, entre ellos Coinbase, Cloudflare y Stripe. Es un movimiento hacia estandarización neutral — el estándar sobre el que un agente decide cómo paga deja de pertenecer a una sola empresa.

Los datos de adopción, de un informe de Chainalysis de principios de junio de 2026, muestran por qué esto ya no es un experimento:

Ese giro del 49 % al 95 % en pagos por encima de 1 dólar es la parte relevante para nuestro tema: el sistema pasó de mover céntimos a mover dinero real. Y cuando el importe sube, el radio de daño de un fallo de permisos sube con él.

El mercado ya detectó que el estándar base no basta. El 20 de mayo de 2026, Fireblocks se unió a la x402 Foundation y lanzó su Agentic Payments Suite, aportando una capa de "integridad de solicitud y gobernanza de gasto" (request integrity y spend governance) por encima de x402. Esa extensión previene ataques de reenrutamiento tipo man-in-the-middle (un intermediario que desvía el pago a otro destino) que el estándar base no cubre, e incluye wallets para agentes con límites de gasto, listas de destinatarios permitidos, ventanas temporales y restricciones por activo. Traducido: incluso el patrón intent-based mejor diseñado necesita un cinturón de seguridad adicional de permisos. Nadie se fía del estándar por sí solo — y ese escepticismo es la lección, no una nota al pie.

¿Por qué el "mínimo privilegio" es más difícil on-chain que en software normal?

El principio de mínimo privilegio dice que cada componente debe tener solo los permisos que necesita para su tarea, ni uno más. Es un dogma de la seguridad informática desde hace décadas. On-chain, aplicarlo es mucho más difícil, y conviene entender por qué:

• No hay deshacer. En un sistema tradicional, un administrador revierte una transacción errónea. Una firma en blockchain es final. El error no se corrige: se paga.
• La componibilidad propaga el permiso. Un allowance concedido a un protocolo puede cascada a otros contratos que este llama. Autorizas a A, y A invoca a B y a C. El permiso viaja más lejos de lo que imaginabas.
• Los allowances persisten. Una autorización ilimitada firmada hace un año sigue viva hasta que la revocas manualmente. Miles de wallets cargan permisos zombis que olvidaron.
• No hay administrador central. No existe un departamento de IT que ponga en cuarentena a un agente rebelde. Herramientas como el Microsoft Agent Governance Toolkit (abril de 2026) o el trabajo del OWASP sobre riesgos de aplicaciones agénticas gobiernan agentes dentro de una empresa — pero DeFi es permissionless por diseño, sin directorio corporativo ni interruptor central.
• La llave es el poder. Poseer la clave equivale a la autoridad plena: una firma cruda no tiene segundo factor. No hay "confirma en el móvil" que frene a un agente comprometido.

Por eso la identidad de máquina y la trazabilidad on-chain se han vuelto un campo entero: sin un "quién es" y un "qué hizo" por cada agente, el mínimo privilegio queda en buena intención.

¿Qué incidentes reales muestran cada fallo de permisos?

La taxonomía se entiende mejor con víctimas concretas. Cada uno de estos casos verificables corresponde a un fallo distinto de la cadena de permisos:

El caso de los routers LLM maliciosos — documentado en abril de 2026 por investigadores de UC Santa Barbara, UC San Diego y Fuzzland — es el más instructivo, porque el ataque no toca la wallet ni el modelo directamente: envenena la capa intermedia que traduce la petición del agente en una acción. El agente "cree" que está ejecutando una operación legítima. Es el mismo patrón de inyección de prompts que ya ha drenado fondos a través de protocolos de conexión de herramientas: la vulnerabilidad no está en quién firma, sino en qué le dicen que firme.

Ninguno de estos incidentes fue un fallo de criptografía. Todos fueron fallos de arquitectura de permisos: un agente con más autoridad de la que necesitaba, ejecutando una instrucción que no debió aceptar.

¿Cómo conectar un agente de IA a tu wallet sin exponerlo todo?

Si vas a delegar operaciones DeFi a un agente — propio o de un servicio de agentes de trading —, este es el checklist de permisos, ordenado por impacto:

• Nunca entregues la clave privada ni un allowance ilimitado. Es el patrón naive, y su radio de daño es todo tu wallet. Usa una wallet separada solo para lo que el agente gestiona.
• Exige llaves de sesión con caducidad. Un permiso sin fecha de muerte es una puerta abierta indefinida — el fallo exacto de Bankr. Que expire en horas, no en meses.
• Pon límites de gasto por transacción, por protocolo y por día. Si el agente necesita mover más de tu tope, que requiera aprobación humana. El coste es fricción; el beneficio es contener el desastre.
• Prefiere el patrón intent-based cuando exista. Un agente que firma pagos puntuales contra instrucciones explícitas (el modelo de x402) tiene un radio de daño acotado a cada operación, no a tu saldo.
• Verifica la capa de intermediación. Si el agente se conecta a herramientas o facilitadores externos, comprueba quién los opera. Un router o un servidor malicioso puede inyectarle instrucciones — el vector de los routers LLM.
• Revoca permisos viejos periódicamente. Los allowances persisten. Revisa y retira los que ya no usas antes de conceder nuevos. Aquí ayuda saber leer los permisos de un protocolo antes de firmar.

Ninguno de estos pasos exige confiar menos en la IA. Exige darle menos poder del que tu instinto te empuja a concederle — que es, precisamente, la definición práctica del mínimo privilegio.

¿Qué queda claro sobre los permisos agénticos en DeFi?

La lección que atraviesa todo el marco es que el riesgo de un agente en DeFi casi nunca vive en el modelo de IA. Vive en la arquitectura de permisos que lo rodea. Bankr no cayó por una IA defectuosa, sino —según todas las hipótesis públicas— por permisos de sesión que sobrevivieron a su propósito; los routers maliciosos no rompieron el modelo, envenenaron lo que este leía. El mismo agente, con el patrón de permisos correcto, es una herramienta útil; con el patrón naive, es una bomba con temporizador.

La dirección del sector es clara y coherente: de la custodia total hacia el intent-based, y de ahí hacia capas de gobernanza de gasto que ni siquiera se fían del estándar intent-based por sí solo — como demuestra que Fireblocks construyera controles adicionales encima de x402. El "fully sandboxed" sigue siendo el horizonte aspiracional, más citado que desplegado, porque su seguridad se paga en autonomía. Elegir dónde te sitúas en ese espectro, para cada euro que un agente toca, es la decisión de seguridad que define la era agéntica de DeFi. Antes de conectar cualquier agente, conviene tener claro qué wallet usas y qué expone.

Fuentes y enlaces: Chainalysis — Inside x402: 100M Agentic Payments on Base · Fireblocks — Agentic Payments Suite · Coinbase — x402 Foundation (Linux Foundation) · Microsoft — Agent Governance Toolkit · CoinDesk — Routers LLM maliciosos