
Durante años, el gran talón de Aquiles de las herramientas automáticas en seguridad fue su ruido: informes de vulnerabilidad confusos, hallazgos sin contexto y listas interminables de falsos positivos que saturaban a equipos de desarrollo y a maintainers de proyectos open source. Frente a ese paisaje, empieza a imponerse un paradigma distinto, agentes orquestados por IA capaces de encontrar, verificar y demostrar vulnerabilidades de extremo a extremo, con un workflow sorprendentemente parecido al de un cazador de bugs humano. El ejemplo más sólido que tenemos a la vista es A2, una evolución del proyecto A1, orientada a aplicaciones Android, que introduce una novedad decisiva: validación automatizada por etapas.
La propuesta de A2 es sencilla en su formulación, pero profunda en sus consecuencias para el pentesting moderno. En lugar de limitarse a señalar “posibles” problemas, el agente traza un plan de ataque, ejecuta acciones concretas dentro de la app objetivo y valida el resultado como lo haría un analista: con pruebas de concepto que demuestran explotabilidad. Esa “prueba viviente” es lo que convierte a un hallazgo en algo priorizable para un product owner, un equipo de AppSec o un programa de bug bounty.
Cobertura y precisión
En la suite de pruebas Ghera para Android, A2 alcanzó una cobertura del 78,3 %, frente al 30 % de un analizador estático reconocido (APKHunt). Cuando se lanzó contra 169 APK reales, el agente detectó 104 vulnerabilidades de día cero, y 57 de ellas fueron confirmadas por exploits generados automáticamente. Entre los casos, apareció un bug de severidad media en una app con más de 10 millones de instalaciones: una redirección de intents que abría la puerta al control por parte de malware. Esto no es “ruido”: es demostrabilidad.
Validación escalonada (la pieza que faltaba)
A1 ya había mostrado músculo explotando errores en contratos inteligentes, pero su verificación era binaria: ¿genera beneficios el ataque? A2 añade un módulo de validación paso a paso. Si la app guarda una clave AES en texto plano, A2:
localiza la clave (por ejemplo, en strings.xml);
la usa para generar un token falso de reset;
comprueba que el token realmente elude la autenticación;
verifica la actividad en la app y que la navegación llega a la pantalla esperada.
Cada etapa deja rastros y aserciones verificables (coincidencia de valores, estados de actividad, vistas en pantalla). Este es el tipo de evidencia que convierte a un reporte en algo accionable en minutos, no semanas.
Arquitectura multi-modelo con roles humanos
A2 no se “casa” con un único LLM. Orquesta OpenAI o3, Gemini 2.5 Pro, Gemini 2.5 Flash y GPT-oss-120b distribuyendo funciones:
Planificador: define la estrategia de ataque.
Ejecutor: corre acciones en el entorno objetivo.
Validador: confirma (o refuta) el resultado.
Este reparto emula el ciclo humano de investigación: hipótesis, experimentación y verificación. ¿La ganancia? Menos ruido, más hallazgos confirmados.
Economía del hallazgo
Los autores cuantifican el costo: entre 0,0004 y 0,03 USD por app para la fase de detección (según el modelo), y 1,77 USD promedio por ciclo completo con verificación. Si se usa solo Gemini 2.5 Pro, el coste sube a 8,94 USD por fallo. Para dimensionar: otro experimento académico mostró que GPT-4 podía crear un exploit desde la descripción de una vulnerabilidad por 8,80 USD. Traducido al día a día, el precio de encontrar y confirmar fallos en móviles empieza a ser competitivo respecto del valor de un bug de severidad media en programas de recompensas que pagan cientos o miles de dólares. El impacto en el ROI del pentesting es evidente.
Menos falsos positivos, más PoCs listas: la validación embebida evita el clásico “¿pero esto de verdad se explota?”. La respuesta viene con los pasos y el resultado.
Auditorías por lotes y priorización basada en evidencia: puedes lanzar el agente sobre una cartera de APKs y ordenar por “explotabilidad confirmada”, no por “probabilidad”.
Integración continua: A2 encaja en pipelines CI/CD como gate de seguridad: cada build de Android pasa por detección y, si aparece un hallazgo, el pipeline adjunta la PoC y bloquea el release hasta su remediación.
Shift-left con foco: en lugar de bombardear a desarrollo con findings genéricos, se entrega una lista corta de fallos explotables con pasos de reproducción. La fricción baja, la corrección sube.
No todo es lineal. Los autores advierten que:
A2 puede acelerar el bug hunting, pero los programas de recompensas no cubren todo el espectro de fallos, y parte de lo detectado podría no tener canal de divulgación. Eso abre la puerta a usos ofensivos si se carece de ética o gobernanza.
Por ahora, el código fuente se ofrece solo a investigadores con acuerdos oficiales, buscando un equilibrio entre ciencia abierta y divulgación responsable.
Para equipos serios de pentesting, esto exige políticas claras: scopes, límites, publicación coordinada (CVD), entornos de prueba aislados, logging exhaustivo y autenticación/control de acceso para cualquier agente automatizado. La madurez operativa administrativa importa tanto como la técnica.
Del “scripting” a la orquestación
El valor diferencial se desplaza: menos tiempo en wiring de herramientas, más en definir estrategias, ajustar prompts técnicos, diseñar escenarios de validación y combinar fuentes (trazas, dinámicas, revisión de recursos, ingeniería inversa selectiva). El pentester pasa a ser arquitecto de sistemas de descubrimiento, no solo usuario de scanners.
Evaluación y gobierno de agentes
Habrá que medir cobertura real, tasa de confirmación y reproducibilidad de PoCs en diferentes entornos (emuladores, dispositivos físicos, distintas APIs de Android). Se abrirá un subcampo de MLOps de seguridad: conjuntos de pruebas curados (como Ghera y sucesores), benchmarks públicos, trazabilidad y control de costos por modelo.
Skills que suben de valor
Conocimiento profundo de ecosistemas móviles (intents, permisos, almacenamiento, WebView, crypto en cliente).
Capacidad de construir validaciones robustas (asserts de UI/estado/registro).
Ética y coordinación con programas de bug bounty, PSIRT y equipos de producto.
Manejo de costos por consulta y latencia: cuándo usar un modelo premium, cuándo uno rápido y barato, cuándo ejecutar en local.
De la señal al riesgo
La métrica que importará no será “vulnerabilidades encontradas”, sino riesgos mitigados. Un agente que te entrega 50 hallazgos con 40 PoCs reproducibles será más valioso que otro con 5.000 “señales” inciertas. Las direcciones de seguridad se moverán hacia SLA de remediación basados en evidencia.
Pilota A2-like en un entorno controlado: define un set de APKs, incluye “semillas” con vulnerabilidades conocidas y mide cobertura, confirmación y costo por hallazgo.
Integra validación como contrato: sin PoC reproducible, el hallazgo no sube a backlog. Esto libera a desarrollo de inflaciones de riesgo.
Instrumenta guardrails: scope estricto, entornos aislados, rotación de credenciales y registros forenses. Si un agente puede explotar, también puede romper.
Cierra el loop: para cada PoC confirmada, genera un test de regresión automático que evite la reintroducción del fallo.
Forma al equipo: promps técnicos, lectura crítica de trazas, y criterios de severidad que contemplen explotabilidad demostrada.
El péndulo por fin se mueve del “escaneo ciego” al pentesting dirigido por evidencia. Agentes como A2 muestran que los LLM, bien orquestados y con módulos de validación, no sustituyen al analista: lo potencian. El futuro inmediato del pentesting no es una lluvia de alertas, sino una cola de trabajo corta, priorizada y verificable. Y eso, para quienes defendemos sistemas en producción, es exactamente la clase de revolución que necesitamos.
¿Estamos presenciando el fin de las tareas de Red Team y Pentest tal cual las conocemos?
Fuente: The Register