$25M Robados vía Inyección de Prompts MCP: Cómo un Chatbot de IA Rompió DeFi Sin Tocar la Blockchain

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

Resolv es un protocolo de stablecoins que utiliza una estrategia conocida como cobertura delta-neutral para mantener el USR fijado a $1,00. En términos simples, el protocolo mantiene criptoactivos (ETH, BTC) mientras simultáneamente coloca apuestas opuestas en mercados de derivados, de modo que los movimientos de precio se cancelan mutuamente — el valor en dólares permanece aproximadamente constante independientemente de si las criptomonedas suben o bajan. (Para una explicación más profunda de cómo las stablecoins sintéticas mantienen su paridad y los riesgos involucrados, consulta nuestra guía sobre stablecoins y la sección sobre la crisis de Ethena USDe en nuestro informe de Real Yield.) Este diseño pertenece a la misma familia que USDe de Ethena, aunque con decisiones de implementación distintas que resultarían críticas el 22 de marzo.

El proceso de acuñación de USR sigue un patrón de dos pasos común en protocolos que requieren autorización fuera de la cadena. Primero, un usuario llama a requestSwap(), depositando USDC en el contrato como colateral. Esto crea una solicitud de acuñación pendiente. Segundo, una dirección privilegiada — el SERVICE_ROLE — llama a completeSwap() 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 SERVICE_ROLE.

Aquí es donde la arquitectura se vuelve peligrosa. El SERVICE_ROLE era una única Cuenta de Propiedad Externa (EOA) — no un multisig, no un timelock, no 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. Como documentó Chainalysis en su análisis post-mortem, “el contrato impone un mínimo de salida de USR — pero críticamente, ningún máximo.”

Lee eso de nuevo. El contrato inteligente permití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 error. No había verificación de proporción en la cadena. Ningún tope máximo de acuñación. Ninguna validación por oráculo. Ningún circuit breaker. El contrato confiaba implícitamente en el SERVICE_ROLE — cualquier cantidad que autorizara se acuñaba, punto final.

El análisis de DeFiPrime lo expresó sin rodeos: no había “barreras de protección en la cadena que impusieran esa proporción.” Todo el modelo de seguridad dependía de la suposición de que la clave SERVICE_ROLE solo sería utilizada por infraestructura backend legítima. 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 vive en la cadena (verificada por código, inmutable, transparente) y uno donde vive fuera de la cadena (dependiente de una sola clave, almacenada en infraestructura en la nube, controlada por software que puede ser comprometido). Resolv eligió lo segundo. Y el software que controlaba esa clave era un agente de IA.

¿Cómo fue comprometido el asistente de IA? El ataque de inyección de prompts

Aquí es donde el hackeo de Resolv se aparta de todo exploit DeFi anterior en la historia. No hubo un bug de reentrancia. Ni manipulación de préstamos flash. Ni front-running de oráculos. Ni ataque de gobernanza. El atacante no tocó la blockchain en absoluto — no hasta el final, cuando usó una clave de firma legítimamente obtenida para autorizar transacciones que el contrato inteligente ejecutó impecablemente.

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

¿Qué es Model Context Protocol?

MCP es un estándar abierto lanzado por Anthropic en noviembre de 2024 que permite a los modelos de IA descubrir e interactuar dinámicamente con herramientas externas durante la ejecución. Piensa en él como un adaptador universal: en lugar de codificar rígidamente cada integración que una IA podría 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 de Supabase, leer archivos de un bucket de almacenamiento, llamar a un endpoint de API o ejecutar una migración de base de datos — todo mediante 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 datos de Supabase — y se ejecutaba con privilegios de service_role.

En el modelo de seguridad de Supabase, la clave service_role elude todas las políticas de Seguridad a Nivel de Fila (Row Level Security). Tiene acceso completo de lectura y escritura a cada tabla, cada fila, 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 que los LLM no pueden distinguir de forma fiable entre instrucciones de su operador e instrucciones incrustadas en los datos que procesan. Si un atacante puede introducir texto malicioso en cualquier entrada que la IA lea, la IA puede interpretar ese texto como un comando legítimo.

