⚔️Red team automatizado: cómo los agentes IA encuentran vulnerabilidades que los humanos no ven

Tu equipo de seguridad hizo pentest anual en enero. Encontraron 12 vulnerabilidades, las arreglaron en 6 semanas. Mayo llega, tu CTO les pide la auditoría para un cliente enterprise. El pentest dice "sitio limpio" según el reporte de enero. Lo que el reporte no dice es que en febrero desplegaron un nuevo feature que introdujo 3 vulnerabilidades nuevas, en marzo actualizaron un plugin que agregó path de SQL injection, y en abril un empleado rotó que tenía permisos de admin y ahora esas credenciales están en el dark web.

Ese es el problema del pentest anual: foto fija en un mundo que cambia rápido. El red team automatizado con IA soluciona eso — escaneo continuo, capacidad de encontrar vulnerabilidades complejas que escáneres tradicionales no capturan, y costo más bajo que un red team humano full-time.

Este artículo explica cómo funcionan los agentes IA ofensivos, qué encuentran que otros no, cuándo NO son suficientes, y cómo integrarlos con red team humano tradicional para máxima cobertura.

Qué hace diferente a un agente IA ofensivo

Un escáner tradicional (Burp Suite, Nessus, OWASP ZAP) funciona como checklist: prueba patrones conocidos contra tu aplicación. Request con ' en parámetros → detecta SQL injection. Request con <script> → detecta XSS. Muy efectivo para vulnerabilidades de patrón.

Un agente IA ofensivo funciona como un pentester junior trabajando: primero explora tu aplicación para entenderla, después formula hipótesis sobre dónde podrían haber vulnerabilidades dado esa comprensión, después prueba específicamente esas hipótesis, después combina hallazgos para construir exploits más complejos.

Ejemplo concreto de la diferencia:

• Escáner tradicional: prueba 50,000 payloads SQL injection contra todos los endpoints. Encuentra 3 endpoints vulnerables. Reporta.
• Agente IA: explora la aplicación. Identifica que es una plataforma e-commerce con área de admin, endpoints API, integración con pagos. Hipotetiza: "el endpoint /api/orders/:id probablemente tiene control de acceso basado en user_id; si puedo manipular el user_id puedo ver órdenes de otros clientes". Prueba la hipótesis. Encuentra que sí, hay un IDOR. Construye cadena: IDOR en /api/orders + información sensible en response = exfiltración de data de clientes.

El escáner encontró patrones; el agente construyó un exploit real con impacto específico.

3 clases de vulnerabilidades donde los agentes brillan

1. Cadenas lógicas de bugs (chained exploits)

Un bug solo raramente es crítico. Tres bugs menores encadenados pueden ser catastróficos. Los escáneres tradicionales reportan cada bug individualmente (low severity) — no los correlacionan.

Ejemplo real reportado en engagement: una aplicación tenía:

• Bug A: usuario autenticado podía ver ID de otros usuarios en response de endpoint.
• Bug B: endpoint de reset password aceptaba user_id en parámetro (diseño raro pero no vulnerabilidad inmediata — el reset iba al email del user).
• Bug C: endpoint interno de "admin account recovery" no validaba si el request venía de admin legítimo; solo checaba que venía de IP interna.

Por separado: todos low severity. Escáner tradicional los listó como mediums-lows.

Agente IA: encadenó. "Obtengo IDs de otros usuarios (A). Uso Bug B para pedir reset password con el ID de un admin. El reset va al email del admin, no al mío — pero Bug C me permite forzar recovery desde IP interna (compromis de servidor intermedio). Combinado: RCE con admin."

Severity real: crítica. El agente lo encontró en 3 horas de análisis. El pentester humano lo habría encontrado en 2-3 días si tenía suerte.

2. Abuso de lógica de negocio

Las vulnerabilidades más costosas no son técnicas — son de lógica. "La aplicación permite hacer X, que técnicamente funciona bien, pero que genera daño económico si lo hacés de forma específica".

Ejemplo: una tienda e-commerce con cupones de descuento. Cada cupón tenía reglas: se puede usar 1 vez por usuario, en compras >$50, válido hasta fecha X. El escáner tradicional no tiene forma de testear "lógica de cupones" — no es vulnerabilidad de patrón.

Un agente IA exploró la aplicación, entendió el flujo de checkout, identificó los endpoints de aplicación de cupones, y probó variaciones: ¿qué pasa si aplico el mismo cupón en dos carritos simultáneos (race condition)? ¿Qué pasa si aplico cupón, remuevo producto, agrego otro, y el cupón sigue activo (persistencia de estado)? ¿Qué pasa si uso cupón en compra, cancelo la compra, y después intento usar el mismo cupón (cancelación no invalida uso)?

Encontró que la última variante funcionaba — se podía abusar para descuentos ilimitados. Impacto financiero potencial: pérdida significativa si se explotaba a escala.

3. Patrones específicos de tu aplicación

Cada aplicación tiene su dialecto: nombres de parámetros custom, estructura de endpoints, convenciones internas. Los escáneres genéricos no aprenden eso; usan diccionarios universales.

Los agentes IA, después de la fase de exploración, entienden el "dialecto" de tu aplicación específica. Si tu API usa convención /api/v2/{resource}/:id/actions/:action, el agente prueba variaciones dentro de ese patrón, no ataques genéricos inefectivos.

Esto es especialmente útil en aplicaciones enterprise custom donde los escáneres tradicionales devuelven 95% falsos positivos de ruido y 5% útiles, mientras que los agentes devuelven 30% falsos positivos y 70% útiles.

Safety boundaries: el agente descontrolado es peligroso

Un agente IA ofensivo tiene capacidades reales. Sin constraints adecuados, puede:

