Cuando los agentes de IA obtienen ejecución en cadena: ¿quién verifica la información que ven y las órdenes que emiten?

Cada vez más agentes de IA están obteniendo capacidades de ejecución en cadena a través de cuentas inteligentes, billeteras de estrategia o servicios de firma restringida

I. Qué expuso el incidente de KelpDAO

El 18 de abril de 2026, el puente entre cadenas de rsETH de KelpDAO fue atacado y se liberaron de forma anómala 116.500 rsETH, valorados en ese momento en unos 292 millones de dólares. El informe del incidente de LayerZero mostró que el atacante obtuvo las claves de sesión del desarrollador mediante ingeniería social, contaminó el RPC interno del que dependía el DVN de LayerZero Labs y suprimió los RPC externos con un ataque de denegación de servicio, de modo que el servicio de firma emitió pruebas para mensajes falsificados basándose en datos erróneos. KelpDAO había cambiado en ese momento la ruta de verificación de 2-de-2 a 1-de-1 DVN. Una vez que el único DVN designado emitía una prueba errónea, el sistema ya no requería que un segundo DVN independiente verificara de forma cruzada el mismo mensaje. CrowdStrike y Mandiant atribuyeron el incidente con alta confianza a TraderTraitor (UNC4899), vinculado a Corea del Norte.

Este tipo de incidentes no es aislado. En muchos incidentes de seguridad importantes en cadena, el problema no suele estar en que se hayan roto los supuestos criptográficos en sí, sino en el control de claves, las fuentes de datos, la configuración de los validadores, la implementación del protocolo y los permisos operativos: el sistema no solo debe responder «si esta firma es válida», sino también «quién tiene derecho a firmar, en función de qué información firma y si el estado correspondiente a la firma ocurrió realmente».

Cada vez más agentes de IA están obteniendo capacidades de ejecución en cadena a través de cuentas inteligentes, billeteras de estrategia o servicios de firma restringida. Una firma válida solo puede demostrar que se invocó una determinada ruta de autorización; no puede demostrar que los datos en los que se basa el agente sean fiables, que la decisión se ajuste a la estrategia establecida o que la transacción debiera ocurrir en ese momento. El objeto de la verificación se está ampliando de «la autenticidad de la firma» a «si la entrada, la decisión y la ejecución son coherentes».

II. Qué resuelven las soluciones existentes y qué dejan pendiente

Las soluciones existentes resuelven cada una una parte del problema de confianza y, a su vez, depositan la confianza restante en actores diferentes:

Oráculos y resolución de disputas: los resultados del mercado de Polymarket son propuestos primero por los participantes y solo entran en la votación de los poseedores de tokens de UMA si son impugnados durante el período de desafío. El problema no es que «no haya revisión», sino si la revisión es fiable: cuando las reglas son ambiguas, los eventos reales admiten múltiples interpretaciones o el poder de voto se concentra en unas pocas direcciones, el sistema en realidad traslada la cuestión de «quién define los hechos» a otra estructura de gobernanza.

Multifirma de puentes entre cadenas y DVN: ambos difieren en su implementación, pero exigen que la aplicación configure explícitamente el conjunto de validadores y el umbral. Después de que KelpDAO configurara la ruta como 1-de-1 DVN, toda la ruta de verificación pasó a depender de un único servicio de verificación; y las fuentes de datos y los mecanismos de respuesta ante fallos de los que depende ese servicio pueden formar a su vez otro punto único en el siguiente nivel.

Custodia MPC: el atractivo de las firmas de umbral es que la clave no existe completa en un solo lugar, pero la fragmentación criptográfica no conlleva automáticamente una descentralización del poder a nivel organizativo. Según reveló en su momento el equipo de Multichain, después de que el fundador fuera detenido por la policía china, el equipo perdió de inmediato el acceso a los servidores de los nodos MPC correspondientes, que funcionaban bajo la cuenta personal en la nube del fundador. Si la cuenta en la nube, los permisos operativos y la respuesta de emergencia se concentran en una sola persona, el diseño de umbral de MPC puede seguir dejando un punto único a nivel organizativo.

TEE: los entornos de ejecución confiables pueden aislar el código y los datos sensibles, pero no eliminan la confianza, solo cambian dónde se deposita. La raíz de confianza del hardware y las actualizaciones de microcódigo suelen depender del fabricante del chip, mientras que el código del enclave, los permisos de actualización y las políticas de certificación pueden estar controlados por el proyecto o el operador. El TEE puede proteger el proceso de cómputo, pero no puede descentralizar automáticamente esos permisos de gobernanza.

Los modos de fallo de estas soluciones no son idénticos, pero apuntan al mismo tipo de problema: los umbrales y la descentralización escritos en los libros blancos solo constituyen una frontera de seguridad real si se materializan en las fuentes de datos, los permisos de las cuentas, las claves de actualización y los procesos de gobernanza.

III. CRVA: rediseñar la distribución del derecho de verificación

DeepSafe es el nuevo nombre de Bool Network desde 2025. CRVA continúa la línea técnica propuesta en 2022 por los investigadores relacionados con Bool Network. El artículo correspondiente se publicó en IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072) y proponía una plataforma de certificación entre cadenas basada en un «comité oculto en evolución» (evolving hidden committee).