Unit 42 de Palo Alto Networks publicó una investigación extensa sobre ataques de inyección indirecta de prompts observados en producción. Sus hallazgos son alarmantes: el 37,8% de los ataques usan texto plano visible (instrucciones simplemente escritas en un documento que la IA procesa), el 19,8% usan ocultación en atributos HTML (escondiendo instrucciones en atributos HTML que los humanos no ven pero la IA lee), y el 16,9% usan supresión CSS (incrustando comandos en CSS que se renderiza invisible para los lectores humanos pero es analizado 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 al MCP de Supabase ya había sido documentado antes del incidente de Resolv. La investigación de PVML describió el escenario exacto: un ticket de soporte o entrada de usuario que contiene instrucciones incrustadas es procesada por un asistente de IA con acceso service_role. La IA, incapaz de distinguir las instrucciones maliciosas de las legítimas, sigue los comandos incrustados. En el caso documentado por PVML, esto condujo 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 creó una entrada que el asistente de IA interpretó como instrucciones legítimas. La carga útil exacta no ha sido revelada públicamente — el análisis post-mortem de Resolv se refiere a ella solo como “una inyección de prompts elaborada” — pero el resultado es conocido: la IA filtró credenciales temporales de la nube, incluyendo tokens de acceso AWS que proporcionaron un punto de apoyo en la infraestructura de Resolv.

Tabla: Anatomía de una Inyección Indirecta de Prompts — las cuatro etapas que permitieron la filtración de credenciales de Resolv.

Practical DevSecOps identificó ocho categorías críticas de vulnerabilidad en servidores MCP: inyección de prompts, envenenamiento de herramientas, herramientas con permisos excesivos, el problema del delegado confundido, contaminación cruzada de herramientas, robo de tokens, suplantación de servidor y carga dinámica de herramientas sin validar. El ataque a Resolv explotó al menos tres de estas: inyección de prompts (el punto de entrada), herramientas con permisos excesivos (acceso service_role), y lo que equivale a un problema de delegado confundido (la IA actuó en nombre del atacante mientras creía que seguía instrucciones legítimas).

La conclusión crítica es que esto no fue un fallo de la IA en algún sentido abstracto. La IA hizo exactamente lo que fue diseñada para hacer: 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 $100M. Esto es lo que Charles Guillemet, CTO de Ledger, llama la “tríada letal”: entrada no confiable, capacidades de ejecución poderosas y acceso a la red para exfiltración. Cualquier sistema que combine las tres está, en palabras de Guillemet, “preparado para fallar bajo presión.”

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

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

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

El primer paso fue enumerar el entorno AWS usando 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 estarían estrictamente acotadas — 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 proporcionaban acceso suficiente para penetrar más profundamente.

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

Chainalysis confirmó la ruta: el atacante “accedió al entorno de AWS Key Management Service de Resolv donde se almacenaba la clave de firma privilegiada del protocolo.” Una vez dentro de KMS, el atacante tenía 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 infraestructura en la nube avanzan rápido cuando el atacante tiene credenciales válidas. No hay cadenas de exploits que desarrollar, ni zero-days que descubrir. El atacante simplemente inicia sesión con las claves robadas y navega el entorno como un administrador legítimo. Por eso el robo de credenciales es consistentemente la técnica de acceso inicial más común en brechas de la nube, según todos los principales informes de seguridad en la nube de los equipos de inteligencia de amenazas de AWS, Google Cloud y Microsoft Azure.

Vale la pena hacer una pausa para apreciar la ironía. Resolv almacenó 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 cuestión. La vulnerabilidad estaba en el camino hacia KMS: un agente de IA, ejecutándose con permisos excesivos, procesando entradas no confiables, conectado al mismo entorno en la 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 $23M. Cinco pasos, menos de 30 minutos, cero exploits de contratos inteligentes.

La ejecución en la cadena: 80 millones de tokens de la nada

Con la clave SERVICE_ROLE comprometida, el atacante finalmente tocó la blockchain — y el contrato inteligente hizo exactamente lo que fue diseñado para hacer.

Transacción 1: El atacante depositó aproximadamente $100.000 en USDC en el contrato de acuñación vía requestSwap(), luego inmediatamente llamó a completeSwap() con la clave SERVICE_ROLE robada, autorizando la acuñación de 50 millones de USR. Eso es una sobreacunación de 500x — cincuenta millones de dólares en stablecoin creados a partir de cien mil dólares de colateral. El contrato aceptó la transacción sin dudar. No había verificación de proporción para rechazarla, ni tope máximo para limitarla, ni oráculo para verificar si el monto de acuñación guardaba alguna relación con el depósito.

Transacción 2: Poco después, el atacante repitió el proceso, acuñando 30 millones adicionales de USR. Mismo método, misma clave, misma ausencia de barreras de protección en la cadena.

En total: 80 millones de USR creados 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 existente de USR quedaron instantáneamente respaldados por una fracción de lo que habían valido minutos antes.

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

El atacante luego distribuyó las ventas a través de tres exchanges descentralizados principales:

• Curve Finance: El lugar de liquidación principal para pares de stablecoins. Los pools USR/USDC y USR/USDT absorbieron la presión vendedora inicial antes de que colapsara la paridad.
• KyberSwap: Usado para conversión adicional de USDC/USDT. KyberSwap bloqueó las wallets del explotador en cuestión de horas tras el ataque, pero para entonces el daño ya estaba hecho.
• Velodrome: Apuntado por 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 reportó que el atacante extrajo aproximadamente $25 millones, mientras que CoinDesk situó la cifra en aproximadamente $23 millones. La discrepancia refleja la dificultad de rastrear cantidades exactas a través de múltiples DEXs y cadenas en tiempo real.

La conversión final fue de stablecoins a ETH. El atacante consolidó los ingresos en aproximadamente 11.400 ETH — con un valor de aproximadamente $24 millones en el momento del exploit — y comenzó a mover fondos a través de direcciones intermediarias. La wallet principal del atacante, 0x8ed8cf0c1c531c1b20848e78f1cb32fa5b99b81c, fue rápidamente marcada por firmas de seguridad y operadores de DEX.

Toda la fase en la cadena — desde la primera acuñación hasta la consolidación final en ETH — tomó menos de 30 minutos. Para contexto, eso es más rápido de lo que la mayoría de firmantes de multisig pueden coordinar una respuesta de emergencia, más rápido de lo que la mayoría de equipos de protocolos pueden siquiera 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 completamente al atacante.

La forensia en la cadena cuenta la historia de un contrato inteligente haciendo exactamente lo que la clave autorizada le indicó. Cada transacción era válida. Cada firma era legítima. El contrato no tenía forma de saber — y ningún 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.

Lo que encontraron las firmas de seguridad

El hackeo de Resolv desencadenó una respuesta inmediata del ecosistema de seguridad blockchain. En cuestión de horas, múltiples firmas habían publicado sus evaluaciones iniciales. Lo que surgió no fue solo un análisis post-mortem de un único exploit sino un reconocimiento de que todo el modelo de amenazas para protocolos DeFi acababa de expandirse.

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 acuñación era órdenes de magnitud superior a cualquier ejecución previa de completeSwap(). La alerta de Cyvers desencadenó la investigación de la comunidad de seguridad más amplia y ayudó a los exchanges y DEXs a comenzar a bloquear las direcciones del explotador.

PeckShield: cuantificando el daño

PeckShield, una de las firmas de seguridad blockchain más establecidas, estimó el total de USR generado artificialmente en $80 millones de valor nominal. Su análisis en la cadena confirmó el patrón de acuñación en dos transacciones y rastreaó 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 completamente lavados.

Chainalysis: el análisis post-mortem definitivo

Chainalysis publicó el análisis más exhaustivo bajo 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 del SERVICE_ROLE → acuñación no autorizada.

Las recomendaciones clave de Chainalysis incluyeron:

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

Charles Guillemet (Ledger): la advertencia estructural

Quizás la respuesta más significativa no vino de una firma de seguridad blockchain sino de Charles Guillemet, CTO de Ledger, quien publicó “La IA Agéntica Anda Suelta. Tu Modelo de Seguridad No Está Listo.” El análisis de Guillemet fue más allá de los detalles específicos del hackeo de Resolv para describir un problema sistémico con cómo los agentes de IA están siendo desplegados en la infraestructura cripto.

Guillemet describió la “tríada letal” que hace a los agentes de IA 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 de inyección de prompts.
2. Capacidades de ejecución poderosas: 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 API, operaciones con archivos, y potencialmente firma de transacciones.
3. Acceso a la red para exfiltración: Los agentes de IA pueden comunicarse hacia afuera — a través de su canal de respuesta, llamadas de herramientas, logging — 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 forzada por hardware (como una wallet hardware de Ledger). La IA nunca puede ejecutar autónomamente una acción de alto valor. Solo puede recomendar.

Su conclusión tiene un peso particular dada la posición de Ledger como el principal fabricante de wallets hardware: “Si tu arquitectura no puede separar claramente lo que un agente sugiere de lo que un humano autoriza, entonces está preparada para 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 use agentes de IA con privilegios elevados — particularmente aquellos con acceso a claves de firma, credenciales de la nube o acceso service_role a bases de datos — debe implementar inmediatamente defensas contra inyección de prompts, sanitización de entradas y el principio de mínimo privilegio para todos los sistemas conectados a IA.

La blockchain nunca fue el eslabón débil

Esta es la parte que debería inquietar a cada constructor, inversor e investigador de seguridad en DeFi. El código del contrato inteligente funcionó perfectamente. Hizo exactamente lo que fue diseñado para hacer: cuando la clave SERVICE_ROLE firmó una transacción completeSwap(), el contrato acuñó la cantidad especificada de USR. El código no tenía bugs. No era vulnerable a reentrancia. No tenía llamadas externas sin verificar. Sin colisión de almacenamiento. Sin desbordamiento de enteros. Por toda medida estándar de seguridad de contratos inteligentes, el contrato de acuñación de Resolv era técnicamente sólido.

La vulnerabilidad existía enteramente en el stack de infraestructura centralizada: agente de IA → MCP → Supabase → AWS IAM → AWS KMS. Cada componente en esta cadena está fuera de la cadena. Cada componente está centralizado. Cada componente es exactamente el tipo de intermediario de confianza que la tecnología blockchain fue inventada para eliminar.

Esto invierte completamente el modelo de seguridad DeFi tradicional. Durante los últimos seis años, la abrumadora mayoría de exploits DeFi han apuntado a la capa blockchain: ataques de reentrancia (The DAO, 2016), manipulación de oráculos por préstamos flash (bZx, 2020; Cream Finance, 2021), ataques de gobernanza (Beanstalk, 2022), vulnerabilidades de bridges (Ronin, Wormhole, Nomad, 2022) y exploits de aprobaciones de tokens. La respuesta estándar a estos ataques ha sido mejores auditorías, verificación formal, bug bounties y monitoreo en la cadena.

Ninguna de esas defensas habría prevenido el hackeo de Resolv. Podrías haber auditado el contrato de acuñación cien veces con las mejores firmas del mundo y no haber 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 acuñación no tenía verificaciones de oráculo ni de acuñación máxima.” Pero incluso eso subestima el problema. Las verificaciones de oráculos y los topes máximos de acuñación habrían ayudado — habrían limitado el radio de explosión — pero el problema fundamental es que una sola clave controlada por un agente de IA comprometible tenía autoridad ilimitada de acuñación. La solución no es solo agregar verificaciones en la cadena. Es repensar toda la relación entre la infraestructura de IA y las operaciones en la cadena.

DeFiPrime lo llamó “un caso de confianza excesiva en la infraestructura fuera de la cadena” — una frase que podría servir como epitafio para toda una generación de protocolos DeFi que añadieron agentes de IA a sus operaciones sin considerar las implicaciones de seguridad.

La paradoja es dolorosa. La promesa central de DeFi es finanzas sin confianza, sin permisos, descentralizadas. Sin punto único de fallo. Sin intermediario de confianza. El código es ley. Y sin embargo aquí estaba Resolv — un protocolo que gestionaba cientos de millones de dólares — donde la función de acuñació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 ser filtradas engañando a un chatbot. La blockchain era el componente más seguro de todo el stack. Fue la infraestructura fuera de la cadena — la IA, la nube, la gestión de claves — la que falló.

Tabla: Hackeo DeFi Tradicional vs Hackeo de Infraestructura IA — el exploit de Resolv representa un cambio de paradigma en dónde residen las vulnerabilidades DeFi.

Para los usuarios que intentan evaluar su propia exposición a estos riesgos, herramientas como CleanSky pueden ayudar a monitorear aprobaciones de tokens y posiciones a través de protocolos — pero la lección más profunda es que el monitoreo en la cadena 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 usan tras bastidores. Entender el riesgo en DeFi ahora significa entender todo el stack, no solo los contratos inteligentes.

Por qué esto probablemente no será el último ataque de infraestructura IA

Si el hackeo de Resolv fuera un incidente aislado — un fallo puntual de un solo protocolo que tomó decisiones arquitectónicas únicamente malas — sería preocupante pero contenible. 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 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 dataset de 405 contratos que representan $550M en valor simulado. Esta investigación trataba sobre IA atacando contratos inteligentes, pero las mismas capacidades 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, investigadores demostraron que modelos de frontera incluyendo GPT-5 y Sonnet 4.5 encontraron dos fallos zero-day en 2.849 contratos de BNB Chain a un coste computacional 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 bugs explotables es ahora trivial comparado con el pago potencial.

Los números se están acelerando

El informe anual 2025 de Hacken documentó un aumento del 1.025% en exploits relacionados con IA comparado con 2024. No es un error tipográfico — un aumento de diez veces en un solo año. La categoría incluye phishing potenciado por IA, descubrimiento de vulnerabilidades asistido por IA, ingeniería social mejorada con deepfakes, y ahora ataques de inyección de prompts contra infraestructura de protocolos. La investigación de Cecuro encontró que los agentes de IA de frontera pueden ejecutar exploits de extremo a extremo en el 72% de los contratos vulnerables conocidos, frente a aproximadamente el 20% a principios de 2024.

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

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

La adopción de Model Context Protocol explotó a lo largo de 2025 y en 2026. Miles de servidores MCP existen ahora 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, email), y servicios financieros (APIs bancarias, procesadores de pago, nodos blockchain). Cada servidor MCP es un potencial objetivo de inyección de prompts.

