$25M robados mediante Inyección de Prompts en MCP: Cómo un Chatbot de IA rompió DeFi sin tocar la Blockchain

Descargo de responsabilidad Introducción 1. ¿Qué es Resolv y cómo funciona la acuñación de USR?

¿Qué es Resolv y cómo funciona la acuñación de USR?

Resolv es un protocolo destablecoinque utiliza una estrategia conocida comocobertura delta-neutralpara mantener el USR anclado a $1.00. En términos sencillos, el protocolo mantiene criptoactivos (ETH, BTC) mientras coloca simultáneamente apuestas opuestas en mercados de derivados, de modo que los movimientos de precio se cancelan entre sí: el valor en dólares permanece aproximadamente constante independientemente de si el cripto sube o baja. (Para una explicación más profunda sobre cómo las stablecoins sintéticas mantienen su paridad y los riesgos involucrados, consulta nuestra guía sobrestablecoinsy la sección sobre lacrisis de USDe de Ethenaen nuestro informe Real Yield). Este diseño pertenece a la misma familia que el USDe de Ethena, aunque con opciones de implementación distintas que resultarían críticas el 22 de marzo.

El proceso de acuñación (minting) de USR sigue un patrón de dos pasos común en protocolos que requieren autorización off-chain. Primero, un usuario llama arequestSwap(), depositando USDC en el contrato como colateral. Esto crea una solicitud de acuñación pendiente. Segundo, una dirección privilegiada —elSERVICE_ROLE— llama acompleteSwap()para autorizar la acuñación real de tokens USR. La idea es sencilla: el depósito proviene del usuario, pero el backend del protocolo verifica el monto del depósito, calcula la proporción correcta de USR a USDC y luego firma la transacción de acuñación con la clave del SERVICE_ROLE.

Aquí es donde la arquitectura se vuelve peligrosa. El SERVICE_ROLE era unacuenta de propiedad externa (EOA) única, no un multisig, ni un timelock, ni un contrato controlado por gobernanza. Una sola clave privada, almacenada en AWS Key Management Service (KMS), controlaba la capacidad de acuñar cualquier cantidad de USR. Comodocumentó Chainalysis en su post-mortem, "el contrato impone una salida mínima de USR, pero fundamentalmente, no hay un máximo".

Lee eso de nuevo. Elcontrato inteligentepermitiría al SERVICE_ROLE acuñar mil millones de USR contra un solo dólar de USDC, y el código se ejecutaría sin errores. No había verificación de proporción on-chain. No había límite máximo de acuñación. No había validación de oráculo. No había interruptor de seguridad (circuit breaker). El contrato confiaba implícitamente en el SERVICE_ROLE: cualquier cantidad que autorizara era acuñada, punto final.

El análisis de DeFiPrimelo expresó sin rodeos: "no había barandillas on-chain que impusieran esa proporción". Todo el modelo de seguridad dependía de la suposición de que la clave del SERVICE_ROLE solo sería utilizada por la infraestructura legítima del backend. Esa suposición estaba a punto de ser catastróficamente errónea.

Para entender por qué esto importa, considera la diferencia entre un protocolo donde la lógica de acuñación reside on-chain (verificada por código, inmutable, transparente) y uno donde reside off-chain (dependiente de una sola clave, almacenada en infraestructura de nube, controlada por software que puede ser comprometido). Resolv eligió lo segundo. Y el software que controlaba esa clave era un agente de IA.

2. El ataque de inyección de prompts

¿Cómo se comprometió el asistente de IA? El ataque de inyección de prompts

Aquí es donde el hackeo de Resolv se aparta de cualquier exploit previo en la historia de DeFi. No hubo errores de reentrada. No hubo manipulación de préstamos flash. No hubo front-running de oráculos. No hubo ataques de gobernanza. El atacante no tocó la blockchain en absoluto, hasta el final, cuando utilizó una clave de firma obtenida legítimamente para autorizar transacciones que el contrato inteligente ejecutó a la perfección.

El vector de ataque fue unasistente de IA—un modelo de lenguaje extenso (LLM) integrado en la infraestructura operativa de Resolv. Como muchos protocolos en 2025–2026 que adoptaron la IA para herramientas internas, Resolv había desplegado un asistente basado en LLM conectado a sus sistemas de backend mediante elModel Context Protocol (MCP).

¿Qué es el Model Context Protocol?

MCP es un estándar abiertolanzado por Anthropic en noviembre de 2024que permite a los modelos de IA descubrir e interactuar dinámicamente con herramientas externas durante el tiempo de ejecución. Piénsalo como un adaptador universal: en lugar de codificar rígidamente cada integración que una IA pueda necesitar, MCP proporciona una forma estandarizada para que un LLM se conecte a bases de datos, APIs, sistemas de archivos y servicios en la nube sobre la marcha. La IA puede consultar una base de datos Supabase, leer archivos de un bucket de almacenamiento, llamar a un endpoint de API o ejecutar una migración de base de datos, todo a través de llamadas de herramientas MCP.

El poder es obvio. El peligro es igualmente obvio, aunque mucho menos discutido. Una IA conectada por MCP opera con los permisos que el servidor MCP le otorgue. En el caso de Resolv, el asistente de IA estaba conectado a bases de datosSupabasey se ejecutaba con el rolservice_roleprivilegios.

