Fuzzing agéntico de smart contracts: qué es y lecciones para defensores

Ultrafuzz, un orquestador agéntico de fuzzing y búsqueda de amenazas para smart contracts, se ha publicado como código abierto con licencia MIT. Anunciado por Antonio Viggiano y publicado bajo la organización monad-developers, coordina muchos agentes especializados para configurar un repositorio objetivo, modelar sus amenazas, extraer propiedades y cazar errores en paralelo. El código es interesante, pero la aportación más valiosa es un conjunto de cuatro experimentos que responden discretamente a una pregunta que se hace todo el que construye herramientas de seguridad asistidas por IA: ¿qué hace que funcione de verdad el descubrimiento agéntico de vulnerabilidades? Las respuestas van mucho más allá de las DeFi.

Si piensas ejecutar herramientas agénticas como esta, decide primero su salida de red: el laboratorio de contención de la salida de red de PlayCISO recorre las decisiones de permitir, pasar por proxy y denegar.

Qué es Ultrafuzz

A grandes rasgos, Ultrafuzz es un grafo de agentes especializados conectados mediante el traspaso de artefactos. Una ejecución pasa por la configuración y el descubrimiento del proyecto, incorpora una base de datos de vulnerabilidades, define los actores y los flujos de usuario, prepara un arnés de pruebas, modela las amenazas del sistema, especifica las propiedades, se ramifica en muchas estrategias de búsqueda de errores (pruebas de invariantes, pruebas diferenciales, búsquedas dirigidas a objetivos), deduplica y clasifica los hallazgos y redacta un informe. Está pensado para smart contracts en Solidity y se ejecuta con un solo comando sobre un grafo configurable de agentes.

Lo fundamental es que el equipo construyó un entorno de evaluación a su alrededor (UltrafuzzBench, más compatibilidad con suites públicas y algunos conjuntos de datos privados) para que los cambios de prompts y de topología pudieran medirse en precisión, exhaustividad (recall), F1, tiempo, coste y uso de tokens en lugar de discutirse. Esa disciplina guiada por la evaluación es lo que hace que merezca la pena leer sus conclusiones.

Los cuatro experimentos, y por qué importan a quien construye herramientas de seguridad con IA

El equipo hizo una serie de ablaciones controladas, cada una en máquinas distintas para que las ejecuciones no compartieran cachés ni estado, para comprobar qué impulsaba de verdad la ventaja de la herramienta a la hora de encontrar errores.

1. Obligar a cada estrategia a escribir pruebas de fuzzing no era lo óptimo

El diseño original indicaba a los agentes que convirtieran cada propiedad en una prueba de fuzzing ejecutable. Una variante, «NoFuzz», mantenía la misma topología pero pedía a los agentes que investigaran la propiedad directamente («encuentra un error que rompa la propiedad X») en lugar de escribir un arnés. Sorprendentemente, NoFuzz encontró bastantes más errores, y con menos tokens, sin dejar de detectar todos los que encontraba la versión que empezaba por el fuzzing. La lectura del equipo: los modelos capaces pueden detectar muchos errores simples y sin estado leyendo el código, y el coste de escribir un arnés de pruebas consume un presupuesto de contexto que podría dedicarse a encontrar más problemas. Adoptaron como opción por defecto la investigación directa guiada por propiedades.

2. El fuzzing con estado sigue mereciendo su lugar

Eso no jubiló el fuzzing. En otro benchmark, el fuzzing ejecutable sacó a la luz un error que el enfoque de leer el código no encontró: un invariante de conservación que solo se rompía a lo largo de una secuencia (tomar prestada una unidad, dejar pasar el tiempo y después leer el agregado), lo que producía un desajuste de redondeo de una unidad. Los errores que dependen de varias interacciones o de un orden concreto necesitan el razonamiento más profundo y la exploración del estado que aporta el fuzzing con estado. La lección no es «haz fuzzing de todo» ni «no hagas fuzzing de nada», sino reservar el fuzzing ejecutable con estado para los errores que de verdad se benefician de las secuencias y de los cambios de estado.

3. Las propiedades explícitas mejoran la exhaustividad

Una propiedad es una afirmación concreta y comprobable sobre cómo debería comportarse un sistema: «la suma de todos los saldos es igual al suministro total», «las comisiones acumuladas solo aumentan», «una transferencia reduce el saldo del emisor y aumenta el del destinatario en la misma cantidad». Cuando el equipo eliminó por completo el paso de especificación de propiedades, la exhaustividad bajó. No de forma catastrófica, pero sí medible. Dar a los agentes condiciones de corrección concretas que investigar, en lugar de una instrucción vaga de «encontrar errores», es un auténtico multiplicador.