El incidente del MCP de Supabase documentado por PVML fue el tiro de advertencia. El propio Supabase publicó “Defensa en Profundidad para MCP” en respuesta, recomendando que los servidores MCP nunca usen claves service_role y en su lugar utilicen autenticación con alcance limitado por usuario. Pero la adopción de estas recomendaciones ha sido desigual en el mejor de los casos. Muchos equipos de protocolos desplegaron integraciones MCP durante la ola de hype de 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 de expansión del despliegue de agentes de IA, 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 las defensas están siendo desplegadas. Cada protocolo que use agentes de IA para tareas operativas — gestión de riesgos, trading, soporte al cliente, monitoreo, participación en gobernanza — debería considerar el ataque a Resolv como una advertencia directa.

El problema estructural

El problema más profundo 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 poderosas para procesar información, generar salidas e interactuar con sistemas externos. También son fundamentalmente incapaces de distinguir de forma fiable entre instrucciones confiables y entradas no confiables. Esto no es un bug que se parcheará en la próxima versión del modelo — es una propiedad inherente de cómo los modelos de lenguaje basados en transformers procesan texto.

Cada conexión MCP a un agente de IA crea una nueva superficie de ataque. Cada pieza de datos que la IA procesa es un potencial vector 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 poderosos y conectados se vuelven los agentes de IA, más valiosos se vuelven como objetivos de ataque. Esta es la paradoja de seguridad de la IA agéntica: las características que hacen útiles a los agentes son las mismas que los hacen peligrosos.

