A IA está encontrando as falhas mais rápido

Em 4 de novembro, a OpenAI descreveu uma rodada de agentes de IA contra o kernel do Linux, o software que sustenta celulares Android, infraestrutura de nuvem e supercomputadores. Em cerca de dez dias a partir de meados de outubro, os agentes produziram exploits funcionais para 948 falhas distintas, cada uma capaz de transformar uma conta de usuário comum em controle total de uma máquina, e escreveram um patch candidato para cada uma delas. Uma semana antes, o Google anunciou o Gemini 4 Carbon e o entregou primeiro a defensores cibernéticos verificados. O tempo entre a existência de uma falha e a sua descoberta está encolhendo, e os laboratórios querem que os defensores cheguem lá primeiro.

O que a OpenAI rodou

O pipeline tinha cinco etapas e rodava num modelo de cibersegurança que a OpenAI lançou em 5 de novembro como GPT-6 Cyber. Agentes de reconhecimento escolheram 5'034 partes do kernel que valia a pena auditar, cerca de 7 por cento do código. Agentes analistas as transformaram em 2'308 achados candidatos em 12 horas. Agentes de triagem tentaram reproduzir cada um numa máquina isolada e conseguiram em 1'724 casos, cerca de três quartos, e a OpenAI diz que apenas 3,1 por cento dos achados se baseavam numa análise errada. Etapas posteriores testaram quais falhas podiam ser exploradas e escreveram patches, e pessoas revisaram os resultados antes que qualquer coisa fosse reportada.

A rodada custou 1'213'430 dólares em créditos de API, ou cerca de 1'279 dólares por exploit. Os alvos rodavam um Linux de desktop padrão, com as proteções habituais ativadas. Uma rodada em julho com um modelo anterior, o GPT-5.6 Sol, tinha encontrado 166 falhas desse tipo. O modelo mais novo encontrou mais de cinco vezes mais, embora o kernel tivesse sido reforçado durante os três meses entre uma rodada e outra.

O que os laboratórios dizem sobre os limites

A OpenAI é franca sobre onde errou. Numa das primeiras rodadas, o pipeline reportou 200 exploits bem-sucedidos, e a revisão humana descobriu que 20 deles tinham chegado ao controle total por meio de outra falha desconhecida, diferente da que lhes tinha sido atribuída. “Isso sugere que mesmo a exploração bem-sucedida por agentes precisa de uma validação adequada”, escreveu a OpenAI, que acrescentou uma verificação independente de que cada exploit usou a falha atribuída. A lição vale para qualquer trabalho automatizado: “verificar o caminho até um resultado, além de verificar o próprio resultado.”

Os patches também precisaram de ajustes. Os primeiros funcionavam, mas às vezes acrescentavam código desnecessário, ignoravam as convenções locais ou deixavam passar variantes da mesma falha, até que mais instruções e iterações os melhoraram. A OpenAI chama seus números de custo de “mais um limite superior”. Todos esses números são da própria OpenAI. Até 5 de novembro, não tínhamos encontrado nenhuma auditoria independente deles nem nenhuma declaração pública dos mantenedores do kernel sobre esse lote.

Defensores primeiro

O anúncio do Google em 28 de outubro segue o mesmo padrão. Ele chama o Gemini 4 Carbon de “nosso modelo mais forte, com capacidades de cibersegurança e de longo horizonte de ponta” e informa 88,2 por cento no SEC-bench Pro para encontrar falhas, 54,8 por cento no ExploitGym e 71,0 por cento no CWE-bench para corrigi-las, todos números do próprio Google, medidos sem guardrails. O acesso começa com um subconjunto de defensores cibernéticos e se amplia em fases por meio do Fairwind Program, que, segundo a SecurityWeek, tem mais de 650 participantes, entre eles governos e operadores de infraestrutura crítica. Uma versão para desenvolvedores, empresas e consumidores está prometida “o mais rápido possível”, sem data.

A Anthropic estabeleceu esse padrão com o Mythos em abril, e a OpenAI o segue. O GPT-6 Cyber vai primeiro para um grupo seleto de clientes aprovados do Daybreak Red, o programa da empresa para testes de segurança autorizados, e a OpenAI classifica o modelo no nível Crítico de cibersegurança do seu próprio Preparedness Framework. O anúncio explica por quê: “Está claro que temos uma janela limitada para usar modelos de fronteira para proteger o software.”

O lado dos mantenedores

Cada achado cai nas mãos de alguém que precisa corrigi-lo. Em março, Greg Kroah-Hartman, um mantenedor sênior do kernel, disse ao The Register que os relatórios feitos com IA tinham passado de lixo a genuínos cerca de um mês antes: “Agora temos relatórios de verdade.” Em maio, Linus Torvalds escreveu que “a enxurrada contínua de relatórios de IA basicamente tornou a lista de segurança quase totalmente ingerenciável”, porque muitas pessoas encontram os mesmos bugs com as mesmas ferramentas. O conselho dele a quem reporta: “Se você encontrou um bug usando ferramentas de IA, é provável que outra pessoa também tenha encontrado.” Em julho, a equipe do kernel publicou 432 CVEs em apenas um domingo e uma segunda-feira.

Enquanto a varredura da OpenAI rodava, mantenedores e outros colaboradores já estavam corrigindo muitas das mesmas falhas: depois de dez dias, 61 tinham sido corrigidas upstream, 43 tinham patches à espera e 299 estavam sendo discutidas em público. A OpenAI diz que seguiu as orientações da comunidade do kernel e até agora divulgou 304 achados críticos com patches candidatos. Na nossa visão, o recurso escasso agora é a atenção de quem revisa, testa e publica as correções.

O que uma empresa pode fazer

A maioria das empresas simplesmente roda o software que recebe essas correções, muitas vezes em grandes lotes. A própria OpenAI tira a conclusão: por enquanto, uma conta com poucos privilégios num sistema que “não está em dia com os patches mais recentes disponíveis deve ser considerada funcionalmente equivalente a um acesso root para um agente de ameaça com bons recursos.” Daí decorrem quatro coisas, na nossa visão.

Aplique correções mais rápido, e saiba o que você roda. Jan Schaumann, arquiteto-chefe de segurança da informação da Akamai, escreveu em julho que priorizar mudanças individuais do kernel já não é viável, e disse ao The Register que “atualizações automatizadas, regulares e frequentes” parecem a única abordagem razoável, por mais difíceis que sejam para grandes organizações. Isso exige uma lista atualizada de cada servidor, dispositivo e serviço, e de quem atualiza cada um.

Escolha fornecedores que corrigem rápido, e pergunte quanto tempo uma correção crítica leva para chegar até você. Pergunte aos seus fornecedores de software como eles usam esses modelos: se varrem o próprio código, como verificam o que os modelos reportam e se participam de programas como o Daybreak ou o Fairwind.

Mantenha os dados sensíveis em sistemas que você controla, com acesso limitado por função, para que uma falha no serviço de outra empresa exponha menos. O controle não elimina o dever de corrigir, ele torna esse dever seu. A OpenAI também recomenda sandboxes e isolamento para limitar o dano quando algo é explorado.

Onde estamos

Não construímos scanners de segurança. A nossa parte é o último ponto dessa lista. O Twin, já disponível, dá aos assistentes de uma empresa um único cérebro, com acesso por função, cada gravação autenticada por usuário e cada passo registrado, hospedado na Suíça, na UE, nos Estados Unidos ou no hardware da própria empresa. O Eigna, em acesso antecipado e construído pela nossa parceira Eigna Labs, é um modelo privado que roda na nuvem da própria empresa ou em seus próprios servidores e foi projetado para funcionar offline em redes fechadas. Como tudo o que uma empresa roda, os dois precisam ser mantidos atualizados.