Skill de Auditoria de Segurança da Cloudflare Transforma a Revisão de Código por IA em um Fluxo de Trabalho Adversarial
A Cloudflare lançou um fluxo de trabalho de auditoria de código com IA em seis fases, mas o skill de auditoria de segurança da Cloudflare não é apenas outro prompt que pede a um modelo para encontrar bugs. Ele atribui agentes separados para mapear o código, caçar vulnerabilidades, contestar descobertas e verificar as evidências que sobrevivem.
Essa distinção importa porque relatórios de segurança gerados por IA frequentemente contêm alegações plausíveis sem um caminho de ataque válido. O projeto da Cloudflare trata cada vulnerabilidade proposta como uma alegação que outro agente deve tentar refutar. Ele também registra o que a auditoria cobriu, tornando análises ausentes mais visíveis.
O lançamento de código aberto reúne ideias que a Cloudflare desenvolveu ao construir uma infraestrutura interna de vulnerabilidades muito maior. O skill público é direcionado a um repositório e uma execução de auditoria. Já o sistema interno da Cloudflare mantém resultados entre repositórios, rastreia dependências e gerencia milhares de descobertas.
Isso cria a tensão central em torno do lançamento. Um skill reutilizável reduz a barreira para revisões estruturadas de código com IA, mas não consegue reproduzir sozinho a infraestrutura interna da Cloudflare. Desenvolvedores obtêm um ponto de partida mais sólido, não um substituto autônomo para engenheiros de segurança.
O Que o Skill de Auditoria de Segurança da Cloudflare Realmente Muda
A Cloudflare está transformando a revisão de segurança por IA de uma conversa em um processo que produz evidências, com cobertura explícita e etapas de verificação.
O repositório público do skill de auditoria descreve um fluxo de trabalho criado para agentes de programação que oferecem suporte a ferramentas e subagentes isolados. Ele é licenciado sob a MIT License e pode ser instalado pela interface de linha de comando Skills.
O skill de auditoria de segurança da Cloudflare divide uma auditoria em seis fases. O reconhecimento mapeia a arquitetura de software, os limites de confiança, as superfícies de entrada e as evidências disponíveis. O processo registra esse mapa em um documento de arquitetura e em um registro de cobertura legível por máquina.
Em seguida vem a busca guiada pela cobertura. O agente principal atribui caçadores isolados a áreas e classes de ataque definidas. Cada caçador registra o que verificou, em vez de retornar apenas uma lista de problemas suspeitos.
Esse registro é importante porque um relatório curto pode, de outra forma, criar uma falsa sensação de confiança. Um agente pode inspecionar o código de autenticação, não encontrar nada e sugerir que toda a aplicação parece segura. Um registro de cobertura pode mostrar que parsing, configuração de implantação, tratamento de dependências ou isolamento de tenants receberam pouca atenção.
A validação de candidatos entrega cada pista distinta a um novo verificador. Esse verificador tenta rejeitar a vulnerabilidade proposta ao checar suas suposições, o caminho no código-fonte, o principal afetado e o resultado de segurança. O agente de busca não aprova seu próprio trabalho.
As descobertas sobreviventes seguem então para uma saída estruturada. O skill separa os registros em descobertas confirmadas, problemas que precisam de validação e candidatos rejeitados. Um esquema define os campos obrigatórios, enquanto validadores JavaScript incluídos verificam mecanicamente os arquivos.
As fases finais verificam de forma independente as alegações sobre o código-fonte e geram relatórios neutros em relação ao alvo. Mudanças materiais em uma descoberta acionam outra etapa de verificação. Esse projeto busca impedir que quem redige um relatório fortaleça discretamente uma alegação fraca durante a síntese.
O resultado difere de uma auditoria comum de segurança de código por IA em um aspecto crucial. A entrega inclui um relato das superfícies examinadas, ideias rejeitadas, fatos não resolvidos e descobertas verificadas de forma independente. Um relatório aparentemente limpo deixa de ser o único artefato.
A Cloudflare também define um limite rigoroso de execução. Builds, testes, fuzzers, navegadores e fixtures controladas pelo alvo exigem um sandbox do sistema operacional sem acesso à rede externa. Sem esses controles, o fluxo de trabalho precisa manter uma pista como não verificada, em vez de executar código não confiável.
Essa restrição torna o lançamento menos conveniente do que um prompt de auditoria de uma linha. Ela também reflete um problema real de segurança. O código sob revisão pode conter instruções ou comportamentos de build que atacam o próprio ambiente de auditoria.
Por Que a Cloudflare Criou um Skill Antes de uma Infraestrutura para Toda a Frota
O skill público é valioso porque captura o método de auditoria da Cloudflare, ao mesmo tempo que revela por que uma única sessão de agente atinge um limite operacional.
A Cloudflare afirma que o projeto começou como um skill de segurança de aproximadamente 450 linhas para um único repositório. Os engenheiros refinaram seus prompts até que ele encontrasse bugs úteis e, então, levaram seus cenários e regras de validação para um sistema maior.
A empresa detalhou essa evolução em sua publicação de engenharia sobre a infraestrutura de vulnerabilidades. A primeira versão usava três agentes de pesquisa para reconhecimento, caçadores separados para classes de ataque, validadores adversariais, descobertas estruturadas e verificação independente do código-fonte.
A Cloudflare identificou três limites durante essas execuções iniciais. Sessões longas esgotavam o contexto do modelo, execuções interrompidas perdiam o progresso, e revisões de um único repositório deixavam de identificar relações com serviços consumidores.
Essas falhas não eram simplesmente problemas de qualidade do modelo. Eram problemas de gerenciamento de estado.
Um modelo pode raciocinar sobre o código atualmente em seu contexto, mas uma grande auditoria produz muitas hipóteses paralelas. Cada hipótese envolve arquivos, limites de confiança, suposições, experimentos, contra-argumentos e mudanças de status. Comprimir esse histórico em um resumo de conversa pode descartar detalhes decisivos.
A Cloudflare respondeu externalizando o estado. Sua infraestrutura posterior trata modelos de linguagem como trabalhadores substituíveis e mantém informações duráveis da auditoria fora de suas janelas de contexto. Um banco de dados armazena a execução, o repositório e a etapa de cada tarefa.
A distinção explica por que a Cloudflare lançou o ponto de partida em vez de apresentá-lo como o sistema interno concluído. Um skill pode codificar uma sequência rigorosa dentro de um ambiente de programação. Ele não pode fornecer automaticamente inventário de frota, filas duráveis, grafos de dependência ou telemetria de produção.
A Cloudflare relata que a transição de seu primeiro skill para um sistema que abrange 128 repositórios levou cerca de seis semanas. Esse sistema interno funciona em Rust, Go, C, Lua, TypeScript, Python e formatos de configuração sem orquestração específica por linguagem.
Seu fluxo de trabalho maior separa descoberta de validação. A Vulnerability Discovery Harness mapeia e caça possíveis fraquezas. Um Vulnerability Validation System diferente elimina duplicatas, verifica a relevância em produção e gerencia a correção.
A Cloudflare afirma que usa modelos diferentes nessas duas etapas. Essa escolha reduz a dependência dos padrões recorrentes de raciocínio de um único modelo. Ela também permite que a empresa troque de provedores sem redesenhar o processo de segurança em torno de um modelo específico.
Essa posição neutra em relação a modelos pressiona fornecedores que apresentam o desempenho em benchmarks como a principal medida de um produto de segurança por IA. O argumento da Cloudflare é que orquestração, evidências e rejeição independente determinam se a saída de um modelo se torna trabalho de engenharia útil.
A empresa não afirma que o skill recria seu pipeline de produção. Suas próprias orientações dizem que as equipes devem começar com reconhecimento, busca e validação. O rastreamento entre repositórios e a eliminação de duplicatas dedicada tornam-se úteis apenas depois que o volume de auditorias cria esses problemas.
Esse sequenciamento oferece às equipes menores um ponto de entrada prático. Elas podem testar se os prompts e as regras de evidência funcionam em seu código antes de construir uma infraestrutura cara ao redor deles.
Ele também impede que o lançamento público se torne uma demonstração de produto enganosa. O repositório oferece o método que originou o sistema da Cloudflare, não o sistema completo que agora opera em toda a sua frota.
O Verdadeiro Oponente É a Revisão Pontual de Código por IA
A infraestrutura de vulnerabilidades da Cloudflare questiona a suposição de que um único modelo capaz pode inspecionar um repositório, identificar falhas reais e avaliar com confiança suas próprias conclusões.
Uma revisão pontual geralmente segue um padrão conhecido. O desenvolvedor dá a um agente de programação acesso a um repositório e pede que ele encontre vulnerabilidades de segurança. O agente lê arquivos selecionados, identifica padrões suspeitos e redige um relatório bem acabado.
Esse processo pode produzir pistas úteis. Também pode ocultar três falhas distintas.
Primeiro, o modelo escolhe o que inspecionar sem preservar um registro durável do que pulou. Segundo, o mesmo processo de raciocínio gera e avalia cada alegação. Terceiro, uma linguagem persuasiva pode fazer evidências incompletas parecerem definitivas.
O fluxo de trabalho da Cloudflare ataca cada falha separadamente. O registro de cobertura documenta a superfície de auditoria pretendida. Caçadores independentes examinam unidades delimitadas. Novos validadores tentam refutar candidatos, em vez de melhorar sua apresentação.
Essa divisão adversarial é mais importante do que simplesmente adicionar mais agentes. Dez agentes compartilhando as mesmas suposições podem gerar dez versões do mesmo falso positivo. A Cloudflare atribui papéis diferentes e concede aos validadores autoridade para rejeitar a teoria de um caçador.
O skill também exige uma falha concreta de limite. Um problema confirmado precisa incluir um principal afetado, um recurso ou um resultado de segurança. A ausência de uma boa prática não se transforma automaticamente em uma vulnerabilidade.
Essa distinção filtra descobertas como comportamentos irrestritos disponíveis apenas para um administrador já confiável. Ela também rejeita relatórios que descrevem uma defesa ausente sem mostrar como um atacante atravessa um limite real.
O processo interno da Cloudflare usa requisitos de prova mais fortes. Uma descoberta confirmada deve incluir um teste reproduzível contra a base de código original. O teste não pode depender de mudanças no código-fonte introduzidas pelo agente de busca.
Essa regra aborda um modo de falha especialmente perigoso. Um agente pode modificar o código enquanto experimenta e, então, demonstrar um exploit contra a versão modificada. Sem controles de estado do código-fonte, o relatório resultante pode atribuir à aplicação uma falha criada pelo próprio agente.
A validação mecânica adiciona outra camada. Verificações comuns de código confirmam se arquivos, caminhos, patches e testes citados existem ou são analisados corretamente. O modelo de linguagem não decide se sua própria saída satisfaz esses requisitos estruturais básicos.
A Cloudflare afirma que uma única execução do skill encontrou aproximadamente metade das vulnerabilidades que execuções repetidas acabaram descobrindo. Essa é uma observação relatada pela empresa, não uma taxa de recall medida de forma independente.
Ainda assim, o resultado sustenta a escolha central de design do lançamento. Uma execução concluída não estabelece cobertura completa, mesmo quando todas as descobertas relatadas são válidas.
Portanto, uma auditoria rigorosa de segurança de código por IA precisa de duas declarações distintas de confiança. Uma diz respeito à validade de cada descoberta. A outra diz respeito à profundidade com que a auditoria buscou por descobertas.
O skill de auditoria de segurança da Cloudflare expõe ambas as questões. Seus vereditos confirmados, não resolvidos e rejeitados descrevem a confiança nas evidências. Seu registro de cobertura descreve o processo de busca.
A análise estática tradicional continua relevante nesse modelo. Scanners determinísticos se destacam em padrões conhecidos, regras de fluxo de dados e verificações repetíveis. Um agente pode explorar suposições de confiança específicas da aplicação ou combinar fraquezas em lógicas desconhecidas.
A experiência interna da Cloudflare também oferece um alerta sobre preferências presumidas de ferramentas. A empresa afirma que seus caçadores não invocaram um caminho integrado do Semgrep durante um mês de execuções. Eles preferiam ler e executar código, enquanto frequentemente solicitavam ambientes ou fixtures ausentes.
Essa observação não mostra que a análise estática não tem valor. Ela mostra que instalar uma ferramenta não garante que um agente a usará de forma eficaz. As equipes precisam medir o comportamento real das ferramentas dentro de seu fluxo de trabalho.
A competição, portanto, não é entre IA e scanners convencionais. É entre a saída não estruturada de modelos e um processo de auditoria que combina verificações determinísticas, exploração especializada e validação adversarial.
Descobertas Estruturadas Reduzem o Ruído, mas Não Comprovam Segurança
A parte mais forte do lançamento é sua recusa em tratar uma saída plausível de modelo como evidência confirmada, mas essa disciplina não consegue medir vulnerabilidades ainda não descobertas.
A Cloudflare informa que seu ambiente interno de descoberta gerou 20.799 candidatos brutos. Cerca de 12.057 passaram pela etapa inicial de validação antes de entrar em um grupo maior de validação.
Depois que as descobertas de outro ambiente foram incorporadas ao sistema, o grupo central continha 13.841 registros. A desduplicação removeu 5.442, enquanto 1.154 foram redirecionados por serem casos de repositório incorreto ou de baixo risco. A Cloudflare afirma que restaram 7.245 descobertas acionáveis para as equipes de engenharia.
Esses números são úteis porque mostram o quanto de filtragem existe entre a geração e a correção. Eles não devem ser interpretados como uma referência independente de precisão de detecção.
A Cloudflare seleciona seus próprios repositórios, modelos, prompts, classes de ataque e definições. Os números publicados descrevem seu pipeline operacional. Eles não estabelecem como a skill pública se comporta em uma base de código não relacionada.
A empresa evita explicitamente afirmar uma taxa de falsos negativos. Um repositório real não possui um conjunto completo de rótulos contendo todas as vulnerabilidades, portanto a cobertura não pode ser calculada diretamente. Execuções repetidas que continuam encontrando bugs mostram uma cobertura incompleta, mas não o tamanho da lacuna restante.
Essa incerteza deve estar no centro de qualquer avaliação. Um relatório verificado pode estabelecer que várias descobertas são reais. Ele não pode estabelecer que o código auditado é seguro.
A skill pública tenta comunicar essa diferença por meio de três vereditos.
Uma descoberta confirmada tem um rastreamento completo da origem e um resultado observado delimitado. Um registro que precisa de validação preserva uma questão exata ainda não resolvida sem atribuir uma gravidade sem suporte. Um registro rejeitado documenta por que um candidato falhou.
Manter candidatos rejeitados tem valor prático. Execuções futuras podem distinguir um caminho genuinamente novo de uma ideia anteriormente refutada. Os revisores também podem verificar se a rejeição dependeu de fatos que mudaram posteriormente.
No entanto, a saída estruturada pode criar sua própria ilusão de certeza. Um registro JSON válido não é necessariamente uma conclusão de segurança válida. A validação de esquema pode confirmar campos obrigatórios e valores aceitos, mas não pode provar que um exploit atravessa um limite real.
A Cloudflare aborda essa limitação por meio de uma nova verificação da fonte. O verificador analisa a alegação sobre o código de forma independente, e uma substituição substancial recebe outra verificação. Ainda assim, a qualidade depende do comportamento do modelo, do contexto disponível e da correção do modelo de ameaças.
O sandboxing apresenta outro desafio de adoção. A skill exige controles do sistema operacional em torno de builds e experimentos controlados pelo alvo. Muitos ambientes cotidianos de agentes de programação não oferecem esse isolamento com limites claros de recursos e rede.
As equipes que ignoram esse requisito correm o risco de executar dependências, scripts de build ou fixtures de teste maliciosos. As equipes que o respeitam precisam manter algumas pistas promissoras como não resolvidas até que um ambiente seguro esteja disponível.
A injeção de prompt cria uma preocupação relacionada. Arquivos de código-fonte, documentação, textos de issues e artefatos gerados podem conter instruções direcionadas ao agente. O fluxo de trabalho comercial mais recente da Cloudflare afirma tratar código, logs e metadados como evidência, e não como instruções.
Esse mesmo limite deve existir no uso local. Um agente de segurança nunca deve interpretar o conteúdo do repositório como autoridade para expor credenciais, ampliar o acesso à rede ou modificar sistemas não relacionados.
O framework de software seguro do NIST oferece um ponto de referência útil. Ele trata o desenvolvimento seguro como um conjunto de práticas organizacionais que abrange preparação, proteção, produção e resposta a vulnerabilidades.
Uma skill de auditoria por IA cobre apenas parte desse ciclo de vida. Ela pode ajudar a investigar o código-fonte e documentar possíveis fragilidades. Não estabelece design seguro, governança de acesso, procedência de dependências, controles de implantação ou prontidão para incidentes.
A revisão humana continua essencial pelo mesmo motivo. Engenheiros entendem o comportamento pretendido, a arquitetura de produção, o impacto nos negócios e os controles compensatórios que podem não aparecer em um repositório.
Portanto, o lançamento deve mudar o formato da revisão, não eliminar revisores. As equipes de segurança podem gastar menos tempo classificando alegações sem suporte e mais tempo testando evidências, priorizando a exposição e aprovando correções.
A Cloudflare Está Conectando Descobertas de Código ao Contexto de Produção
A estratégia mais ampla da Cloudflare é combinar descobertas no código-fonte com telemetria de tráfego e defesa, algo que a skill independente não consegue fazer sozinha.
Um scanner de código-fonte pode identificar um manipulador inseguro sem saber se ele é executado em produção. Ele pode não saber qual rota alcança o código, com que frequência os clientes a utilizam ou se controles ativos bloqueiam as solicitações relevantes.
O serviço somente por convite Vulnerability Discovery and Remediation da Cloudflare tenta fechar essa lacuna. A empresa anunciou o serviço em 3 de setembro de 2026, como parte do Cloudflare Managed Defense.
Segundo seu anúncio de remediação orientada por contexto, o serviço conecta análises autorizadas de código ao Web Assets, a dados do Web Application Firewall e à observabilidade de Workers.
O serviço usa modelos OpenAI Daybreak, incluindo GPT-5.6 Cyber, para reconhecimento, investigação e validação. A Cloudflare afirma que os prompts passam pelo AI Gateway até os servidores da OpenAI. A inferência dos modelos não é executada na edge da Cloudflare.
Essa implementação ilustra por que a skill de código aberto e o serviço comercial desempenham funções diferentes. A skill organiza uma investigação no nível do repositório. O serviço acrescenta informações sobre rotas implantadas, volume de solicitações, eventos de segurança e controles existentes.
O contexto de produção pode mudar a prioridade sem alterar a validade técnica. Uma vulnerabilidade real em um caminho de desenvolvimento inacessível merece tratamento diferente da mesma falha em um endpoint público muito utilizado.
A Cloudflare afirma que seu processo pode propor um patch de código e uma regra de WAF de escopo restrito quando as evidências sustentam ambos. A regra de edge pode reduzir a exposição enquanto os engenheiros revisam a alteração permanente no código.
O serviço não permite que o modelo implante sua própria proposta. As chamadas de ferramentas são registradas e avaliadas segundo uma política de acesso. Verificações externas testam patches e regras, enquanto os clientes decidem se as alterações serão implementadas.
Essa abordagem transforma o ambiente de vulnerabilidades da Cloudflare em mais do que um mecanismo de descoberta. Ele se torna parte de um sistema de gestão de exposição que conecta evidências no código-fonte, contexto de execução, mitigação e remediação.
Essa estratégia também explica a ênfase da empresa em relatórios neutros em relação ao alvo. O mesmo método de auditoria pode inspecionar diferentes linguagens e tipos de aplicação, enquanto sistemas específicos de produção fornecem o contexto necessário para a priorização.
A maioria das equipes que usam a skill pública não terá visibilidade de rede equivalente. Elas ainda podem melhorar suas decisões fornecendo manifestos de implantação, mapas de rotas, registros de propriedade e logs sanitizados como evidência controlada.
Elas devem manter a procedência clara. Uma descoberta no código-fonte, uma afirmação de implantação e uma observação de tráfego são alegações diferentes. Combiná-las em um único parágrafo não deve apagar a origem de cada fato.
É aqui que o tratamento disciplinado do conhecimento importa. As equipes de engenharia precisam de um registro pesquisável que conecte decisões de arquitetura, evidências de auditoria, hipóteses rejeitadas e correções posteriores. Uma base de conhecimento técnico mantida pode manter esses registros disponíveis além de uma sessão de agente.
A skill pública já avança nessa direção por meio de artefatos persistentes. Notas de arquitetura, registros de cobertura, descobertas legíveis por máquina e relatórios humanos oferecem aos futuros revisores algo mais duradouro do que uma transcrição de chat.
Ainda assim, um repositório continua sendo uma imagem incompleta. Política de infraestrutura, gestão de segredos, configuração de autorização, dependências de serviços e comportamento dos usuários podem determinar se uma fragilidade no nível do código-fonte se torna explorável.
As equipes com maior probabilidade de se beneficiar tratarão a skill como um gerador de evidências dentro de um programa de segurança mais amplo. As equipes com maior probabilidade de enfrentar dificuldades esperarão que uma varredura de repositório responda a questões de risco de produção que o repositório não contém.
Três Sinais Mostrarão se o Lançamento Importa
O próximo teste é verificar se os desenvolvedores conseguem reproduzir a disciplina da Cloudflare sem a infraestrutura privada, os dados e a equipe de segurança da Cloudflare.
O primeiro sinal é a qualidade dos artefatos de auditoria públicos. Uma adoção útil produzirá relatórios com limites de confiança precisos, evidências reproduzíveis, candidatos rejeitados relevantes e questões não resolvidas apresentadas com honestidade.
Um aumento no número de instalações mostraria interesse, mas não eficácia. A melhor medida é verificar se equipes independentes publicam auditorias cujas descobertas confirmadas resistem à revisão dos mantenedores.
O design atual do lançamento apoia essa avaliação. Seus esquemas de cobertura e descobertas criam artefatos comparáveis, enquanto validadores podem detectar registros malformados antes do início da revisão humana.
O segundo sinal é como o repositório evolui após o uso real. O ambiente interno da Cloudflare aprendeu com execuções repetidas, ambientes ausentes, cobertura superficial e descobertas rejeitadas. A skill pública enfrentará uma gama mais ampla de linguagens, sistemas de build e plataformas de agentes.
Observe mudanças nas orientações sobre classes de ataque, requisitos de sandbox, modelagem de cobertura e tratamento de falsos positivos. Essas atualizações revelarão quais partes do processo da Cloudflare são transferidas com facilidade e quais dependem de sistemas internos.
A distinção entre descobertas confirmadas e descobertas que precisam de validação merece atenção especial. Se usuários externos promoverem regularmente pistas não resolvidas a relatórios confiantes, as salvaguardas do fluxo de trabalho existirão apenas no papel.
O terceiro sinal é se outras plataformas de segurança adotam uma verificação igualmente independente. As ferramentas de código com IA já competem em velocidade, contagem de problemas e assistência à remediação. A Cloudflare está deslocando a atenção para a linhagem das evidências, taxas de rejeição e contabilização da cobertura.
Essa mudança fortaleceria o impacto mais amplo da skill de auditoria de segurança da Cloudflare, mesmo que os desenvolvedores nunca instalem este pacote específico. Um mercado que pergunta quem verificou uma descoberta é mais saudável do que um que recompensa a maior contagem de alertas.
Os resultados internos da Cloudflare sugerem por que isso importa. Milhares de candidatos brutos desapareceram durante a validação, a desduplicação e o julgamento contextual. Gerar mais candidatos não era a capacidade escassa. Convertê-los em trabalho confiável era.
Também há sinais práticos dentro de organizações individuais. Líderes de segurança devem acompanhar quantas descobertas sobrevivem à revisão independente, quanto a cobertura cresce em execuções repetidas e quantos patches passam em testes de regressão.
Eles também devem registrar o custo da auditoria e o tempo decorrido. A Cloudflare afirma que suas varreduras internas completas podem levar horas, com sua execução mais longa ultrapassando 14 horas. A skill pública pode consumir tempo significativo de modelo à medida que investigadores e verificadores examinam áreas separadas.
Essa despesa pode ser justificada para repositórios sensíveis ou revisões aprofundadas periódicas. Talvez não seja adequada para todos os pull requests. Verificações menores, regras determinísticas e análises de ameaças focadas continuam sendo mais indicadas para feedback rápido.
A decisão importante não é substituir os scanners existentes por uma skill de agente. É identificar onde uma auditoria de agente orientada por evidências adiciona informações que os controles atuais não detectam.
Os desenvolvedores podem começar com um repositório delimitado e uma fronteira de confiança claramente definida. Eles devem inspecionar o registro de cobertura antes de ler o relatório final e, em seguida, contestar cada problema confirmado em relação ao código-fonte inalterado.
Devem preservar os registros não resolvidos em vez de forçar um veredito. Devem executar testes apenas dentro de um sandbox apropriado e manter as decisões de remediação sob controle humano.
Se esse processo produzir descobertas reproduzíveis que os mantenedores aceitem, a Cloudflare terá lançado um método de segurança significativo. Se os usuários o reduzirem a apenas mais um prompt amplo, suas seis fases acrescentarão complexidade sem gerar confiança.
A skill de auditoria de segurança da Cloudflare, portanto, apresenta um desafio concreto aos fornecedores de segurança de IA e às equipes de engenharia: parem de medir o sucesso pela quantidade de vulnerabilidades que um modelo consegue descrever. Meçam quais alegações sobrevivem à revisão adversarial, quais áreas foram realmente examinadas e quais fatos continuam desconhecidos.