En el modelo de seguridad de Supabase, laservice_roleclave omite todas las políticas de Seguridad a Nivel de Fila (RLS). Tiene acceso total de lectura y escritura a cada tabla, cada fila y cada columna. Está explícitamente documentada como una clave que nunca debe exponerse a clientes o entornos no confiables. Resolv otorgó este nivel de acceso a una IA que procesaba entradas externas.

Cómo funciona la inyección de prompts

La inyección de prompts es conceptualmente simple pero devastadoramente efectiva. Un LLM procesa texto: lee entradas y genera salidas. El problema fundamental es quelos LLM no pueden distinguir de manera confiable entre las instrucciones de su operador y las instrucciones integradas en los datos que procesan. Si un atacante logra introducir texto malicioso en cualquier entrada que la IA lea, esta puede interpretar dicho texto como un comando legítimo.

Unit 42 de Palo Alto Networkspublicó una extensa investigación sobre ataques de inyección de prompts indirectos observados en entornos reales. Sus hallazgos son aleccionadores: el 37,8% de los ataques utilizan texto plano visible (instrucciones escritas simplemente en un documento que la IA procesa), el 19,8% utiliza el ocultamiento de atributos HTML (escondiendo instrucciones en atributos HTML que los humanos no ven pero la IA lee), y el 16,9% utiliza la supresión de CSS (incrustando comandos en CSS que resultan invisibles para los espectadores humanos pero son analizados por el modelo). Los ataques no son teóricos. Están ocurriendo en sistemas de producción, contra organizaciones reales, ahora mismo.

El patrón de ataque MCP de Supabase ya había sido documentado antes del incidente de Resolv.La investigación de PVMLdescribió el escenario exacto: un ticket de soporte o una entrada de usuario que contiene instrucciones integradas es procesado por un asistente de IA con acceso service_role. La IA, incapaz de distinguir las instrucciones maliciosas de las legítimas, sigue los comandos integrados. En el caso documentado por PVML, esto llevó a la exfiltración de tokens de integración. Su conclusión fue inequívoca: “Los LLM no están diseñados para ser guardianes de seguridad”.

En el ataque a Resolv, el atacante diseñó una entrada que el asistente de IA interpretó como instrucciones legítimas. La carga útil exacta no ha sido revelada públicamente —el post-mortem de Resolv se refiere a ella solo como “una inyección de prompt elaborada”— pero el resultado es conocido: la IA filtró credenciales temporales de la nube, incluyendo tokens de acceso de AWS que proporcionaron un punto de apoyo en la infraestructura de Resolv.

Tabla: Anatomía de una inyección de prompt indirecta — las cuatro etapas que permitieron la filtración de credenciales de Resolv.

Practical DevSecOps identificó ocho categorías de vulnerabilidades críticasen servidores MCP: inyección de prompts, envenenamiento de herramientas, herramientas con exceso de permisos, el problema del adjunto confundido (confused deputy), contaminación entre herramientas, robo de tokens, suplantación de servidor y carga dinámica de herramientas no validada. El ataque a Resolv explotó al menos tres de estas: inyección de prompts (el punto de entrada), herramientas con exceso de permisos (acceso service_role) y lo que equivale a un problema de adjunto confundido (la IA actuó en nombre del atacante creyendo que seguía instrucciones legítimas).

La idea crítica es que esto no fue un fallo de la IA en un sentido abstracto. La IA hizo exactamente aquello para lo que fue diseñada: procesó una entrada y generó una salida. El fallo estuvo en la arquitectura que otorgó a una IA —un sistema que procesa entradas no confiables por definición— acceso a credenciales que, en última instancia, podían controlar un protocolo de más de 100 millones de dólares. Esto es lo queel CTO de Ledger, Charles Guillemet, llama la “trifecta letal”: entrada no confiable, capacidades de ejecución potentes y acceso a la red para la exfiltración. Cualquier sistema que combine las tres está, en palabras de Guillemet, “predestinado a fallar bajo presión”.

3. Movimiento lateral

De credenciales en la nube a AWS KMS: el movimiento lateral

Con las credenciales temporales de AWS en mano, el atacante pasó de la explotación de la IA a un patrón de ataque clásico a la infraestructura en la nube:movimiento lateral. Esta es una técnica familiar para cualquier equipo de seguridad en la nube, pero casi totalmente ausente en el manual de seguridad DeFi, que históricamente se ha centrado en auditorías de contratos inteligentes y monitoreo on-chain.

El atacante no fue directamente a la blockchain. No fue necesario. El objetivo era la clave de firma, y la clave de firma residía en la nube.

El primer paso fue enumerar el entorno de AWS utilizando las credenciales temporales filtradas por la IA. Las políticas de AWS Identity and Access Management (IAM) determinaban a qué podían acceder esas credenciales. En un entorno bien diseñado con IAM de mínimo privilegio, las credenciales temporales de un asistente de IA tendrían un alcance limitado; quizás acceso de solo lectura a tablas específicas de la base de datos y nada más. En el entorno de Resolv, las credenciales proporcionaron acceso suficiente para profundizar más.

