Por Canuto  

La Fundación Ethereum aseguró que los agentes de IA ya pueden descubrir vulnerabilidades reales en código crítico del protocolo, pero dejó una advertencia clave: el desafío no está en generar reportes, sino en separar hallazgos genuinos de una avalancha de falsos positivos que suenan convincentes.

***

  • La Fundación Ethereum dijo que sus agentes de IA detectaron fallas reales, incluyendo un pánico remoto en gossipsub de libp2p divulgado como CVE-2026-34219.
  • El equipo sostuvo que el verdadero cuello de botella ya no es encontrar bugs, sino hacer triaje, deduplicar reportes y validar pruebas reproducibles.
  • Ethereum insistió en que la IA debe tratarse como herramienta de búsqueda y no como autoridad, con decisión final reservada al juicio humano.

 

La Fundación Ethereum informó que su equipo de Seguridad de Protocolos ha estado ejecutando agentes de IA coordinados contra código real del protocolo y otros sistemas de alta criticidad. La conclusión principal no fue que estos agentes encuentren errores, sino que el trabajo decisivo empieza cuando toca demostrar cuáles de esos reportes son reales.

Según explicó la organización, los agentes sí detectaron vulnerabilidades auténticas en software de sistemas, código criptográfico y contratos que requieren altos estándares de seguridad. Entre los casos citados aparece un pánico activable de forma remota en el componente gossipsub de libp2p, una pieza central de la capa peer-to-peer usada por los clientes de consenso de Ethereum.

Ese problema ya fue corregido y divulgado como CVE-2026-34219, con crédito al equipo de la Fundación. Para Ethereum, el caso demuestra que la IA puede ser útil en investigación de seguridad, pero solo si se la usa como herramienta de búsqueda y no como una autoridad incuestionable.

La advertencia llega en un momento en que el uso de modelos avanzados para auditorías de software gana atención en toda la industria tecnológica. El punto de Ethereum es que el volumen de hipótesis y reportes puede crecer con rapidez, pero eso no equivale a un aumento automático en hallazgos confiables.

En otras palabras, el valor no está en cuántos candidatos produce un agente, sino en cuántos sobreviven al escrutinio técnico. Ese matiz importa especialmente en blockchain, donde una falsa sensación de seguridad o un reporte errado puede desviar tiempo, recursos y decisiones críticas.

Qué encontró Ethereum y por qué el triaje se volvió el trabajo central

El equipo explicó que los agentes son capaces de leer código, formular hipótesis, seguir rutas de llamadas y redactar artefactos de prueba de concepto. Sin embargo, también pueden producir informes muy convincentes basados en rutas de código inalcanzables, fallas que solo existen en compilaciones de depuración, duplicados o pruebas formales demasiado débiles.

La Fundación resumió su sorpresa con una frase clara: encontrar bugs no fue lo inesperado. Lo inesperado fue cuánto del esfuerzo terminó concentrándose en distinguir los errores reales de aquellos que solo parecían reales.

Ese cambio implica una reasignación del trabajo de seguridad. Antes, gran parte del tiempo humano se invertía en idear hipótesis y perseguirlas; ahora, una porción creciente se gasta en revisar, descartar, reproducir y clasificar lo que generan los agentes.

La publicación también sugiere que esta transición no elimina la necesidad de especialistas humanos. Más bien, desplaza el cuello de botella desde la generación de ideas hacia el juicio técnico, el manejo del triaje y la divulgación responsable.

En sistemas de los que depende Ethereum, ese desplazamiento no es menor. Una vulnerabilidad explotable por cualquier par de la red no tiene el mismo peso que un fallo que exige acceso especial, recursos poco realistas o una secuencia de eventos difícil de alcanzar.

Cómo se coordinan los agentes dentro del repositorio

La Fundación Ethereum detalló que ejecuta muchos agentes en paralelo contra un único objetivo. En vez de depender de un coordinador central, los agentes comparten estado a través del propio repositorio y del control de versiones.

Cada agente puede escribir una afirmación visible para los demás, trabajar sobre ella y comprometer sus resultados. El diseño busca reducir complejidad operativa y evitar que un gerente central se convierta en otro punto de falla dentro del proceso.

El flujo de trabajo se divide en cuatro funciones principales: reconocimiento, caza, llenado de vacíos y validación. El reconocimiento traduce superficies amplias de ataque en hipótesis concretas y comprobables.

La fase de caza toma una hipótesis, sigue el camino del código e intenta construir un reproducto funcional. El llenado de vacíos registra lo que ya fue aceptado o rechazado y genera nuevas hipótesis para mejorar cobertura y evitar trabajo repetido.

La validación reexamina de forma independiente cada candidato, elimina duplicados y decide si puede contarse como un hallazgo real. Este punto es esencial porque la mayoría de los reportes no terminan superando el filtro final.

La barra mínima para que un hallazgo cuente como real

Ethereum indicó que no basta con una intuición fuerte o con un informe bien redactado. Para contar como hallazgo, un candidato debe incluir un objetivo alcanzable, una invariante clara, un mecanismo de falla específico, una prueba observable, un reproducto autosuficiente y una clave de deduplicación.

La intención de ese esquema es forzar cada reporte a convertirse en una afirmación concreta y verificable. Un agente ya no puede refugiarse en formulaciones vagas como “esto parece riesgoso” si debe mostrar exactamente cómo se rompe una propiedad del sistema.

La regla dominante del proceso es todavía más estricta: reproducible o no sucedió. Un candidato no se considera válido hasta que exista un artefacto capaz de reproducir la falla contra código real y que pueda ser ejecutado por alguien distinto del agente que lo generó.