Qué deben hacer los protocolos ahora

El hackeo de Resolv proporciona un plan claro de las medidas defensivas que todo protocolo DeFi que use 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 $23M.

1. Separar la firma de la IA — permanentemente

Esta es la conclusión más importante. Los agentes de IA nunca deben poseer, acceder ni estar en la misma ruta de credenciales que las claves de firma. La arquitectura “Los Agentes Proponen, los Humanos Firman” defendida por Guillemet debería ser el estándar para todo protocolo. Una IA puede analizar una solicitud de swap pendiente y recomendar un monto de acuñación. 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 la transacción ejecutable — debe requerir aprobación humana a través de una barrera impuesta por hardware.

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

2. Endurecer cada conexión MCP

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

• Sanitización 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: Usar el nivel de privilegio mínimo requerido. Nunca conectar una IA a una base de datos con acceso service_role. Usar tokens con alcance limitado y de solo lectura siempre que sea posible.
• Lista blanca 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: Limitar la frecuencia y volumen de llamadas de herramientas que una IA puede hacer dentro de una ventana de tiempo para prevenir la exfiltración rápida.

3. Implementar barreras de protección en la cadena

Incluso si la infraestructura fuera de la cadena está comprometida, los mecanismos de seguridad en la cadena pueden limitar el daño. El contrato de Resolv no tenía ninguno. Cada contrato de acuñación u operación de alto valor debería incluir:

