Notas del equipo de Seguridad del Protocolo de la Fundación Ethereum sobre la ejecución de agentes de IA coordinados contra código de protocolo real, incluyendo cómo organizamos el trabajo, qué resiste el escrutinio y qué pueden aprender de ello los equipos de clientes y los investigadores de seguridad. Esta publicación es independiente; publicaciones posteriores profundizarán en clientes individuales.
Qué hemos estado ejecutando y qué nos sorprendió
En el equipo de Seguridad del Protocolo de la Fundación Ethereum, hemos estado ejecutando agentes de IA coordinados contra los tipos de sistemas de los que depende la red, como software de sistemas, código criptográfico y contratos que tienen que ser correctos. Los agentes encontraron errores reales. Uno ahora es público: un pánico activable de forma remota en el gossipsub de libp2p, una parte central de la capa entre pares (peer-to-peer) en la que se ejecutan los clientes de consenso de Ethereum, solucionado y divulgado como CVE-2026-34219 con crédito al equipo.
Que los agentes encontraran errores no fue la sorpresa. La sorpresa fue la poca cantidad de trabajo que se destinó a encontrarlos y la gran cantidad que se destinó a distinguir los errores reales de los que solo parecían reales.
Esta publicación es para equipos de clientes e investigadores de seguridad que quieran hacer lo mismo. Cubre cómo organizamos a los agentes, el estándar que debe superar un candidato antes de que cuente como un hallazgo y los hábitos que mantienen la confiabilidad de los resultados.
Otros equipos están convergiendo en la misma receta. El Frontier Red Team de Anthropic construyó un agente que escribe pruebas basadas en propiedades y encontró errores reales en todo el ecosistema de Python. Cloudflare ejecutó un modelo de frontera a través de un entorno de investigación de seguridad contra sus propios sistemas. Todos llegan al mismo ciclo: apuntar un modelo capaz a una base de código, dejar que busque y hacer un triaje de lo que devuelve. Así que la verdadera pregunta es cómo hacer esto sin ahogarse en ruido que suena convincente.
Una advertencia de antemano: las herramientas para auditorías impulsadas por agentes avanzan rápido, y cualquier configuración específica queda obsoleta en unas pocas semanas. Por lo tanto, esta publicación trata deliberadamente sobre los métodos, que son persistentes, en lugar de las herramientas. La divulgación es un tema en sí mismo y probablemente tendrá su propia publicación.
Un agente es una herramienta de búsqueda, no un oráculo
Un agente apuntado a una base de código es una herramienta de búsqueda, muy parecida a un fuzzer. La diferencia es lo que devuelve. Un fuzzer te entrega un fallo y un seguimiento de pila (stack trace). Un agente te entrega mucho más, incluyendo un informe (cadena de llamadas, reclamo de impacto, gravedad sugerida) y los artefactos para respaldarlo, como una prueba de concepto que puedes ejecutar contra el código real.
Todo eso hace que el resultado sea fácil de leer y de confiar, sobre todo la prueba de concepto en ejecución. Así que no cuentes cuántos candidatos produce un agente. Cuenta cuántos resultan ser reales.
Cómo se organiza el trabajo
Ejecutamos muchos agentes en paralelo contra un objetivo. Se coordinan a través del propio repositorio, con un estado compartido en el control de versiones y sin un proceso central que reparta el trabajo. Un agente anota un reclamo donde los demás pueden verlo, hace el trabajo y realiza un commit.
Obtuvimos este enfoque del artículo de Anthropic sobre la construcción de un compilador de C con una flota de agentes, que se coordina de la misma manera. No hay un coordinador central que construir o mantener, y hay menos cosas que puedan salir mal.
Los roles se generan por el trabajo que se descubre:
- El reconocimiento (Recon) convierte una superficie de ataque en hipótesis concretas y comprobables. No es "auditar el decodificador", sino "se confía en este campo más allá de este punto; aquí está la propiedad que debería mantener, la forma en que podría romperse y la prueba que lo resolvería".
- La caza (Hunting) toma una hipótesis, rastrea la ruta del código e intenta construir un reproductor.
- El llenado de vacíos (Gap-filling) analiza lo que se aceptó y lo que se rechazó, escribe el siguiente lote de hipótesis y rastrea la cobertura para que los agentes no sigan repasando el mismo terreno.
- La validación (Validation) vuelve a comprobar cada candidato de forma independiente, elimina los duplicados y decide.
No inventamos este flujo de trabajo. Cloudflare describe las mismas etapas: reconocimiento, caza en paralelo, validación independiente, deduplicación, informes, y su artículo ayudó a dar forma al nuestro.
Así es como se ve un candidato antes de que cuente como un hallazgo:
objetivo: componente y punto de entrada que un atacante realmente puede alcanzar invariante: la propiedad que debe mantenerse mecanismo: la forma específica en que se podría hacer que se rompa éxito: prueba observable: un pánico, un bloqueo, una entrada inválida aceptada reproductor: un artefacto autónomo que se ejecuta contra el código real dedup: una clave, para que dos agentes no persigan lo mismo
El esquema está ahí por una razón. Obliga a un reclamo específico y comprobable y a una definición clara de finalizado. Un agente que tiene que escribir una prueba observable no puede recurrir a "esto parece arriesgado".
Reproducible o no sucedió
Una regla importa más que cualquier otra. Un candidato no es un hallazgo hasta que haya un artefacto autónomo que reproduzca el fallo contra el código real, y que se ejecute para alguien que no lo escribió.
El reproductor no lee el informe y no le importa lo seguro que sonaba el modelo. O se ejecuta o no.
La mayor parte de su valor reside en los falsos positivos que detecta. Tres de ellos surgen una y otra vez, y cada uno es el agente obteniendo una aprobación por la razón equivocada:
- Un pánico que solo ocurre en una compilación de depuración (debug build). Compílalo y ejecútalo de la forma en que el software se distribuye realmente, y el valor simplemente se desborda (wraps around). Nada falla. Parece un fallo, pero no lo es.
- Un reproductor que construye algún valor interno a mano, uno que ninguna entrada real podría producir jamás, porque cada ruta que controla un atacante lo rechaza antes. El error solo se "reproduce" contra una función que nada alcanzable llama de esa manera.
- En el trabajo de verificación formal, una prueba que se aprueba pero no significa lo que querías. La afirmación es trivialmente cierta independientemente de lo que haga el código, o es más débil que la propiedad que pretendías capturar. El verificador está satisfecho, pero el teorema no restringe el comportamiento que realmente te importaba.
Nada de esto es nuevo. Es lo mismo que una prueba que pasa porque en realidad no comprueba nada. Lo nuevo es el volumen. Un agente escribe la versión inútil tan rápido como la real, y con la misma confianza. Así que la comprobación tiene que ser automática. No puedes contar con que el agente se dé cuenta por sí mismo.
La relación señal-ruido es la mayor parte del trabajo
La mayoría de los candidatos son incorrectos, duplicados o están fuera de alcance. Ese no es un problema con el método; así es como funciona. El objetivo es rechazar los incorrectos rápidamente y respaldar los reales con pruebas que sean difíciles de discutir.
Cada candidato que sobrevive pasa por dos comprobaciones independientes. ¿Puede un atacante real alcanzarlo en una configuración normal? ¿Y cuánto le cuesta al atacante llevarlo a cabo, en comparación con lo que le cuesta a la red si funciona? Un error que cualquier par individual puede desencadenar es muy diferente de uno que necesita acceso especial o una gran cantidad de recursos.
Todo se comprueba contra una lista actualizada de lo que ya se conoce, se ha solucionado o se ha rechazado. Sin eso, los agentes siguen redescubriendo el mismo problema cerrado y reportándolo una y otra vez.
Las tasas de aceptación varían mucho de un objetivo a otro, y esa variación es útil por sí misma. Ejecuta esto contra código maduro y fuertemente auditado y casi nada sobrevive, lo cual sigue valiendo la pena saber. "Buscamos a fondo y no encontramos nada" es un resultado real. Ejecútalo contra código menos explorado, o contra código verificado formalmente, donde una prueba comprobada por máquina cubre un modelo y solo se asume que el código de bytes implementado coincide con él, y más cosas logran pasar.
No somos los únicos que descubrimos que el triaje es la parte difícil. La principal conclusión de Cloudflare fue que un alcance estrecho supera a un escaneo amplio. El agente de pruebas basadas en propiedades de Anthropic generó algo así como mil informes candidatos, luego usó clasificación y revisión de expertos para reducirlo a un nivel superior que se mantuvo alrededor del 86 por ciento de las veces. La generación fue la parte fácil. No voy a publicar nuestros propios números aquí; vinculados a un objetivo específico, dirían más sobre el objetivo que sobre el método.
En qué son buenos los agentes y dónde engañan
Hay mucho revuelo (hype) en ambas direcciones, así que aquí hay una lista sencilla de lo que los agentes hacen bien y dónde engañan.
| Buenos en | Engañosos en |
|---|---|
| Leer la especificación y el código juntos | Cadenas de llamadas que parecen alcanzables pero no lo son |
| Establecer y comprobar un invariante real | Burlar la comprobación de éxito (una aprobación por la razón equivocada). |
| Redactar un reproductor a partir de una idea de una línea | Inflar la gravedad para que coincida con lo dramático que suena el informe |
| Sugerir una causa raíz antes de que hayas mirado | Errores que abarcan una secuencia de pasos válidos |
La división ni siquiera es constante de una tarea a la siguiente. Stanislav Fort, al probar una variedad de modelos en vulnerabilidades reales, llama a esto una frontera irregular, o un modelo que recupera una cadena de explotación completa en una base de código puede fallar en el rastreo básico del flujo de datos en otra. No puedes asumir que un buen resultado significa que el siguiente se mantendrá, lo cual es otra razón por la que cada candidato se comprueba por sí solo.
La última fila es la importante. Una sola sesión de agente es buena en el razonamiento de un solo intento (one-shot) y mala en los errores que abarcan una secuencia de pasos, donde cada paso es válido y solo el orden es incorrecto. Para esos, el agente no es la herramienta de búsqueda. Su trabajo es sugerir qué secuencias vale la pena ejecutar a través de un entorno de pruebas con estado. Usado de esa manera, funciona bien. Usado como reemplazo del entorno de pruebas, pasa por alto los errores más costosos que existen, los que solo aparecen a lo largo de una secuencia.
Manteniéndolo honesto
Unos pocos hábitos hacen la mayor parte del trabajo para que los hallazgos de los agentes sean confiables, y ninguno de ellos es complicado.
- Procedencia en cada artefacto: qué lo produjo, con qué contexto, contra qué revisión. Un hallazgo debería ser algo que puedas volver a ejecutar meses después.
- Determinismo donde cuenta: un entorno, una forma de construir y ejecutar, para que "reproduce" signifique lo mismo en cada máquina, no solo en la que se encontró.
- Normas, no guiones (scripts): dile a los agentes lo que importa, los invariantes y el estándar para un hallazgo real, en lugar de un procedimiento numerado. Los agentes con guiones excesivos se rompen de la misma manera que las pruebas sobreespecificadas, siguen los pasos después de que los pasos dejan de tener sentido. Un estudio de archivos de contexto de repositorios encontró lo mismo: los requisitos adicionales redujeron el éxito de la tarea y aumentaron el costo en más del 20%, y los autores recomiendan mantener el contexto en los requisitos mínimos.
- Una persona toma la decisión final: los agentes sugieren. No deciden qué es real, qué es un duplicado de un problema conocido o qué se divulga y cuándo.
El cuello de botella se movió
La IA no reemplazó al investigador de seguridad. Movió el trabajo. El tiempo que solía dedicarse a idear y perseguir hipótesis ahora se destina a juzgarlas a escala, lo que incluye construir el oráculo, ejecutar el triaje, mantener la lista de problemas conocidos y manejar la divulgación.
El cuello de botella no desapareció. Pasó de encontrar errores a confiar en los resultados, lo cual es un lugar mejor para él, porque ahí es donde el juicio humano realmente importa. Pero sigue siendo un cuello de botella, e ignorar eso es cómo terminas enviando un "está bien" equivocado.
Las prácticas que hacen que esto funcione no son nuevas. Los fallos reproducibles, los oráculos reales y el triaje cuidadoso son las mismas prácticas que convirtieron el fuzzing de un tema de investigación en una práctica estándar durante los últimos quince años. Las herramientas son nuevas. Las prácticas no lo son.
Qué tan rápido siguen cambiando las herramientas es una pregunta abierta. Nicholas Carlini, cuidadoso y alguna vez escéptico, argumenta que vale la pena tomar en serio el caso exponencial, incluso mientras mantiene amplios márgenes de error al respecto. Si el lado de la generación sube tan rápido, el lado del juicio tiene que subir con él, o la brecha entre lo que se produce y lo que realmente se verifica solo se amplía.
Para los sistemas de los que depende Ethereum, esa es la parte que importa. Los agentes nos permiten cubrir mucho más terreno del que podríamos a mano. A cambio, piden un juicio más cuidadoso, a través de una pila mucho más grande de reclamos que suenan convincentes. Ese es un intercambio que vale la pena hacer, siempre y cuando recuerdes que el juicio es el verdadero producto.