El atacante navegó desde el punto de apoyo inicial en IAM haciaAWS Key Management Service (KMS), donde Resolv almacenaba la clave privada SERVICE_ROLE. KMS es el servicio gestionado de Amazon para almacenar y utilizar claves criptográficas; está diseñado para ser una bóveda segura para este tipo de material sensible. Pero la seguridad de KMS depende totalmente de las políticas de IAM que controlan quién puede acceder a las claves. Si un atacante tiene credenciales de AWS válidas con permisos suficientes, KMS le entregará la clave con la misma disposición que a la aplicación legítima.

Chainalysis confirmó la ruta: el atacante “accedió al entorno AWS Key Management Service de Resolv donde se almacenaba la clave de firma privilegiada del protocolo”. Una vez dentro de KMS, el atacante obtuvo la clave privada SERVICE_ROLE: el único secreto criptográfico que autorizaba todas las operaciones de acuñación de USR.

Toda la fase de movimiento lateral —desde las credenciales filtradas por la IA hasta el acceso a KMS— probablemente tomó minutos. Los ataques a la infraestructura en la nube avanzan rápido cuando el atacante posee credenciales válidas. No hay cadenas de exploits que desarrollar ni vulnerabilidades de día cero que descubrir. El atacante simplemente inicia sesión con las claves robadas y navega por el entorno como un administrador legítimo. Es por esto que el robo de credenciales es consistentemente la técnica de acceso inicial más común en las brechas de la nube, según todos los informes principales de inteligencia de amenazas de AWS, Google Cloud y Microsoft Azure.

Vale la pena detenerse a apreciar la ironía. Resolv almacenaba su secreto más crítico —la clave que controla cientos de millones de dólares en autoridad de acuñación— en AWS KMS, uno de los servicios de gestión de claves más seguros disponibles. La seguridad de KMS en sí nunca estuvo en duda. La vulnerabilidad estaba en la ruta hacia KMS: un agente de IA, ejecutándose con permisos excesivos, procesando entradas no confiables, conectado al mismo entorno de nube donde residía la clave de firma. La cadena era tan fuerte como su eslabón más débil, y el eslabón más débil era un LLM que no podía distinguir una instrucción legítima de una maliciosa.

Tabla: Cadena de ataque — Del Prompt a los $23M. Cinco pasos, menos de 30 minutos, cero exploits de contratos inteligentes.

4. Ejecución on-chain

La ejecución on-chain: 80 millones de tokens de la nada

Con la clave SERVICE_ROLE comprometida, el atacante finalmente tocó la blockchain —y elcontrato inteligentehizo exactamente aquello para lo que fue diseñado.

Transacción 1:El atacante depositó aproximadamente $100,000 en USDC en el contrato de acuñación a través derequestSwap(), luego llamó inmediatamente acompleteSwap()con la clave SERVICE_ROLE robada, autorizando la acuñación de50 millones de USR. Eso es una sobre-acuñación de 500x: cincuenta millones de dólares en stablecoins creados a partir de cien mil dólares de colateral. El contrato aceptó la transacción sin dudarlo. No hubo una verificación de ratio para rechazarla, ni un límite máximo para restringirla, ni un oráculo para verificar si el monto acuñado guardaba alguna relación con el depósito.

Transacción 2:Poco después, el atacante repitió el proceso, acuñando30 millones de USRadicionales. Mismo método, misma clave, misma ausencia de protecciones on-chain.

En total:80 millones de USRcreados contra aproximadamente $200,000 en depósitos reales de USDC. Una dilución de 400–500x del suministro de tokens. Los tokens de cada titular de USR existente pasaron a estar respaldados instantáneamente por una fracción de lo que valían minutos antes.

La estrategia de liquidación fue metódica. En lugar de lanzar 80M de USR directamente en un solo DEX —lo que habría activado interruptores de circuito inmediatos y un deslizamiento (slippage) máximo— el atacante primero convirtió una parte significativa de USR enwstUSR(wrapped staked USR). Este paso de envoltura sirvió a un propósito táctico: wstUSR era aceptado por pools de liquidez diferentes a los de USR puro, permitiendo al atacante acceder a múltiples lugares de liquidación simultáneamente y reducir el impacto en el precio en cualquier pool individual.

Luego, el atacante distribuyó las ventas a través de tres de los principales exchanges descentralizados:

• Curve Finance:El principal lugar de liquidación para pares de stablecoins. Los pools USR/USDC y USR/USDT absorbieron la presión de venta inicial antes de que la paridad colapsara.
• KyberSwap:Utilizado para conversiones adicionales de USDC/USDT.KyberSwap bloqueó las billeteras del explotador a las pocas horasdel ataque, pero para entonces el daño ya estaba hecho.
• Velodrome:Objetivo debido a su profunda liquidez en Optimism, proporcionando otra ruta de salida para los fondos robados.

El resultado fue rápido y devastador. En Curve,USR se desplomó de $1.00 a $0.025 en aproximadamente 17 minutos— un colapso del 97.5%.The Block informó queel atacante extrajo aproximadamente $25 millones, mientras queCoinDesk situó la cifra en aproximadamente $23 millones. La discrepancia refleja la dificultad de rastrear montos exactos a través de múltiples DEXs y cadenas en tiempo real.

La conversión final fue de stablecoins a ETH. El atacante consolidó las ganancias en aproximadamente11,400 ETH— con un valor de unos $24 millones al momento del exploit — y comenzó a mover fondos a través de direcciones intermediarias. La billetera principal del atacante,0x8ed8cf0c1c531c1b20848e78f1cb32fa5b99b81c, fuerápidamente marcada por firmas de seguridad y operadores de DEX.