• Topes máximos de acuñación: Un límite por transacción y por hora en la cantidad que se puede acuñar. Si Resolv hubiera limitado la acuñación a, digamos, 2x el valor del depósito, el atacante podría haber robado $400K en lugar de $23M.
• Verificaciones de precio por oráculo: Antes de acuñar, verificar la proporción depósito-acuñación contra un oráculo externo. Si la proporción se desvía más allá de un umbral, revertir la transacción.
• Bloqueos temporales: Las operaciones de acuñación grandes deberían requerir un retraso obligatorio (ej. 15 minutos a 24 horas) durante el cual la acuñación pendiente pueda ser revisada y cancelada.
• Pausas activadas por anomalías: Si el volumen de acuñación excede las normas históricas por un factor grande (10x, 50x), el contrato debería pausarse automáticamente y requerir intervención multisig para reanudar.

4. Multisig para todas las operaciones críticas

El SERVICE_ROLE nunca debería haber sido un único EOA. Las operaciones críticas del protocolo — acuñació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 usando firmantes geográficamente distribuidos con wallets hardware habría hecho el ataque a Resolv virtualmente imposible, incluso con la clave SERVICE_ROLE comprometida, porque el atacante habría necesitado comprometer 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 agentes de IA deberían estar acotadas a los permisos mínimos absolutos requeridos. Un asistente de IA que consulta tablas de base de datos no necesita acceso a KMS.
• Sin credenciales de larga duración: Los agentes de IA deberían usar credenciales de corta duración con rotación automática. 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 de acceso y alertas de KMS: Cada acceso a una clave KMS debería generar una alerta. Patrones de acceso inusuales (nueva IP, nuevo rol, nueva hora del día) deberían activar una investigación inmediata.
• Segmentación de red: El entorno del agente de IA y el entorno de gestión de claves deberían estar en VPCs (Virtual Private Clouds) 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 instrucciones confiables y datos no confiables usando delimitadores especiales que la IA está entrenada para respetar. El prompt del sistema instruye explícitamente a la IA a tratar el contenido dentro de los delimitadores no confiables solo como datos, nunca como instrucciones.
• Jerarquía de instrucciones: Configurar la IA para que las instrucciones a nivel de sistema siempre anulen cualquier instrucción encontrada en entradas de usuario o datos externos. Esto es imperfecto pero aumenta la dificultad de una inyección exitosa.
• Pruebas adversarias: Realizar regularmente pruebas de penetración (red team) en tus integraciones de IA con intentos de inyección de prompts. Si tu 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: Usar un modelo de IA separado y más simple para escanear las salidas del agente principal en busca de potenciales filtraciones de credenciales, llamadas de herramientas anómalas o señales de seguimiento de instrucciones de entradas no confiables.

