Cloudflare usa modelos de IA para atacar o próprio WAF e fechar brechas

O que a Cloudflare testou

A Cloudflare colocou modelos de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → de ponta dentro de um harness controlado para atacar o próprio Web Application Firewall (WAF), usando ataques que o firewall já havia bloqueado como ponto de partida para gerar variações novas. Em 45 cenários, o sistema gerou 1.107 tentativas de ataque e, depois da triagem humana, sobraram 49 achados considerados relevantes (InfoQ).

Cada rodada começou com payloads que o WAF da Cloudflare já tinha barrado em produção. Em vez de repetir o mesmo teste várias vezes, as chamadas de modelo propunham mudanças de codificação, posição ou forma de entrega do payload, baseadas na resposta da tentativa anterior. Os modelos não tinham acesso às regras do WAF, ao código-fonte nem a sinais internos de segurança da Cloudflare: do ponto de vista deles, era um teste caixa-preta.

Como o harness controla o que a IA pode fazer

Um harness escrito em Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → fez o trabalho que a Cloudflare não quis delegar aos modelos: montou e reproduziu as requisições HTTP, manteve o estado de cada cenário, impôs limites de execução e coletou as respostas. Uma chamada de modelo propunha a próxima mutação do ataque; outra chamada revisava a resposta recebida, permitindo que as tentativas evoluíssem sem dar aos modelos controle direto sobre a execução das requisições.

Essa separação de papéis é o ponto central do desenho: o modelo decide o que tentar, mas nunca executa nada sozinho. Quem fala HTTP com o alvo é sempre o harness determinístico, com limites e registro de tudo. Pra quem constrói agentes de IA com acesso a sistemas externos em produção, é o mesmo princípio de sandboxing que vale pra qualquer agente autônomo.

O caso do SSRF que expôs o limite do "bloqueado"

Um teste de SSRF (Server-Side Request Forgery) ilustra o loop de refinamento. O modelo testou repetidamente diferentes representações de um endereço de metadados de nuvem, trocando entre forma decimal, octal e outras variações. Uma tentativa usando representação decimal foi bloqueada pelo WAF.

Na tentativa seguinte, o modelo manteve a mesma estrutura de requisição, mas trocou para uma representação com ponto final (trailing-dot) do endereço, e dessa vez o cliente recebeu um redirecionamento em vez de um bloqueio do WAF. A Cloudflare não tratou esse resultado como prova de que o ataque tinha funcionado: guardou o caso para investigação, em vez de descartá-lo ou validá-lo às pressas.

Os números por trás da triagem

Essa cautela aparece de novo na análise agregada. Dos 1.107 ataques gerados, 607 compuseram o conjunto final pós-triagem: 558 bloqueados pelo WAF e 49 classificados como achados relevantes para investigação. Desses 49, 48 envolviam injeção de comando ou SSRF.

Revisores humanos seguiram sendo a etapa final de validação. Eles checaram se a requisição realmente chegou ao alvo, se o payload continuava malicioso, se o bloqueio do WAF de fato não ocorreu, se o caso era de responsabilidade do WAF (e não de outra camada de defesa) e se podia ser reproduzido com segurança.

Em resumo: o harness gera volume e variação de forma automatizada, mas quem decide o que vira mudança de regra continua sendo gente, caso a caso.

O que mudou de fato no Managed Ruleset

O exercício resultou em três mudanças concretas no Managed Ruleset da Cloudflare:

• Duas detecções novas: SSRF - Obfuscated Host e SSRF - Restricted Protocol
• Uma melhoria na regra já existente SSRF - Cloud

São mudanças pequenas em número, mas nascidas de um processo que testou mais de mil variações de ataque de forma automatizada, volume inviável de produzir manualmente no mesmo intervalo de tempo.

Não é só a Cloudflare fazendo isso

O padrão de usar um harness para orquestrar modelos em busca de vulnerabilidades, com validação separada da descoberta, aparece em outras empresas de segurança. O próprio Vulnerability Discovery Harness da Cloudflare separa a descoberta da validação independente. Já o Agentic Vulnerability Discovery Harness do Google Mandiant encadeia agentes especializados por análise de código-fonte, geração de hipótese e verificação, antes de qualquer achado chegar a um revisor humano.

A OpenAI segue lógica parecida com o Codex Security: o sistema constrói um modelo de ameaça para um repositório, procura vulnerabilidades e tenta reproduzir os candidatos em um ambiente isolado antes de propor correções para revisão humana. O PageBreak, do Google, foca em validar se hipóteses de vulnerabilidade geradas por IA são de fato exploráveis, em parte para evitar que times de segurança sejam soterrados por achados plausíveis, mas não verificados.

O fio comum entre todos esses sistemas é o harness ao redor do modelo: ele restringe a execução, preserva o estado, valida os achados e transforma exploração probabilística em evidência que os fluxos de segurança já existentes conseguem usar.

O que isso muda pra quem roda aplicação atrás de um WAF

Pra quem tem aplicação em produção atrás de WAF (Cloudflare ou qualquer outro provedor), o recado prático é duplo. Primeiro, regras de WAF não são estáticas: no caso da Cloudflare, elas agora são atualizadas com base em ataques sintéticos gerados por IA, o que tende a reduzir o tempo entre descoberta de uma variação de ataque e a mitigação chegar ao ruleset.

Segundo, e mais importante: WAF nunca foi, e continua não sendo, suficiente sozinho. O próprio exercício da Cloudflare mostrou que 48 dos 49 achados relevantes envolviam SSRF, uma classe de vulnerabilidade que depende tanto de como a aplicação valida URLs e hosts de saída quanto de como o WAF filtra a entrada. Validar entrada de usuário contra redirecionamento para endereços de metadados de nuvem (como 169.254.169.254 na AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps →, ou equivalentes no GCP e Azure) continua sendo responsabilidade do código da aplicação, não só da camada de borda.

Times que constroem agentes próprios de IA com acesso a sistemas de produção também saem com um desenho de referência: separar o papel que decide (o modelo) do papel que executa (o harness determinístico), manter estado e limites fora do modelo, e nunca tratar uma resposta ambígua do sistema sob teste como prova definitiva sem checagem manual.

Fonte: InfoQ