Toda la fase on-chain — desde el primer minado hasta la consolidación final de ETH — tomómenos de 30 minutos. Para contextualizar, eso es más rápido de lo que la mayoría de los firmantes de un multisig pueden coordinar una respuesta de emergencia, más rápido de lo que la mayoría de los equipos de protocolo pueden confirmar que está ocurriendo un exploit, y más rápido de lo que cualquier mecanismo de pausa basado en gobernanza podría reaccionar. La ventaja de velocidad pertenecía enteramente al atacante.

La forense on-chain cuenta la historia de un contrato inteligente haciendo exactamente lo que le ordenó la clave autorizada. Cada transacción era válida. Cada firma era legítima. El contrato no tenía forma de saber — ni mecanismo para verificar — que la clave que firmaba estas transacciones había sido robada del entorno en la nube de un agente de IA comprometido. Desde la perspectiva de la blockchain, esto no fue un hackeo en absoluto. Fue una serie de operaciones perfectamente autorizadas.

5. Hallazgos de las firmas de seguridad

Hallazgos de las firmas de seguridad

El hackeo de Resolv desencadenó una respuesta inmediata del ecosistema de seguridad blockchain. En pocas horas, varias firmas publicaron sus evaluaciones iniciales. Lo que surgió no fue solo el post-mortem de un único exploit, sino el reconocimiento de que todo el modelo de amenazas para los protocolosDeFise había expandido.

Cyvers: primera detección

Cyvers, una plataforma de monitoreo de seguridad Web3 en tiempo real, fue de las primeras en detectar la actividad anómala. Sus sistemas marcaron la creación de 80M de tokens USR como una anomalía crítica; el volumen de emisión era órdenes de magnitud superior a cualquier ejecución previa de completeSwap(). La alerta de Cyvers activó la investigación de la comunidad de seguridad y ayudó a que los exchanges y DEXs comenzaran a bloquear las direcciones del explotador.

PeckShield: cuantificando el daño

PeckShield, una de las firmas de seguridad blockchain más consolidadas, estimó el total de USR generado artificialmente en un valor nominal de $80 millones. Su análisis on-chain confirmó el patrón de emisión en dos transacciones y rastreó los flujos de fondos a través de Curve, KyberSwap y Velodrome. El seguimiento en tiempo real de PeckShield fue fundamental para ayudar a los exchanges a congelar los activos restantes del explotador antes de que pudieran ser lavados por completo.

Chainalysis: el post-mortem definitivo

Chainalysis publicó el análisis más exhaustivobajo el título “Cómo una clave comprometida imprimió $23 millones”. Su investigación confirmó el vector de AWS KMS y proporcionó la descripción más clara de la cadena de ataque: inyección de prompts → robo de credenciales → movimiento lateral hacia KMS → compromiso de SERVICE_ROLE → emisión no autorizada.

Las recomendaciones clave de Chainalysis incluyeron:

• Monitorear anomalías en el ratio de completeSwap():Cualquier emisión donde la salida de USR exceda la entrada de USDC por más de una pequeña tolerancia (contabilizando el posicionamiento delta-neutral) debería activar una alerta inmediata.
• Pausa automatizada ante eventos de Mint sospechosos:Si el volumen de emisión en una sola transacción o ventana de tiempo corta excede las normas históricas por 10 veces o más, el contrato debería pausarse automáticamente y requerir la intervención de un multisig para reanudarse.
• Monitoreo de infraestructura en la nube:Los registros de acceso de KMS deben monitorearse en tiempo real. Cualquier acceso desde una IP, rol o sesión no reconocida debería activar una rotación inmediata de claves.
• Aislamiento de agentes de IA:Los agentes de IA nunca deben compartir credenciales de nube con sistemas que controlan claves de firma. El entorno de la IA y el entorno de gestión de claves deben ser cuentas de AWS completamente separadas sin acceso cruzado entre cuentas.

Charles Guillemet (Ledger): la advertencia estructural

Quizás la respuesta más significativa no provino de una firma de seguridad blockchain, sino deCharles Guillemet, CTO de Ledger, quien publicó “La IA Agéntica está suelta. Tu modelo de seguridad no está listo”. El análisis de Guillemet fue más allá de los detalles del hackeo de Resolv para describir un problema sistémico sobre cómo se están desplegando los agentes de IA en la infraestructura cripto.

Guillemet describió la “trifecta letal” que hace que los agentes de IA sean inherentemente peligrosos en entornos de alto valor:

1. Entrada no confiable:Los agentes de IA procesan datos de fuentes externas —usuarios, sitios web, bases de datos, APIs— cualquiera de las cuales puede contener cargas útiles de inyección de prompts.
2. Potentes capacidades de ejecución:El MCP y protocolos similares de uso de herramientas otorgan a los agentes de IA la capacidad de ejecutar acciones reales: consultas a bases de datos, llamadas a APIs, operaciones de archivos y, potencialmente, firma de transacciones.
3. Acceso a la red para exfiltración:Los agentes de IA pueden comunicarse hacia el exterior —a través de su canal de respuesta, llamadas a herramientas o registros— lo que significa que cualquier información filtrada puede llegar al atacante.