Ese requisito sirve como filtro contra una gran parte de los falsos positivos. También impide que una presentación persuasiva reemplace la evidencia empírica, algo especialmente importante cuando los modelos producen respuestas con alta confianza incluso al equivocarse.

La Fundación subrayó que el reproducto no “lee” el informe ni se deja impresionar por la narrativa del modelo. O funciona de forma consistente bajo condiciones reales, o el supuesto bug no alcanza la categoría de hallazgo confirmado.

Los falsos positivos más comunes y por qué suenan tan creíbles

El equipo describió varios errores recurrentes que aparecen una y otra vez en las auditorías basadas en agentes. Uno de los más comunes es un pánico que solo ocurre en una compilación de depuración, mientras que en la versión de producción el valor se ajusta y el bloqueo nunca ocurre.

Otro caso frecuente aparece cuando el reproducto construye manualmente un valor interno que ninguna entrada real podría generar. En ese escenario, la falla solo se observa al invocar una función de una manera que ningún atacante puede alcanzar desde el sistema real.

También hay problemas en trabajos de verificación formal. A veces una prueba se completa con éxito, pero la afirmación validada es trivialmente verdadera o más débil que la propiedad de seguridad que se pretendía demostrar.

Esto produce una ilusión de rigor difícil de detectar a simple vista. El verificador queda satisfecho, el informe parece sólido y aun así el comportamiento que realmente importaba nunca quedó restringido.

La Fundación sostuvo que nada de esto es conceptualmente nuevo, pero sí lo es el volumen. Un agente puede producir versiones inútiles y versiones acertadas con la misma rapidez y con el mismo tono de seguridad, lo que obliga a automatizar y disciplinar la verificación.

Qué hacen bien los agentes y dónde siguen engañando

Ethereum reconoció que los agentes tienen fortalezas claras. Pueden leer la especificación y el código al mismo tiempo, proponer invariantes válidas, redactar un reproducto a partir de una idea breve y sugerir una posible causa raíz en etapas tempranas.

Pero esas capacidades conviven con debilidades marcadas. Los modelos suelen equivocarse con cadenas de llamada que parecen alcanzables y no lo son, con criterios de éxito manipulados por la razón equivocada y con una gravedad inflada para hacer más dramático el reporte.

La Fundación también destacó su peor desempeño en errores que se desarrollan a lo largo de secuencias de pasos válidos. En ese tipo de vulnerabilidades, cada acción individual es legítima, pero el orden completo termina generando una falla costosa.

Para esos casos, los agentes funcionan mejor como guías que ayudan a decidir qué secuencias vale la pena pasar a un arnés de prueba con estado. Usarlos como reemplazo de ese arnés, sostuvo el equipo, puede dejar escapar algunos de los errores más graves.

El resultado es una frontera irregular en el rendimiento de la IA aplicada a seguridad. Un modelo puede reconstruir una cadena de explotación completa en una base de código y, aun así, fallar en seguimiento básico de flujo de datos en otra distinta.

Las prácticas que Ethereum considera indispensables

La publicación enfatiza que los hábitos que mantienen el proceso honesto no son especialmente glamorosos, pero sí decisivos. Uno de ellos es la procedencia completa de cada artefacto, incluyendo qué lo produjo, con qué contexto y contra qué revisión del código.

Otro principio es el determinismo donde importa. Debe existir un entorno y una forma de compilar y ejecutar que hagan que “reproduce” signifique exactamente lo mismo en máquinas distintas y también meses después.

La Fundación recomienda además trabajar con normas en vez de guiones rígidos. Es decir, decirle a los agentes qué invariantes importan y cuál es la barra de evidencia, en lugar de imponerles un procedimiento numerado que puede dejar de tener sentido a mitad del proceso.

El equipo advirtió que los agentes sobreespecificados fallan de forma parecida a las pruebas sobreespecificadas. Siguen pasos de memoria incluso cuando esos pasos ya no responden al problema real que tienen enfrente.

Por encima de todo, Ethereum insiste en que una persona debe tomar la decisión final. Los agentes pueden sugerir, pero no deberían decidir qué es real, qué es duplicado y qué debe divulgarse o cuándo hacerlo.

Un cambio de era para la seguridad, pero no un reemplazo del investigador

La principal conclusión del equipo es que la IA no reemplazó al investigador de seguridad. Lo que hizo fue mover el trabajo hacia la construcción de oráculos, la ejecución del triaje, el mantenimiento de listas de problemas conocidos y la gestión de la divulgación.

Ese movimiento puede ser positivo porque lleva el cuello de botella hacia un terreno donde el juicio humano agrega más valor. Aun así, sigue siendo un cuello de botella y no desaparece por el simple hecho de que la generación de hipótesis se haya acelerado.

La Fundación presentó este enfoque como una evolución comparable al camino que siguió el fuzzing durante los últimos quince años. Las herramientas cambian, pero los principios de confianza siguen siendo los mismos: fallas reproducibles, entornos deterministas, invariantes claras y revisión cuidadosa.

En ese sentido, la experiencia de Ethereum funciona también como advertencia frente al entusiasmo excesivo por la IA en ciberseguridad. Cobertura más amplia no sirve de mucho si la organización no puede verificar qué parte de esa cobertura corresponde a problemas reales.

Para los sistemas sobre los que opera Ethereum, esa diferencia es crítica. Los agentes permiten recorrer mucho más terreno del que sería posible manualmente, pero a cambio exigen una disciplina mayor para no ahogarse en afirmaciones plausibles que nunca llegan a convertirse en evidencia.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público

Este artículo fue escrito por un redactor de contenido de IA

 


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados