Zendoric
← Volver al día · 7 de septiembre de 2026

Bobbin: un agente de pentesting con IA 100% local que publica también sus fracasos

🕒 Publicado en Zendoric: 7 de septiembre de 2026 · 02:54

✨ Generado con IA · cómo se hace

Bobbin es un agente de código para modelos pequeños que corren en local vía Ollama: el código nunca sale de la máquina, así que puede auditar proyectos bajo NDA que ningún LLM en la nube podría tocar. Su autor publica miles de ejecuciones fallidas junto a las que funcionan, una transparencia benchmark poco habitual en el sector.

🎧 Escuchar el análisis · voz sintética

Por Zendoric · 7 de septiembre de 2026.

Bobbin es un agente de codificación pensado para modelos pequeños —de 7.000 a 32.000 millones de parámetros, del tamaño que corre en una sola GPU de consumo— que se ejecutan en local a través de Ollama, la herramienta que permite correr modelos de lenguaje en el propio ordenador sin pasar por la nube. Según su documentación, el proyecto no depende de ningún paquete externo de Python: solo librería estándar. Su bucle es simple: el modelo emite una llamada a herramienta estructurada, el programa la ejecuta, el resultado vuelve como mensaje y el modelo recibe otro turno, hasta que responde en prosa o se agota el presupuesto de pasos.

El autor compara Bobbin con aider, uno de los agentes de código de referencia, bajo un mismo arnés de pruebas cuyos resultados en bruto —450 ejecuciones— están publicados en el propio repositorio. En fixtures propias de refactorización multiarchivo, Bobbin gana con holgura: 107 aciertos sobre 114 frente a 56 y 52 de las dos configuraciones de aider. Pero al saltar a código real —el proyecto pallets/click, con 12.674 líneas y 1.991 tests—, el resultado depende del modelo: con qwen3-coder de 30.000 millones de parámetros pierde (6 sobre 18 frente a 9 de aider); con nemotron gana por goleada (12 sobre 18 frente a 3). El propio autor resume el agregado —50% frente a 33%— como "empate con un margen amplio, no una ventaja", una honestidad poco frecuente en el marketing de herramientas de IA.

El argumento de fondo del proyecto, sin embargo, no es competir con aider: es que correr en local habilita una categoría de trabajo que un modelo en la nube no puede tocar por motivos de confidencialidad. Un código bajo NDA, una auditoría de un cliente con cláusula de no fuga de datos, un pentest cuyo objetivo no se puede describir a un proveedor externo: todo eso sigue pudiendo revisarse con un modelo que nunca abandona la máquina. Según las pruebas del propio proyecto, en revisión de código los tres modelos evaluados (qwen3-coder:30b, nemotron-3.5-lightning y qwen2.5-coder:7b) detectan sin excepción las vulnerabilidades plantadas —inyección SQL, inyección de comandos, hash débil, secreto embebido, token predecible, path traversal—; el coste real son los falsos positivos, como marcar una llamada `subprocess.run()` correctamente parametrizada como si fuera insegura.

En explotación activa contra un objetivo de pruebas offline, el patrón se invierte: encontrar el fallo es la parte difícil. Solo la inyección SQL cae de forma fiable, y únicamente con los dos modelos de 30.000 millones de parámetros; el IDOR (acceso a recursos ajenos por fallo de comprobación de propiedad) y la exposición de datos por fuerza bruta de rutas fallan en todos los modelos hasta que se añade una herramienta específica y acotada de barrido de identificadores —no un shell genérico— que sí destraba el IDOR. Por diseño, Bobbin no ejecuta comandos arbitrarios: genera una prueba de concepto que un humano debe lanzar. El proyecto documenta también, con el mismo detalle, los mecanismos que no funcionaron —avisos, bloqueos y guardas contra bucles de un modelo que se niega a admitir que no encontró nada—, dejándolos publicados como resultados negativos en lugar de ocultarlos.

Nuestra lectura es que el interés de Bobbin no está en si gana o pierde frente a aider, sino en lo que confirma sobre hacia dónde va la seguridad ofensiva asistida por IA: la capacidad ya existe para tareas acotadas —encontrar una inyección SQL, revisar un archivo en busca de patrones conocidos— y sigue faltando para las que exigen persistencia y juicio, como la enumeración sistemática. Es el mismo patrón que ya hemos visto en otros contextos: la ciberseguridad funciona como termómetro fiable de qué tan lejos llega realmente un modelo, mucho más que cualquier benchmark saturado. Y el hecho de que sea un modelo local, corriendo en una GPU de escritorio, el que sostenga ese primer filtro de auditoría es otra prueba de que la frontera abierta y ejecutable en local está cerrando huecos que hace un año solo cubrían modelos de frontera en la nube: la democratización que sostiene nuestra tesis de fondo sobre la abundancia no llega solo de los grandes laboratorios, también de proyectos de un único desarrollador dispuestos a medir y publicar dónde fallan.

Conviene, eso sí, ponerlo en su escala real: es un repositorio incipiente, con métricas propias no auditadas por terceros y apenas tracción en la comunidad. Su valor no es el de un lanzamiento que cambie el mercado, sino el de una muestra de metodología —publicar los 4.133 registros de ejecución, incluidos los fracasos— que debería ser la norma en un sector que suele vender capacidad con benchmarks escogidos a modo. Si algo hay que aplaudir aquí no es que un modelo pequeño iguale a un frontera, sino que alguien se moleste en decir exactamente en qué no lo hace.

🔗 Relacionadas en Zendoric

Fuentes y referencias