• Causar downtime: enviar volumen de requests que satura el servidor (DoS accidental).
• Modificar data real: si descubre que puede UPDATE algo, y está en nivel de autonomía alto, puede hacer cambios.
• Borrar datos: peor caso — encuentra un DELETE vulnerable y lo ejecuta "para confirmar el exploit".
• Afectar usuarios reales: si no distingue entre entorno de test y producción, puede crear transacciones falsas, emails a clientes reales, etc.

Por eso los engagements serios incluyen definición clara de qué el agente PUEDE y NO PUEDE hacer:

Constraints típicos

• Solo lectura por default. Cualquier acción que modifica state requiere override explícito en el engagement spec.
• Rate limiting. Máximo X requests/segundo para no saturar servidores.
• Blacklist de operaciones. Nunca ejecutar DELETE, DROP, TRUNCATE. Nunca modificar usuarios admin existentes. Nunca enviar emails reales (usar captura).
• Scope de targets claro. Solo probar los sistemas autorizados. Si descubre un sistema relacionado, reportar pero no probar.
• Sandbox para pruebas destructivas. Si una vulnerabilidad requiere destructive testing (para confirmar impacto real), el agente reporta y el humano decide si proceder en ambiente controlado.

En Gladiador, estos constraints son parte del engagement setup. El cliente firma exactamente qué puede hacer el agente y qué no. Cualquier acción fuera de scope se bloquea por diseño.

Integración con red team humano

Red team automatizado NO reemplaza red team humano. Los complementa:

Lo que hace mejor el agente automatizado

• Cobertura amplia continua: corre 24/7, no se cansa, escanea todo el perímetro.
• Velocidad: encuentra vulnerabilidades de patrón complejo en horas vs días.
• Consistency: misma metodología cada scan, sin drift de pentester humano cansado.
• Bajo costo por unidad: un scan que haría un pentester junior en 3 días, el agente lo hace en 2 horas.

Lo que hace mejor el red team humano

• Ingeniería social: los agentes no pueden (aún) ejecutar phishing efectivo dirigido.
• Pensamiento lateral: "¿qué pasa si combino esto con lo otro en una forma que nadie intentó?". Los agentes están empezando a hacer esto pero los humanos seniors lo hacen mejor.
• Contexto de negocio profundo: después de 2 semanas de engagement, un humano senior entiende la empresa de una forma que un agente aún no iguala.
• Creatividad adversarial: pensar como adversario real con objetivos específicos.

Estrategia combinada recomendada

• Red team automatizado continuo: Gladiador corre permanentemente sobre sistemas críticos. Detecta vulnerabilidades nuevas introducidas por deploys. Genera reportes mensuales.
• Red team humano 1-2 veces al año: engagement de 2-4 semanas por pentester senior externo. Profundidad que el agente no puede.
• Red team humano dirigido: cuando aparece evento específico (breach en empresa similar, nueva regulación, deploy de sistema crítico), engagement focalizado de 1-2 semanas.

Este combo cubre tanto cobertura continua como profundidad dirigida, a costo razonable para empresa mediana-grande.

Cómo distinguir ofertas serias de marketing

El mercado de "AI-powered pentesting" se llenó de vendors que aplican ML básico a escáneres tradicionales y lo llaman "agente IA". Preguntas diagnósticas para filtrar:

1. ¿Qué modelo usan y cómo lo entrenaron?

Respuesta seria: "Usamos Drokio Sentinel v1 + modelo custom para planificación adversarial. Entrenamos el modelo de planificación con engagements sintéticos y reales sanitizados. Arquitectura es agente con capacidad de ejecutar sub-agentes para tareas específicas."

Respuesta marketing: "Usamos inteligencia artificial avanzada para mejorar la detección."

2. ¿Pueden mostrar reporte real sanitizado?

Seria: muestran 2-3 páginas de reporte real con datos del cliente removidos. Ves estructura, profundidad, evidencia de razonamiento.

Marketing: "Por confidencialidad no podemos compartir reportes específicos."

3. ¿Qué safety constraints tiene el agente?

Seria: lista específica (rate limits, blacklist de operaciones, scope enforcement, approval gates para acciones destructivas).

Marketing: "Nuestro agente es completamente seguro."

4. ¿Cómo manejan falsos positivos?

Seria: el agente clasifica por confianza, reportes marcan claramente hallazgos de alta confianza vs requieren validación humana, proceso de feedback refina el modelo.

Marketing: "Nuestra IA tiene cero falsos positivos."

5. ¿Qué NO hace el agente?

Seria: admite limitaciones específicas (no hace ingeniería social humana, no reemplaza pentest tradicional en ciertos escenarios, requiere configuración apropiada para tu contexto).

Marketing: "Nuestro agente encuentra todas las vulnerabilidades automáticamente."

Si las respuestas caen en la columna "seria", estás frente a oferta real. Si caen en "marketing", probablemente es escáner tradicional con marketing de "AI".

Cierre

Los agentes IA ofensivos son una capacidad real disponible hoy, no futuro cercano. Empresas que los integran como complemento de red team humano están encontrando vulnerabilidades que antes pasaban inadvertidas — y encontrándolas más rápido, más barato, y de forma continua en lugar de episódica.

La pregunta no es si los agentes van a ser parte del stack de seguridad enterprise — lo van a ser. La pregunta es cuándo tu organización los integra. Empresas que lo hicieron en 2023-2024 tienen 2-3 años de ventaja acumulada en descubrimiento de vulnerabilidades. Empresas que esperen hasta 2027-2028 van a estar jugando catch-up.

Gladiador está diseñado para ese escenario: capability enterprise sin necesidad de construir agentes desde cero. Incluido en Diesel como parte del paquete, disponible por engagement para clientes Conan hacia arriba.