La solución propuesta por Guillemet es arquitectónicamente radical:“Los agentes proponen, los humanos firman”.En este modelo, un agente de IA puede analizar datos, sugerir transacciones y preparar operaciones, pero la autorización final debe provenir de un humano, verificada mediante separación reforzada por hardware (como una billetera de hardware Ledger). La IA nunca puede ejecutar de forma autónoma una acción de alto valor. Solo puede recomendar.

Su conclusión tiene un peso especial dada la posición de Ledger como fabricante líder de billeteras de hardware:“Si tu arquitectura no puede separar claramente lo que un agente sugiere de lo que un humano autoriza, entonces está condenada a fallar bajo presión”.

El mensaje colectivo de la comunidad de seguridad fue claro: el hackeo de Resolv no fue un incidente aislado sino un presagio. Cualquier protocolo que utilice agentes de IA con privilegios elevados —particularmente aquellos con acceso a claves de firma, credenciales de nube o acceso a bases de datos mediante service_role— debe implementar de inmediato defensas contra inyección de prompts, saneamiento de entradas y el principio de mínimo privilegio para todos los sistemas conectados a la IA.

6. La blockchain nunca fue el eslabón débil

La blockchain nunca fue el eslabón débil

Esta es la parte que debería inquietar a todo desarrollador, inversor e investigador de seguridad de DeFi. El código delcontrato inteligentefuncionóperfectamente. Hizo exactamente aquello para lo que fue diseñado: cuando la clave SERVICE_ROLE firmó una transacción completeSwap(), el contrato emitió la cantidad especificada de USR. El código no tenía errores. No era vulnerable a reentrada. No tenía llamadas externas sin verificar. Sin colisión de almacenamiento. Sin desbordamiento de enteros. Según cualquier medida estándar de seguridad de contratos inteligentes, el contrato de emisión de Resolv era técnicamente sólido.

La vulnerabilidad existía enteramente en lapila de infraestructura centralizada: Agente de IA → MCP → Supabase → AWS IAM → AWS KMS. Cada componente en esta cadena es off-chain. Cada componente es centralizado. Cada componente es exactamente el tipo de intermediario de confianza que la tecnología blockchain fue inventada para eliminar.

Esto invierte por completo elmodelo de seguridad DeFitradicional. Durante los últimos seis años, la gran mayoría de los exploits de DeFi han tenido como objetivo la capa blockchain: ataques de reentrada (The DAO, 2016), manipulación de oráculos mediante préstamos flash (bZx, 2020; Cream Finance, 2021), ataques de gobernanza (Beanstalk, 2022), vulnerabilidades en puentes (Ronin, Wormhole, Nomad, 2022) yexploits de aprobación de tokens. La respuesta estándar a estos ataques ha sido mejores auditorías, verificación formal, recompensas por errores (bug bounties) y monitoreo on-chain.

Ninguna de esas defensas habría evitado el hackeo de Resolv. Se podría haber auditado el contrato de emisión cien veces con las mejores firmas del mundo y no se habría encontrado nada, porque no había nada que encontrar. El contrato era seguro. El agente de IA que lo controlaba no lo era.

Andrew Whong, cofundador de Herd, resumió el fallo arquitectónico: “El contrato de emisión no tenía oráculo ni verificaciones de emisión máxima”. Pero incluso eso subestima el problema. Las verificaciones de oráculo y los límites de emisión habrían ayudado —habrían limitado el radio de impacto— pero el problema fundamental es que una sola clave controlada por un agente de IA comprometible tenía autoridad de emisión ilimitada. La solución no es solo añadir verificaciones on-chain. Es replantear toda la relación entre la infraestructura de IA y las operaciones on-chain.

DeFiPrime lo llamó“un caso de exceso de confianza en la infraestructura off-chain”, una frase que podría servir como epitafio para toda una generación de protocolos DeFi que acoplaron agentes de IA a sus operaciones sin considerar las implicaciones de seguridad.

La paradoja es dolorosa. La promesa central de DeFi es una finanza descentralizada, sin permisos y sin necesidad de confianza. Sin puntos únicos de falla. Sin intermediarios de confianza. El código es la ley. Y sin embargo, aquí estaba Resolv —un protocolo que gestiona cientos de millones de dólares— donde la función de emisión estaba controlada por una sola clave centralizada, gestionada por un agente de IA, almacenada en la infraestructura de un proveedor de nube, accesible a través de una cadena de credenciales que podían filtrarse engañando a un chatbot. La blockchain era el componente más seguro de toda la pila. Fue la infraestructura off-chain —la IA, la nube, la gestión de claves— la que falló.

Tabla: Hackeo DeFi Tradicional vs. Hackeo de Infraestructura de IA — el exploit de Resolv representa un cambio de paradigma en la ubicación de las vulnerabilidades de DeFi.

Para los usuarios que intentan evaluar su propia exposición a estos riesgos, herramientas comoCleanSkypueden ayudar a monitorearlas aprobaciones de tokensy las posiciones en diversos protocolos; pero la lección de fondo es que el monitoreo on-chain por sí solo ya no es suficiente. La superficie de ataque ahora se extiende a la infraestructura en la nube, los agentes de IA y los sistemas de gestión de claves que los protocolos utilizan entre bastidores. Comprender elriesgoen DeFi ahora significa entender todo el stack tecnológico, no solo los contratos inteligentes.

