Palo Alto Networks anuncia testes ofensivos contínuos com IA: o que se sabe e o que ainda falta demonstrar

Um serviço anual para buscar e validar vulnerabilidades

Em 22 de setembro de 2026, a Palo Alto Networks anunciou o Unit 42 Continuous Frontier AI Defense, um serviço por assinatura anual que, segundo a empresa, combina especialistas em segurança e inteligência artificial para buscar vulnerabilidades continuamente, verificar se elas podem ser exploradas e acelerar sua correção. O anúncio descreve uma proposta de testes ofensivos assistidos por IA, não uma avaliação independente de sua eficácia.

A ficha do fornecedor enumera funções de descoberta contínua, validação da possibilidade de exploração e recomendações para corrigir problemas. Também menciona patches virtuais e alterações de código. O fato de o serviço poder gerar ou recomendar uma medida não significa, por si só, que ela será aplicada em produção: os materiais disponíveis não especificam suficientemente quais alterações são executadas automaticamente e quais exigem validação ou aprovação do cliente.

A proposta pode interessar a equipes que precisam revisar com frequência sistemas expostos ou complexos. Mas a decisão de contratar não deve se basear apenas no fato de a busca ser “contínua” ou contar com modelos avançados. Também importam os ativos incluídos, as condições dos testes, a qualidade das evidências entregues e o controle sobre qualquer ação que possa modificar ou afetar um sistema.

Um mecanismo multimodelo e participação humana

A empresa menciona Claude Mythos 5, GPT-5.6-Cyber e modelos de pesos abertos entre os sistemas que podem participar. Segundo o anúncio, um mecanismo próprio encaminha tarefas entre modelos; especialistas em segurança da Unit 42 também fazem parte do serviço. A ideia é distribuir o trabalho, em vez de confiar toda a busca a um único modelo.

A expressão “mecanismo multimodelo” descreve uma camada que coordena o uso de modelos diferentes, mas não basta para explicar como as decisões são tomadas. Para avaliar o processo, um possível cliente precisaria saber quais tarefas são atribuídas a cada modelo, como resultados repetidos são consolidados, quem revisa descobertas duvidosas e quais evidências o serviço conserva para justificar que uma vulnerabilidade existe e pode ser explorada.

Também é importante distinguir a participação humana da supervisão efetiva. O fato de haver especialistas envolvidos não esclarece em que etapa eles revisam os resultados, se autorizam cada teste ativo ou se sua intervenção se limita a determinadas fases. Essa diferença pode alterar tanto o risco operacional quanto a responsabilidade pelas decisões.

Dois números chamativos, ainda atribuídos ao fornecedor

A Palo Alto Networks afirma que, em seus testes em ambientes complexos, nenhum modelo individual detectou mais de 40% das vulnerabilidades. Também diz que Claude Mythos 5 e GPT-5.6-Cyber coincidiram em menos de 10% das exposições que identificaram. Esses números apontam para uma possível complementaridade entre modelos, mas são resultados comunicados pela empresa, não uma medição independente do serviço.

O percentual abaixo de 40% não permite avaliar a cobertura sem saber o que foi contado como vulnerabilidade, quantas havia no total e como os ambientes foram selecionados. Também não informa, por si só, a quantidade de falsos positivos: um modelo poderia apontar poucos problemas e acertar em todos, ou produzir muitas descobertas que depois não fossem confirmadas. Sem denominadores e critérios de validação, o número não basta para comparar modelos nem para estimar o desempenho na infraestrutura de uma organização específica.

Da mesma forma, uma sobreposição inferior a 10% não significa automaticamente que os modelos descobriram vulnerabilidades únicas e corretas nessa proporção. Seria preciso saber como uma coincidência foi definida, se duplicatas foram eliminadas, como foram agrupadas descobertas que descrevem o mesmo defeito e se os dois modelos receberam as mesmas tarefas e condições. Também é relevante distinguir “exposições identificadas” de vulnerabilidades confirmadas.

A reportagem da Axios atribui o número de cobertura inferior a 40% a testes realizados pela própria Palo Alto Networks, enquanto o anúncio da empresa apresenta os números de cobertura e sobreposição. O material publicado consultado não fornece um protocolo reproduzível, conjuntos de teste completos nem resultados detalhados que permitam verificar esses percentuais externamente. Portanto, eles devem ser entendidos como afirmações do fornecedor.