4. La amplitud de la exploración (y la capacidad de cómputo) es una palanca importante

Como ejecutar el mismo prompt varias veces da resultados distintos, una de las palancas más sencillas es gastar más cómputo y ejecutar más estrategias distintas. Ultrafuzz pasó de cinco estrategias a más de veinte, y la exhaustividad creció con ellas. Esto refleja una conclusión más amplia de la investigación de vulnerabilidades asistida por IA: el volumen y la diversidad de los intentos importan tanto como cualquier prompt ingenioso por sí solo. También convierte la búsqueda de errores en un problema explícito de optimización de tiempo y dinero: ¿cómo mantienes la exhaustividad minimizando el gasto?

La lección de seguridad operativa que todos deberían copiar

Escondida en el anuncio está la frase más importante para los defensores: ejecuta Ultrafuzz solo en máquinas virtuales efímeras y aisladas que puedas desechar sin riesgo. Los agentes funcionan en un flujo de trabajo sin restricciones y sin permisos (skip-permissions), lo que significa que pueden instalar o usar herramientas peligrosas o llegar a credenciales sensibles, y los prompts, la elección de modelos y el comportamiento del objetivo pueden empujarlos hacia acciones no previstas o destructivas en el host.

Es la misma clase de riesgo sobre la que hemos escrito a propósito de los routers de LLM maliciosos y la inyección en las llamadas a herramientas: un agente que puede actuar es un «confused deputy» en potencia. Los controles también son los mismos: trata el host del agente como no confiable y desechable, dale el mínimo privilegio y ninguna credencial permanente, limita su salida de red a una lista de permitidos y nunca apuntes un agente sin permisos a una estación de trabajo de desarrollo ni a una máquina que guarde algo valioso. Si adoptas cualquier herramienta de seguridad agéntica, esa postura de aislamiento no es negociable.

Una taxonomía de vulnerabilidades compartida

Ultrafuzz alimenta sus búsquedas con una base de datos estructurada de vulnerabilidades (de momento, el OWASP Smart Contract Security Project), y el equipo propone ir más allá: un grafo de categorías, subcategorías e instancias concretas de errores que los agentes puedan recorrer hasta la profundidad que se elija. Una categoría de «denegación de servicio» podría ramificarse en «DoS de liquidación» y después en modos de fallo concretos, como posiciones residuales (dust) que bloquean la liquidación. La profundidad se convierte en un control de cuánto cómputo gastar, y la cobertura de la taxonomía en un objetivo medible. Una taxonomía común y ampliable de modos de fallo es justo el tipo de infraestructura compartida que hace más sistemática la investigación automatizada de vulnerabilidades, y es un buen recordatorio de que lo que impulsa los resultados es el conocimiento curado de amenazas, no solo la capacidad bruta del modelo.

Qué deberían sacar en claro los equipos de seguridad

• Combina herramientas; no apuestes por una. Las evaluaciones mostraron una y otra vez que enfoques distintos sacan a la luz errores distintos. Superpón la revisión estática, la investigación con IA guiada por propiedades y el fuzzing con estado en lugar de dar por completo un único método.
• Invierte en propiedades e invariantes. Ayudan tanto a las personas como a los agentes, y fueron una de las palancas más claras sobre la exhaustividad. Si escribes smart contracts (o cualquier sistema con condiciones de corrección fuertes), especificar invariantes compensa.
• Presupuesta el cómputo de forma deliberada. Más estrategias diversas y más ejecuciones encuentran más errores. Trata la revisión asistida por IA como un gasto ajustable, no como algo de una sola vez.
• Aísla por defecto las herramientas agénticas. Los agentes sin permisos van en máquinas virtuales desechables, sin credenciales y con la salida de red restringida. Punto.
• Haz red teaming de tus propios modelos y agentes. Antes de confiar en que un agente toque tu código o tu infraestructura, prueba cómo se comporta ante entradas adversarias. Model Audit (PlayCISO Pro) ejecuta comprobaciones de jailbreak, inyección y filtración de secretos contra un endpoint que controles, y MCP Guard (prueba gratis: una cuenta gratuita incluye 3 usos de herramientas Pro) audita configuraciones de agentes/MCP en busca de los errores de configuración que hacen peligroso a un agente.

La señal de fondo es una a la que volvemos una y otra vez en lo que escribimos sobre cómo se detecta y se frena el mal uso de la IA: los sistemas agénticos avanzan rápido y son potentes, y la disciplina que los hace seguros y eficaces (evaluación, aislamiento, mínimo privilegio y conocimiento compartido de amenazas) es exactamente la que los equipos de seguridad ya conocen. Ultrafuzz es una aportación abierta útil precisamente porque muestra ese trabajo a la vista de todos.