7. Por qué este no será el último

Por qué este probablemente no será el último ataque a la infraestructura de IA

Si el hackeo de Resolv fuera un incidente aislado —un fallo puntual de un solo protocolo que tomó decisiones arquitectónicas excepcionalmente malas— sería preocupante pero controlable. El problema es que cada tendencia en la industria apunta hacia más agentes de IA, más conexiones MCP, más operaciones automatizadas y más protocolos cometiendo exactamente los mismos errores que cometió Resolv.

Los agentes de IA ya son atacantes capaces

La propia investigación de Anthropic, publicada en diciembre de 2025, mostró que los agentes de IA ya podían explotar más del 50% de los contratos inteligentes vulnerables del mundo real en el benchmark SCONE-bench, un conjunto de datos de 405 contratos que representan $550 millones en valor simulado. Esta investigación trataba sobre la IA atacando contratos inteligentes, pero las mismas capacidades se aplican a la inversa: los agentes de IA son lo suficientemente sofisticados como para ser herramientas valiosas tanto para defensores como para atacantes.

Por separado, los investigadores demostraron que los modelos de frontera, incluidos GPT-5 y Sonnet 4.5, encontraron dos fallos de día cero en 2,849 contratos de BNB Chain con un coste de computación de solo $3,476. La economía del descubrimiento de vulnerabilidades impulsado por IA se ha inclinado decisivamente a favor de los atacantes: el coste de encontrar errores explotables es ahora trivial en comparación con el beneficio potencial.

Las cifras se están acelerando

El informe anual de 2025 de Hacken documentó unaumento del 1,025% en exploits relacionados con la IAen comparación con 2024. No es una errata: un aumento de diez veces en un solo año. La categoría incluye phishing impulsado por IA, descubrimiento de vulnerabilidades asistido por IA, ingeniería social mejorada con deepfakes y ahora ataques de inyección de prompts en la infraestructura de protocolos. La investigación de Cecuro descubrió que los agentes de IA de frontera pueden ejecutar exploits de extremo a extremo en el 72% de los contratos vulnerables conocidos, frente al 20% aproximadamente a principios de 2024.

Elpanorama de la seguridad cripto en 2025ya era desalentador antes de Resolv: $4,650 millones en pérdidas totales, el compromiso del multisig de Bybit, una ola de fallos en el control de acceso. El hackeo de Resolv añade una nueva categoría a una superficie de amenazas que ya estaba en expansión.

La adopción de MCP se acelera sin paridad en seguridad

La adopción del Model Context Protocol (MCP) explotó a lo largo de 2025 y hasta 2026. Existen miles de servidores MCP para bases de datos (Supabase, PostgreSQL, MongoDB), proveedores de nube (AWS, GCP, Azure), herramientas de desarrollo (GitHub, GitLab, Jira), plataformas de comunicación (Slack, Discord, correo electrónico) y servicios financieros (APIs bancarias, procesadores de pagos, nodos de blockchain). Cada servidor MCP es un objetivo potencial de inyección de prompts.

Elincidente de Supabase MCP documentado por PVMLfue el disparo de advertencia.La propia Supabase publicó "Defensa en profundidad para MCP"en respuesta, recomendando que los servidores MCP nunca utilicen claves service_role y, en su lugar, utilicen autenticación con permisos limitados por usuario. Pero la adopción de estas recomendaciones ha sido, en el mejor de los casos, desigual. Muchos equipos de protocolos desplegaron integraciones MCP durante la ola de hype de la IA de 2024-2025 sin implementar controles de seguridad básicos.

El hackeo de Resolv fue la primera víctima con dinero real. No será la última. La combinación del despliegue expansivo de agentes de IA, la creciente adopción de MCP y los enormes incentivos financieros para los atacantes crea un panorama de amenazas que crece más rápido de lo que se despliegan las defensas. Cada protocolo que utilice agentes de IA para tareas operativas —gestión de riesgos, trading, atención al cliente, monitoreo, participación en la gobernanza— debería considerar el ataque a Resolv como una advertencia directa.

El problema estructural

El problema de fondo no es ninguna vulnerabilidad individual, sino un desajuste estructural entre las capacidades de la IA y la seguridad de la IA. Los LLM son herramientas extremadamente potentes para procesar información, generar resultados e interactuar con sistemas externos. También son fundamentalmente incapaces de distinguir de forma fiable las instrucciones de confianza de las entradas no fiables. Esto no es un error que se parcheará en la próxima versión del modelo: es una propiedad inherente a cómo los modelos de lenguaje basados en transformadores procesan el texto.

Cada conexión MCP a un agente de IA crea una nueva superficie de ataque. Cada dato que procesa la IA es un vector potencial de inyección de prompts. Cada herramienta que la IA puede llamar es una capacidad que el atacante hereda. Y cada credencial a la que la IA puede acceder es una credencial que el atacante puede robar. Cuanto más potentes y conectados se vuelven los agentes de IA, más valiosos resultan como objetivos de ataque. Esta es la paradoja de seguridad de la IA agéntica: las funciones que hacen que los agentes sean útiles son las mismas que los hacen peligrosos.

8. Qué deben hacer los protocolos ahora