Descobrir, explorar, priorizar e corrigir são coisas diferentes

Em um teste ofensivo, buscar um indício de vulnerabilidade e verificar se ele pode ser explorado são etapas distintas. Um scanner pode apontar uma configuração ou um componente suspeito; uma validação ativa tenta determinar se a falha tem consequências práticas. Essa segunda etapa pode fornecer evidências mais concretas, mas exige limites claros: alguns testes podem alterar dados, degradar um serviço ou interagir com sistemas de terceiros se o escopo não estiver bem definido.

A priorização também não equivale à correção. Ordenar as descobertas ajuda a decidir o que analisar primeiro, mas não elimina o risco. Uma recomendação, um patch virtual ou uma proposta de alteração de código são possíveis respostas; sua inclusão na ficha do serviço não demonstra que tenham sido instalados nem que sejam adequados a cada ambiente. A aplicação efetiva exige testes de compatibilidade, gestão de mudanças e confirmação de que a correção resolveu o problema sem introduzir outros.

É importante distinguir esse tipo de atividade da classificação e resposta a alertas. As operações de detecção e resposta costumam analisar sinais de atividade e gerenciar possíveis incidentes; os testes ofensivos autorizados buscam fragilidades por meio de ações previamente acordadas. Pode haver áreas relacionadas, mas finalidade, permissões e riscos não são intercambiáveis.

Perguntas práticas antes de avaliar o serviço

Antes de contratar um serviço de testes contínuos, os responsáveis pela segurança devem solicitar detalhes sobre o escopo contratual e operacional, assim como fariam para um teste de intrusão. A frequência de execução não substitui a autorização: é preciso identificar os ativos, os horários, os sistemas excluídos, as dependências de terceiros e os contatos que podem interromper um teste.

Também é razoável pedir exemplos de relatórios com dados sensíveis removidos, os critérios para confirmar descobertas, as taxas de falsos positivos e um mecanismo para reproduzir os testes em um ambiente controlado. Se o fornecedor não puder fornecer todos esses dados, deve explicar quais informações consegue entregar, em que condições e quais limitações impedem uma auditoria externa.

No uso de modelos, é necessário perguntar quais dados do cliente são enviados, onde são processados, por quanto tempo são retidos e se são utilizados para treinar ou ajustar modelos. Os materiais consultados descrevem os modelos e as funções anunciadas, mas não esclarecem todas essas questões. Saber apenas os nomes dos modelos também não é suficiente: a configuração, as ferramentas conectadas e as regras de autorização influenciam o que o sistema pode fazer.

O trabalho com patches exige perguntas específicas: trata-se de uma recomendação, de um patch virtual ou de uma alteração de código? Quem verifica a compatibilidade e possíveis regressões? Que aprovação é necessária para aplicá-lo? Como a alteração pode ser revertida se causar problemas? Respostas concretas ajudam a distinguir a análise automatizada da gestão real de mudanças.

O que é possível concluir por enquanto

O anúncio confirma que a Palo Alto Networks oferece um serviço anual da Unit 42 que combina especialistas, um mecanismo multimodelo e funções de descoberta, validação e recomendação de correções. Também registra quais modelos a empresa menciona e quais números de desempenho atribui aos seus testes. A cobertura jornalística acrescenta contexto sobre o anúncio, mas não transforma esses resultados em uma avaliação independente.

Um trabalho de pesquisa disponível no arXiv aborda a avaliação de modelos de linguagem para cibersegurança por meio de testes de vulnerabilidades. Ele é pertinente como contexto para a importância de projetar benchmarks, mas não avalia esse serviço nem confirma os números divulgados pela Palo Alto Networks. Não deve ser apresentado como validação do produto.

A conclusão prudente não é que o serviço não tenha utilidade, nem que suas afirmações sejam falsas: é que as informações públicas consultadas não permitem medir de forma independente sua cobertura, precisão ou segurança operacional. Para tomar uma decisão, cada organização precisa de evidências adequadas ao próprio ambiente, limites de autorização explícitos e clareza sobre a intervenção humana e a aplicação das alterações. Até que sejam publicados resultados auditáveis ou avaliações externas específicas, os números devem continuar atribuídos à empresa.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.