El enfoque concreto es el siguiente: los nodos participan en un sorteo aleatorio mediante Ring-VRF; los seleccionados presentan una prueba y una clave pública temporal; los observadores externos pueden verificar su elegibilidad, pero difícilmente identificar su identidad a largo plazo. El comité temporal seleccionado firma entonces de forma conjunta mediante MPC de umbral, de modo que ningún nodo por sí solo puede generar el resultado. Los procesos críticos, como la gestión de claves, se ejecutan según el diseño del artículo en un TEE (por ejemplo, Intel SGX), con el objetivo de reducir la posibilidad de que el operador del host lea o manipule las porciones de clave. El comité también rota por épocas: la nueva generación obtiene nuevas porciones mediante una transferencia de claves verificable y las porciones antiguas quedan invalidadas; el período de rotación concreto lo determinan los parámetros reales de la red.

El proyecto también espera utilizar el TEE para ocultar el estado operativo del comité, de modo que a los operadores de nodos les resulte difícil saber si su nodo participó en una verificación determinada. Hasta qué punto puede lograrse este objetivo depende del código de la red actual, la certificación remota, los metadatos del host y la protección contra canales laterales; no es una conclusión que se derive automáticamente de «usar TEE».

Pero estos mecanismos resuelven «quién verifica y cómo emitir resultados de forma conjunta y segura», no definen automáticamente «qué resultado es el correcto». En el escenario de los agentes de IA, el comité sigue teniendo que llegar a conclusiones basándose en estrategias predefinidas, fuentes de datos y reglas de juicio ejecutables; si esas reglas son defectuosas, las fuentes de datos no son fiables o el objeto de la verificación no admite una respuesta objetivamente determinable, incluso un comité muy seguro puede confirmar conjuntamente una conclusión errónea.

CRVA intenta reducir los riesgos derivados de la exposición prolongada de verificadores fijos y de la concentración de permisos de firma, pero no puede eliminar por completo los puntos únicos a nivel de gobernanza e implementación. La admisión de nodos, las actualizaciones del protocolo, la atestación TEE y la seguridad del software siguen requiriendo auditorías continuas. Si las porciones antiguas se invalidan de forma fiable y el nuevo comité mantiene suficiente independencia, la rotación puede acortar la ventana de ataque contra un grupo de firmantes fijo, pero no puede cubrir riesgos sistémicos como la cadena de suministro de software o los permisos de actualización.

IV. Base técnica y avances en la implementación

La trayectoria técnica de CRVA se remonta al artículo de Bool Network publicado en el volumen 17 de IEEE TIFS (2022), con DOI 10.1109/TIFS.2022.3209546. El modelo de protocolo, las pruebas de seguridad y la evaluación del prototipo del artículo fueron sometidos a revisión por pares, lo que proporciona una base académica para diseños como el comité oculto dinámico, Ring-VRF, la gestión de claves de umbral y la protección TEE. Hay que distinguir que la revisión por pares se refiere al modelo y la implementación del artículo; cómo se corresponde el CRVA actualmente desplegado por DeepSafe con la solución del artículo debe juzgarse a la luz de las especificaciones técnicas vigentes, las auditorías de código y los parámetros de red.

Según el anuncio de DeepSafe de octubre de 2025, la red había procesado en ese momento casi 120 millones de verificaciones acumuladas y contaba con más de 2,65 millones de cuentas activas. El proyecto también afirmó que sus relaciones ecosistémicas superaban las 70, incluyendo compatibilidad de billeteras, integraciones técnicas, inversiones y colaboraciones de mercado, entre otros tipos.

En octubre de 2025, DeepSafe anunció la finalización de una ronda de financiación inicial de 3 millones de dólares, con inversores como Antalpha Global, ViaBTC Capital y Gate 1. Desde el punto de vista cronológico, esta ronda corresponde principalmente a la investigación y desarrollo técnico y a la expansión del ecosistema tras el cambio de marca.

V. De solución de verificación a infraestructura general

A medida que la infraestructura blockchain se vuelve gradualmente modular, el consenso, la ejecución, la disponibilidad de datos, la interoperabilidad y el sistema de cuentas empiezan a ser asumidos por componentes diferentes. La modularización no hace desaparecer el problema de la confianza, sino que hace más claras las fronteras de seguridad de cada capa: los desarrolladores no solo deben elegir qué tecnología usar, sino también juzgar quién proporciona la garantía de seguridad de esa capa y quién asume la responsabilidad cuando algo falla. Una vez que los agentes de IA obtienen capacidades de ejecución en cadena, surgen nuevas preguntas: ¿quién confirma que los datos que leen son fiables, que las decisiones no exceden su autorización y que la transacción final coincide con la autorización del usuario? Estas preguntas no se responden automáticamente con una firma válida.

DeepSafe aspira a convertir la capacidad de verificación de un módulo auxiliar interno de una aplicación individual en una infraestructura que puedan invocar diferentes protocolos y agentes de IA: «Proof, Not Promises», sustituir las promesas de la parte ejecutora por evidencia verificable. CRVA ya ha combinado el sorteo anónimo, la colaboración de umbral y el TEE en un enfoque técnico; si podrá cubrir además escenarios como oráculos, puentes entre cadenas y agentes de IA, y convertirse en una infraestructura de verificación general, dependerá del desarrollo continuo de las capacidades de la red actual, auditorías independientes e integraciones reales.