Qué deben hacer los protocolos ahora

El hackeo de Resolv proporciona un esquema claro de las medidas defensivas que todo protocolo DeFi que utilice agentes de IA debe implementar. Estas no son mejores prácticas opcionales: son requisitos mínimos para cualquier protocolo que no quiera ser el próximo titular de una pérdida de $23 millones.

1. Separar la firma de la IA — permanentemente

Esta es la conclusión más importante de todas.Los agentes de IA nunca deben poseer, acceder o estar en la misma ruta de credenciales que las claves de firma.La arquitectura "Los agentes proponen, los humanos firman"defendida por Guillemetdebería ser el estándar para cada protocolo. Una IA puede analizar una solicitud de swap pendiente y recomendar una cantidad de emisión (minting). Puede preparar los parámetros de la transacción. Incluso puede enviar la transacción a una cola. Pero la firma real —la autorización criptográfica que hace que la transacción sea ejecutable— debe requerir la aprobación humana a través de un límite reforzado por hardware.

En la práctica, esto significa: la cuenta de AWS donde se ejecutan los agentes de IA debe tener cero acceso a la cuenta de AWS (o HSM, o multisig) donde residen las claves de firma. Sin roles IAM, sin confianza entre cuentas, sin credenciales compartidas. Separación arquitectónica completa.

2. Blindar cada conexión MCP

Cada servidor MCP que se conecte a un agente de IA debe implementar:

• Saneamiento de entradas:Eliminar o escapar patrones potenciales de inyección de prompts de todos los datos antes de que lleguen a la IA.
• Filtrado de salidas:Monitorear las salidas de la IA en busca de patrones de credenciales (claves API, tokens, cadenas de conexión) y bloquearlos antes de que salgan del sistema.
• Acceso basado en roles:Utilizar el nivel mínimo de privilegio requerido. Nunca conectar una IA a una base de datos con acceso service_role. Utilizar tokens de solo lectura y con permisos limitados siempre que sea posible.
• Lista de permitidos de herramientas:Definir explícitamente qué herramientas MCP puede llamar la IA. Bloquear todas las herramientas que no estén en la lista. Evitar que la IA descubra o invoque nuevas herramientas en tiempo de ejecución.
• Limitación de tasa (Rate limiting):Limitar la frecuencia y el volumen de las llamadas a herramientas que una IA puede realizar en un intervalo de tiempo para evitar la exfiltración rápida.

3. Implementar salvaguardas on-chain

Incluso si la infraestructura off-chain se ve comprometida, los mecanismos de seguridad on-chain pueden limitar el daño. El contrato de Resolv no tenía ninguno. Cada contrato de emisión o de operación de alto valor debería incluir:

• Límites máximos de emisión (mint caps):Un tope por transacción y por hora sobre la cantidad que se puede emitir. Si Resolv hubiera limitado la emisión a, por ejemplo, el doble del valor del depósito, el atacante podría haber robado $400,000 en lugar de $23 millones.
• Verificaciones de precio por oráculo:Antes de emitir, verificar la relación depósito-emisión contra un oráculo externo. Si la relación se desvía más allá de un umbral, revertir la transacción.
• Bloqueos temporales (Time-locks):Las operaciones de emisión de gran volumen deben requerir un retraso obligatorio (por ejemplo, de 15 minutos a 24 horas) durante el cual la emisión pendiente pueda ser revisada y cancelada.
• Pausas activadas por anomalías:Si el volumen de emisión excede las normas históricas por un factor amplio (10x, 50x), el contrato debería pausarse automáticamente y requerir la intervención de un multisig para reanudarse.

4. Multisig para todas las operaciones críticas

El SERVICE_ROLE nunca debería haber sido una sola EOA. Las operaciones críticas del protocolo —emisión, quema, cambios de parámetros, actualizaciones, pausas de emergencia— deberían requerir múltiples firmantes independientes. Un multisig 3-de-5 o 4-de-7 utilizando firmantes distribuidos geográficamente con carteras de hardware habría hecho que el ataque a Resolv fuera virtualmente imposible, incluso con la clave SERVICE_ROLE comprometida, porque el atacante habría necesitado comprometer a múltiples firmantes independientes simultáneamente.

5. Fundamentos de seguridad en la nube

El ataque a Resolv explotó fallos básicos de seguridad en la nube que habrían sido detectados por una revisión estándar de seguridad cloud:

• IAM de mínimo privilegio:Las credenciales temporales emitidas a los agentes de IA deben estar limitadas a los permisos mínimos absolutos requeridos. Un asistente de IA que consulta tablas de bases de datos no necesita acceso a KMS.
• Sin credenciales de larga duración:Los agentes de IA deben utilizar credenciales de corta duración que roten automáticamente. Si las credenciales de la IA de Resolv hubieran expirado en minutos en lugar de permanecer válidas el tiempo suficiente para el movimiento lateral, el ataque habría sido significativamente más difícil.
• Registro y alertas de acceso a KMS:Cada acceso a una clave KMS debe generar una alerta. Los patrones de acceso inusuales (nueva IP, nuevo rol, nueva hora del día) deben activar una investigación inmediata.
• Segmentación de red:El entorno del agente de IA y el entorno de gestión de claves deben estar en VPC (Nubes Privadas Virtuales) separadas sin ruta de red entre ellas.

