Pruebas de seguridad con IA: Cloudflare lanzó 1.107 intentos de ataque contra su propio WAF y solo 49 merecieron atención

La lección más valiosa del último experimento de Cloudflare no es que la IA encontrara fallos en su firewall. Es que el 95% de lo que generó no sirvió, y el sistema estaba diseñado para que eso fuera aceptable. La compañía aplicó pruebas de seguridad con IA a su Web Application Firewall (WAF): 45 escenarios, 1.107 intentos de ataque y, tras la revisión humana, solo 49 hallazgos relevantes. De ahí salieron tres cambios concretos en su Managed Ruleset.

El método parte de un punto poco habitual. En lugar de repetir casos de prueba fijos, Cloudflare tomó ataques que el WAF ya había bloqueado y pidió a modelos de IA de frontera que los mutaran: cambiar la codificación, la ubicación en la petición o la forma de entrega, según la respuesta del intento anterior. Los modelos no tenían acceso a las reglas del WAF, al código fuente ni a señales internas de seguridad, es decir, actuaban como un atacante externo real (black-box). Según el análisis de InfoQ, de los 1.107 intentos, 607 llegaron al conjunto de resultados tras la triage: 558 peticiones bloqueadas por el WAF y 49 hallazgos dignos de remediación. 48 de esos 49 involucraban inyección de comandos o SSRF (server-side request forgery). El resultado final fueron dos detecciones nuevas, SSRF - Obfuscated Host y SSRF - Restricted Protocol, y una mejora de la regla existente SSRF - Cloud.

Cómo funciona el AI harness: pruebas de seguridad con IA sin ceder el control

La clave está en el AI harness, la estructura que rodea al modelo. Un programa en Python construía y reenviaba las peticiones HTTP, mantenía el estado de cada escenario, imponía límites y recogía las respuestas. Una llamada al modelo proponía la siguiente mutación y otra revisaba la respuesta. Así, los intentos se adaptaban sin que la IA controlara directamente la ejecución.

Un ejemplo lo ilustra. En una prueba de SSRF, el modelo fue variando la representación de una dirección de metadatos de nube (decimal, octal y otras formas). Una variante decimal fue bloqueada. En el siguiente intento, mantuvo la forma de la petición pero usó una representación con punto final, y esta vez el cliente recibió una redirección en lugar de un bloqueo. Cloudflare no lo tomó como un ataque exitoso: conservó el caso para investigarlo. Esa disciplina es lo que separa un experimento útil de una lista de falsas alarmas.

La validación humana fue el último filtro. Los revisores comprobaban si la petición llegó realmente al objetivo, si seguía siendo maliciosa, si estaba claramente sin bloquear, si era responsabilidad del WAF y si podía reproducirse con seguridad. Solo entonces se evaluaba si el caso exigía cambios en reglas, normalización u otras mitigaciones.

Cloudflare no está solo. InfoQ recuerda que Google Mandiant encadena agentes especializados (análisis de código, hipótesis, verificación) antes de que los hallazgos lleguen a una persona. Codex Security de OpenAI modela amenazas de un repositorio y reproduce candidatos en un entorno aislado. PageBreak, de Google, se centra en comprobar si las hipótesis generadas por IA son realmente explotables, para que los equipos no se ahoguen en hallazgos plausibles pero no verificados. Como resume uno de los análisis consultados, el valor no está en reemplazar al analista humano, sino en descubrir más rápido las brechas entre reglas estáticas y comportamiento real de los atacantes.

Qué puedes aplicar en tu empresa

No necesitas ser Cloudflare para adoptar este patrón. Estas son las lecciones transferibles:

Parte de lo que ya sabes que funciona. Usa incidentes y ataques bloqueados como semillas. Es más barato y rentable que pedir a un modelo que invente amenazas desde cero.

Construye el harness antes de elegir el modelo. Límites de ejecución, estado, registro de resultados y entornos aislados son la parte que no debes delegar a la IA.

Separa descubrimiento y validación. Un modelo propone, otro (o una persona) verifica. Sin esa separación, tu equipo de seguridad heredará ruido.

Define criterios de triage por escrito. Los de Cloudflare son un buen punto de partida: ¿llegó al objetivo?, ¿sigue siendo malicioso?, ¿es reproducible?, ¿es competencia de esta capa de defensa?

Mide con métricas realistas. Aquí, menos del 5% de los intentos acabó en hallazgo, y aun así el ejercicio tuvo impacto en producción. Evalúa el retorno por mejora de reglas, no por volumen de pruebas.

Empieza por categorías acotadas. Con 48 de 49 hallazgos en SSRF e inyección de comandos, queda claro que enfocarse en pocas clases de vulnerabilidad rinde más que cubrir todo a la vez.

El error a evitar es confiar en la salida bruta de la IA. En nuestra cobertura de una auditoría de código con IA que alcanzó solo un 20% de precisión se ve cómo la falta de verificación convierte la promesa en ruido. Si además ya despliegas agentes en tus pipelines, conviene revisar la arquitectura de seguridad multicapa que GitHub aplica a agentes de IA en CI/CD, y comparar el enfoque de Cloudflare con el de OpenAI Codex Security y sus miles de vulnerabilidades analizadas.

El momento de actuar

Las reglas estáticas envejecen en cuanto los atacantes encuentran una nueva codificación o una nueva ruta, y ellos ya usan IA para explorarlas. El caso de Cloudflare demuestra que las pruebas de seguridad con IA son viables hoy, siempre que el modelo opere dentro de un harness controlado y que cada hallazgo pase por un filtro humano. La pregunta para tu equipo no es si automatizar la búsqueda de debilidades en tus defensas, sino quién va a encontrarlas primero: tu harness o un atacante.