Un ingeniero de seguridad construyó en 7 días un servidor MCP que asusta a un agente de IA con vulnerabilidades

Un especialista en seguridad de la información se montó un asistente de IA con una pizca de paranoia: AppSecGate, un servidor MCP local que lanza escáneres, mantiene una base de hallazgos y obliga al agente a ocuparse de las vulnerabilidades en lugar de quitárselas de encima. La primera versión costó 7 días, unos 210 millones de tokens y aproximadamente 3000 rublos, es decir, unos 14 rublos por millón de tokens. La última ejecución sobre OWASP Juice Shop duró unos 50 minutos y costó alrededor de 15 rublos. El agente, basado en deepseek-v4-flash, procesó 200 hallazgos y corrigió 56, entre ellos 8 critical y 45 high.

Por qué AppSec se está convirtiendo en un cuello de botella

El SSDLC clásico funciona así: el desarrollador escribe código en el IDE, el código llega a Git y el CI/CD ejecuta SAST, SCA y DAST. Los informes pasan a ASOC/ASPM, donde se deduplican y se enriquecen. Después, un especialista de seguridad hace el triaje de los hallazgos y crea tareas en el tracker. El principal inconveniente del esquema es que la velocidad de corrección es impredecible. Si se rompe un escáner, no hay con qué reemplazar una librería vulnerable o el responsable de AppSec se va de vacaciones, una corrección puede esperar mucho tiempo. La gran ventaja es que el reparto de responsabilidades está claro y resulta fácil explicar al negocio que la seguridad hay que pagarla.

Los LLM sobrecargan este esquema. Los desarrolladores primero pulsaban TAB, luego pedían al agente que escribiera un método y ahora le dan una especificación técnica que redactó el propio modelo a partir de una tarea también escrita por un modelo. Hay más código, es más enrevesado, crece el volumen de triaje y las pruebas manuales se complican. A eso se suman los vibe coders, que hacen proyectos en solitario y creen que el modelo no confunde desarrollo con producción.

Si simplemente se pone un agente en cada rol, el resultado es un bucle largo en el que todo queda cubierto y los tokens se gastan, pero el proceso difícilmente puede llamarse óptimo. Que los agentes dialoguen directamente entre sí también es arriesgado. El autor bromea: lo primero que podrían descubrir es que ponerse de acuerdo mediante prompt injection es más rápido. La única duda es si se agotará antes el presupuesto de tokens.

Menos agentes, más estructura

La variante sistémica que propone el autor es más sencilla:

• TaskTracker sale del procesamiento de hallazgos, porque a los agentes les conviene más intercambiar datos estructurados. El tracker puede mantenerse para el control del tiempo y la imputación de tokens.
• En el CI/CD queda un único agente autónomo que recibe de ASOC el contexto sobre los hallazgos. No es imprescindible: puede sustituirlo un agente que lance el especialista de seguridad.
• ASOC/ASPM pasa de ser un sistema para personas a ser un sistema para agentes.
• El escaneo se desplaza a la izquierda (shift-left): el agente lanza los escáneres por sí mismo mientras escribe código, como un formateador o los tests unitarios. El push no se bloquea y el problema se escala a AppSec o al Lead. Escanear solo el diff ahorra tokens, porque el agente ya está trabajando con ese archivo. El triaje local se registra en un servidor central, y la eficacia del enfoque puede demostrarse a la dirección.

Cómo funciona AppSecGate

El MVP es un servidor MCP local en un Docker aislado, con un conjunto de escáneres y una base SQLite; la arquitectura deja margen para un servidor central. El agente trabaja a través de Cline: el autor migró a esta herramienta desde Continue y escribió un AGENTS.md. Estas son las herramientas que utiliza el agente:

• get_config — comprobación de la configuración;
• scan_project — lanzamiento del escaneo y resultado agregado;
• query_findings_db — acceso SQL a la base de hallazgos (el agente, por alguna razón, prefiere esta, aunque hay alternativas);
• get_fix_context_batch — contexto de los hallazgos para corregirlos;
• verify_fix_batch — verificación de la corrección o supresión del hallazgo como FALSE_POSITIVE.

Con la petición «Comprobar la seguridad del proyecto» en modo de planificación, el agente recorrió esta cadena y concluyó que no había que arreglar nada, porque Juice Shop es vulnerable a propósito. Hubo que explicarle que se estaban probando las herramientas. Tras cambiarlo al modo Act, empezó el triaje, consultó la base de forma periódica y al final elaboró un informe.

El autor probó los modelos locales con un benchmark de siete variantes en una sola RTX 4060 Ti 16GB. No hubo un ganador claro, pero sí sacó conclusiones.

La conclusión práctica para los equipos es esta. Una capa MCP estructurada entre los escáneres y el agente convierte la seguridad en un paso más del ciclo de desarrollo. El coste de una ejecución, 15 rublos con un modelo en la nube barato, es notablemente inferior a una hora de trabajo de un ingeniero de AppSec dedicada al triaje rutinario.

También resultan útiles los detalles menores: un AGENTS.md con reglas claras, la separación entre Plan y Act y una marca explícita de FALSE_POSITIVE con verificación. Esta combinación no sustituirá al AppSec.

La rutina pasará al agente, y las personas se quedarán con la arquitectura segura y la búsqueda de vulnerabilidades lógicas. Como efecto secundario, queda una herramienta lista para los vibe coders en solitario que necesitan TimeToMarket y no quieren acabar como ilustración de fallos de la IA en las noticias.