7. Monitorear el stack completo

El monitoreo en la cadena es necesario pero ya no es suficiente. Los protocolos ahora deben monitorear:

• Logs de auditoría en la nube: AWS CloudTrail, GCP Cloud Audit, Azure Activity Logs — cada llamada API en el entorno en la nube debería ser registrada y analizada.
• Comportamiento del agente de IA: Registrar cada llamada de herramienta, cada entrada, cada salida. Establecer líneas base de comportamiento normal y alertar sobre desviaciones.
• Invocaciones de herramientas MCP: Rastrear qué herramientas MCP están siendo llamadas, con qué frecuencia y con qué parámetros. Un pico repentino en llamadas de herramientas relacionadas con credenciales debería activar una investigación inmediata.
• Anomalías en la cadena: Continuar monitoreando acuñaciones inusuales, transferencias grandes y desviaciones de precio — pero reconocer que cuando estas aparecen en la cadena, el compromiso fuera de la cadena puede ya estar completo.

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

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

Durante la última década, la narrativa de seguridad cripto ha estado dominada por bugs en contratos inteligentes. El hackeo de The DAO en 2016 nos enseñó sobre reentrancia. El congelamiento de la wallet de Parity nos enseñó sobre contratos de biblioteca. El hackeo del bridge de Wormhole nos enseñó sobre verificación cross-chain. Cada exploit hizo avanzar la comprensión de la industria sobre seguridad en la cadena, llevando a mejores herramientas de auditoría, verificación formal y bug bounties. La industria de seguridad de contratos inteligentes ahora es madura, bien financiada y genuinamente efectiva para encontrar vulnerabilidades a nivel de código.

Pero el hackeo de Resolv evitó todo eso. El atacante no necesitó encontrar un bug 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 pasaba 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, todo centralizado, todo invisible para los sistemas de monitoreo en la cadena en los que la industria ha gastado miles de millones construyendo.

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 seguridad en la nube, seguridad de IA, defensa contra inyección de prompts, mejores prácticas de gestión de claves y monitoreo DeFi tradicional en un marco unificado. Ningún marco de este tipo existe hoy en una forma estandarizada y ampliamente adoptada. El hackeo de Resolv es la llamada de atención.

La industria ahora enfrenta una elección. Puede tratar el hackeo de Resolv como una anomalía — un error de un solo equipo, improbable de repetirse — y continuar 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 de alto valor en la cadena crea una superficie de amenazas fundamentalmente nueva que demanda 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 tipo Resolv antes de que termine el año.

Mantenerse seguro en cripto siempre ha requerido entender dónde viven realmente los riesgos. Después del 22 de marzo de 2026, esos riesgos incluyen los agentes de IA en los que los protocolos confían para gestionar su infraestructura.

Lectura relacionada