A Microsoft afirma que o Frontier Offensive Research & Generative Exploitation, conhecido pela sigla FORGE, passou de testar a capacidade da inteligência artificial de encontrar vulnerabilidades difíceis a estudar o que é necessário para transformar essas descobertas em correções prontas para distribuição. Entre maio e setembro de 2026, o laboratório ajudou a descobrir vulnerabilidades no Windows às quais foram atribuídas 140 identidades CVE, das quais 52 foram tratadas nas atualizações de segurança de setembro de 2026.
O trabalho também se estendeu ao software de código aberto; as equipes do FORGE apresentaram cerca de 155 relatórios verificados internamente em 23 projetos, incluindo o kernel do Linux. Segundo a Microsoft, 93 relatórios em 14 projetos ou famílias de projetos receberam reconhecimento ou aceitação documentada dos mantenedores no momento da preparação do material. Além disso, um dos relatórios do Linux apresentados por meio da iniciativa Akrites da Linux Foundation tornou-se o primeiro relatório da iniciativa a resultar na integração de uma correção no kernel do Linux.
Da capacidade máxima à operação em larga escala
A primeira lição é que o sucesso de um modelo em encontrar uma falha complexa não garante a produção de correções em ritmo semelhante. Aumentar o número de verificadores pode elevar o número de candidatos, mas não necessariamente aumenta o número de resultados confirmados ou correções publicadas. Se os relatórios chegarem mais rápido do que a capacidade do Microsoft Security Response Center de analisá-los, uma fila se acumula e consome o tempo dos especialistas, especialmente quando os relatórios se repetem ou não têm evidências reproduzíveis.
Por isso, o FORGE se concentra em um resultado reproduzível, e não apenas no número de verificações ou relatórios. O laboratório usa a plataforma multimodelo MDASH para organizar o trabalho, além de geradores de provas de explorabilidade ou provas de conceito, construção de ferramentas de teste e busca por entradas que levem ao comportamento defeituoso. A Microsoft afirma que um projeto interno baseado em algoritmos determinísticos, como a análise da árvore sintática abstrata, reduziu os relatórios duplicados em cerca de 45% em várias verificações do mesmo código.
Gastar na remoção da incerteza, não no aumento de texto
A Microsoft considera que medir a eficiência apenas pelo número de tokens produzidos pelo modelo leva a um critério enganoso. Um relatório curto pode ser ambíguo e caro de investigar, enquanto uma análise mais longa pode justificar o caminho de execução e reduzir o custo total. A decisão prática é determinar o que falta ao investigador: o chamador da função, a configuração de compilação, o reprodutor executável ou a explicação causal; em seguida, a próxima etapa deve ser direcionada especificamente para preencher essa lacuna.
O MDASH combina modelos avançados e outros destilados, verificadores especializados e ferramentas de análise de código, com a possibilidade de direcionar tarefas rotineiras para modelos menos dispendiosos e escalar questões não resolvidas para modelos mais potentes. No entanto, a Microsoft ressalta que essa política ainda é uma hipótese que precisa ser medida, pois a filtragem antecipada pode excluir vulnerabilidades reais.
Validação e correção como um ciclo contínuo de aprendizado
De acordo com a proposta, a validação e a correção não devem ser tratadas como uma etapa posterior à descoberta da vulnerabilidade. Cada resultado deve passar por validação automatizada, revisão humana, desenvolvimento da correção e testes de regressão, com o retorno das evidências de cada etapa ao sistema. Até mesmo uma falha na validação pode ser útil se registrar o motivo da falha, como a inacessibilidade do caminho, uma configuração de compilação incorreta, a ausência de controle do invasor sobre as entradas ou a duplicidade do relatório.
Em um experimento com o kernel do Linux, os agentes de validação produziram evidências de apoio para 627 resultados, enquanto o custo médio de criação de uma prova de conceito para 182 resultados confirmados de falha foi de 3,61 dólares em custo do modelo e 21,5 minutos por caso bem-sucedido. Em seis casos nos quais a possibilidade de escalada local de privilégios foi testada por meio da geração automatizada de exploração, a média foi de 8,56 dólares e 25,4 minutos. As avaliações utilizaram o GPT-5.5 e não incluíram os custos da verificação inicial, dos casos malsucedidos nem da investigação humana e da preparação das correções.
O que isso significa para as equipes de segurança?
A principal conclusão desses resultados é que a métrica de sucesso dos sistemas agênticos de descoberta de vulnerabilidades não deve se limitar ao número de resultados. A Microsoft sugere acompanhar o número de falhas confirmadas, os relatórios duplicados e rejeitados, a idade da fila, o tempo entre a descoberta e a correção, além do custo dos modelos e do tempo de revisão humana. O trabalho em projetos de código aberto também exige respeitar os processos de cada projeto para divulgação, revisão e correção, e não apenas enviar mais relatórios.
Na prática, a fonte identifica uma mudança no gargalo: a capacidade de encontrar a falha tornou-se apenas parte do problema, enquanto ganha importância conectar a pesquisa a ambientes de compilação, arquivos binários, configurações, ferramentas de teste e sistemas de CI/CD. Os limites dos resultados permanecem claros; os números relativos ao custo da validação excluem etapas humanas importantes, e a transformação dos resultados da pesquisa em uma correção aceita depende dos mantenedores e do contexto de cada projeto. Portanto, o material não demonstra que a automação substitui a revisão de engenharia, mas a apresenta como um meio de reduzir o trabalho repetitivo, mantendo nos humanos a responsabilidade pelo julgamento de segurança e pela correção.