6. Desplegar defensas contra inyección de prompts

Aunque ninguna defensa es 100% efectiva contra la inyección de prompts (sigue siendo un problema de investigación abierto), varias técnicas elevan significativamente la barrera para los atacantes:

• Spotlighting:Una técnica que marca el límite entre las instrucciones de confianza y los datos no fiables utilizando delimitadores especiales que la IA está entrenada para respetar. El prompt del sistema instruye explícitamente a la IA para que trate el contenido dentro de los delimitadores no fiables solo como datos, nunca como instrucciones.
• Jerarquía de instrucciones:Configurar la IA para que las instrucciones a nivel de sistema siempre prevalezcan sobre cualquier instrucción encontrada en las entradas del usuario o datos externos. Esto es imperfecto pero aumenta la dificultad de una inyección exitosa.
• Pruebas adversarias:Realizar regularmente red-teaming en sus integraciones de IA con intentos de inyección de prompts. Si su equipo de seguridad no puede extraer credenciales mediante inyección de prompts, eso no significa que un atacante no pueda, pero es un mínimo necesario.
• Clasificadores de salida:Utilizar un modelo de IA independiente y más sencillo para escanear las salidas del agente principal en busca de posibles fugas de credenciales, llamadas a herramientas anómalas o signos de seguimiento de instrucciones provenientes de entradas no fiables.

7. Monitorear todo el stack

El monitoreo on-chain es necesario pero ya no es suficiente. Los protocolos ahora deben monitorear:

• Registros de auditoría en la nube:AWS CloudTrail, GCP Cloud Audit, Azure Activity Logs: cada llamada a la API en el entorno de la nube debe registrarse y analizarse.
• Comportamiento del agente de IA:Registrar cada llamada a herramientas, cada entrada y cada salida. Establecer líneas base para el comportamiento normal y alertar sobre desviaciones.
• Invocaciones de herramientas MCP:Rastrear qué herramientas MCP se están llamando, con qué frecuencia y con qué parámetros. Un aumento repentino en las llamadas a herramientas relacionadas con credenciales debería activar una investigación inmediata.
• Anomalías on-chain:Continuar monitoreando emisiones inusuales, grandes transferencias y desviaciones de precios, pero reconocer que para cuando estas aparecen on-chain, el compromiso off-chain puede estar ya completo.

9. El panorama general

El panorama general: cuando la máquina es la vulnerabilidad

El hackeo de Resolv USR no es solo una historia sobre un protocolo que tomó malas decisiones arquitectónicas. Es un anticipo de una nueva categoría de riesgo con la que toda la industria cripto debe lidiar a medida que se acelera la integración de la IA.

Durante la última década, la narrativa de la seguridad cripto ha estado dominada por errores en los contratos inteligentes. El hackeo de The DAO en 2016 nos enseñó sobre la reentrada. El bloqueo de la cartera Parity nos enseñó sobre los contratos de biblioteca. El hackeo del puente Wormhole nos enseñó sobre la verificación cross-chain. Cada exploit hizo avanzar la comprensión de la industria sobre la seguridad on-chain, lo que llevó a mejores herramientas de auditoría, verificación formal y recompensas por errores (bug bounties). La industria de la seguridad de contratos inteligentes es ahora madura, está bien financiada y es genuinamente eficaz para encontrar vulnerabilidades a nivel de código.

Pero el hackeo de Resolv eludió todo eso. El atacante no necesitó encontrar un error en el código porque el código era irrelevante. El atacante necesitaba encontrar una forma de obtener una clave de firma, y el camino pasó por un chatbot de IA, una base de datos en la nube y un servicio de gestión de claves; todo fuera de la cadena (off-chain), todo centralizado y todo invisible para los sistemas de monitoreo on-chain en los que la industria ha invertido miles de millones.

Este no es un problema que mejores auditorías de contratos inteligentes puedan resolver. No es un problema que la verificación formal pueda abordar. Requiere una disciplina de seguridad completamente nueva que combine la seguridad en la nube, la seguridad de la IA, la defensa contra inyecciones de prompts, las mejores prácticas de gestión de claves y el monitoreo tradicional de DeFi en un marco unificado. No existe tal marco hoy en día de forma estandarizada y ampliamente adoptada. El hackeo de Resolv es la llamada de alerta.

La industria se enfrenta ahora a una elección. Puede tratar el hackeo de Resolv como una anomalía —un error de un solo equipo, poco probable que se repita— y seguir desplegando agentes de IA con privilegios elevados y controles de seguridad mínimos. O puede reconocer que la combinación de IA agéntica, acceso a herramientas MCP y operaciones on-chain de alto valor crea una superficie de amenaza fundamentalmente nueva que exige defensas fundamentalmente nuevas.

El dinero inteligente apuesta por la segunda opción. Pero la historia sugiere que muchos protocolos elegirán la primera, y estaremos escribiendo sobre el próximo exploit al estilo Resolv antes de que termine el año.

Mantenerse seguro en el mundo criptosiempre ha requerido entender dónde residen realmente los riesgos. Después del 22 de marzo de 2026, esos riesgos incluyen a los agentes de IA en los que los protocolos confían para ejecutar su infraestructura.

CTA Independencia editorial Lecturas Relacionadas

Lectura relacionada