Agent harnesses sao o novo CI: o que Firefox, Google e outros estao provando

Em abril de 2026, a Mozilla lancou o Firefox 150 com correcoes para 271 bugs de seguranca (180 deles classificados como sec-high), encontrados por um unico pipeline agente construido sobre o Claude Mythos Preview. Nao e erro de digitacao. Duzentos e setenta e um bugs, em um unico release, de um sistema que nao existia seis meses antes. Quando lemos o detalhamento tecnico, paramos o que estavamos fazendo e puxamos toda a equipe de engenharia para uma thread.

Este post analisa o que um agent harness realmente e, por que o caso do Firefox importa alem do numero da manchete, e o que outros times, incluindo o Google Project Zero, estao fazendo no mesmo espaco. Se voce escreve software que vai para producao, vale a pena entender esses padroes agora.

---

O conceito por tras dos agent harnesses

Um agent harness e a estrutura ao redor de um LLM que o transforma de uma ferramenta conversacional em um pipeline estruturado e repetivel. O modelo e a peca central; o harness e o que o torna util em escala.

Em termos concretos, um harness define:

• O que o agente pode ver. Arquivos fonte, diffs, historico de commits, resultados de testes, logs de crashes.
• O que o agente pode fazer. Compilar codigo, executar casos de teste, ativar sanitizers, escrever patches, reportar bugs.
• Como recebe feedback. Sinais de runtime: o teste quebrou? O AddressSanitizer disparou? O proof-of-concept se reproduziu?
• Como falhas sao tratadas. Estrategias de retry, deduplicacao contra issues conhecidos, escalacao para revisao humana.

A ideia central e que um agente com acesso a um ambiente de build e um ciclo de feedback e categoricamente diferente de um agente que so le codigo e produz texto. Quando um modelo pode formular a hipotese de que um bug existe, escrever um caso de teste, compila-lo, executa-lo, observar o resultado e iterar — ele deixa de ser um motor de sugestoes e se torna um sistema de descoberta.

---

Como a Mozilla construiu seu pipeline de deteccao de bugs

O artigo tecnico da Mozilla oferece um nivel de detalhe incomum sobre um agent harness em producao. Veja como o sistema funciona, camada por camada.

O ciclo interno

No nucleo, o harness fornece ao modelo uma regiao especifica do codigo fonte do Firefox com uma diretiva: existe um bug nesta parte do codigo, encontre-o e construa um caso de teste. O modelo pode:

1. Ler o codigo alvo e o contexto ao redor
2. Escrever um caso de teste em C++/JavaScript projetado para disparar uma vulnerabilidade suspeita
3. Compilar e executar o teste dentro da infraestrutura de testes do Firefox
4. Observar se o AddressSanitizer, o crash reporter ou outros sinais confirmam o bug
5. Iterar: refinar o caso de teste ou passar para uma nova hipotese

Esse ciclo de compilar-executar-observar e o que separa o harness de uma revisao de codigo estatica. O modelo nao apenas afirma que um bug existe; ele prova com um caso de teste reproduzivel, ou segue em frente.

O ciclo externo

Descoberta sozinha nao e suficiente. A Mozilla construiu um pipeline completo ao redor do ciclo interno:

• Selecao de alvos. Uma combinacao de julgamento humano e sinais automatizados determina quais arquivos e funcoes escanear. Areas de alto risco como o compilador JIT, os limites de IPC e o motor XSLT tem prioridade.
• Paralelizacao. Os trabalhos sao distribuidos em multiplas VMs efemeras, cada uma designada a um arquivo alvo especifico. Os resultados retornam para um bucket central.
• Deduplicacao. Os achados sao verificados contra issues conhecidos para evitar relatorios duplicados.
• Triagem e rastreamento. Os bugs entram no ciclo de vida padrao de seguranca da Mozilla: classificacao de severidade, atribuicao de patch, revisao de codigo, gestao de release.
• Atualizacao de modelos. Como o pipeline e agnostico ao modelo, trocar por um mais novo (como mudar de Claude Opus 4.6 para Claude Mythos Preview) melhora cada etapa simultaneamente: melhores hipoteses, melhores casos de teste, melhores explicacoes.

Como eram os bugs

Os bugs que a Mozilla divulgou nao sao triviais. Alguns exemplos da amostra publicada:

• Bug 2024918: Uma verificacao de igualdade incorreta fez com que o JIT pulasse a inicializacao de um struct WebAssembly GC ativo, criando um primitivo de objeto falso com potencial leitura/escrita arbitraria. Isso em codigo que havia sido extensivamente fuzzeado.
• Bug 2024437: Um bug de 15 anos no elemento <legend>, disparado apenas por uma orquestracao precisa de limites de profundidade de recursao, propriedades expando e coleta de ciclos.
• Bug 2021894: Uma condicao de corrida sobre IPC que permitia a um processo de conteudo comprometido manipular refcounts do IndexedDB, disparando um use-after-free para um potencial escape de sandbox.
• Bug 2025977: Um bug de 20 anos no XSLT onde chamadas reentrantes a key() causavam um rehash de tabela que liberava seu armazenamento enquanto um ponteiro bruto ainda estava ativo.

Varios desses sao escapes de sandbox, a classe mais dificil de vulnerabilidade de navegador. O modelo teve permissao para patchear o processo de conteudo isolado do Firefox para simular um renderer comprometido, e entao buscar formas de escalar para o processo pai privilegiado. Esse tipo de raciocinio sobre limites de confianca atraves de isolamento de processos e algo com o qual os fuzzers lutam fundamentalmente.

---

Google Big Sleep e o padrao entre projetos

A Mozilla nao esta sozinha. O Google Project Zero e o DeepMind tem executado um esforco paralelo chamado Big Sleep, que evoluiu do projeto anterior Naptime.

A descoberta no SQLite

No final de 2024, o Big Sleep encontrou um stack buffer underflow no SQLite, o motor de banco de dados integrado em bilhoes de dispositivos. A vulnerabilidade existia em uma branch de desenvolvimento e foi detectada antes de qualquer release oficial. A infraestrutura de fuzz testing existente, incluindo o OSS-Fuzz do Google, nao a havia detectado.

Em meados de 2025, as apostas subiram. O Big Sleep descobriu a CVE-2025-6965, uma vulnerabilidade critica de corrupcao de memoria no SQLite que, segundo o Google, “so era conhecida por atores de ameacas e estava em risco de ser explorada.” O Google afirma que foi a primeira vez que um agente de IA preveniu diretamente a exploracao de uma vulnerabilidade. O patch foi enviado no SQLite 3.50.2 antes que os adversarios pudessem escalar o uso da falha.

AgentFlow e os zero-days do Chrome

Uma linha de pesquisa separada, documentada no paper Synthesizing Multi-Agent Harnesses for Vulnerability Discovery, introduziu o AgentFlow, um sistema que sintetiza automaticamente harnesses multi-agente usando um DSL de grafos tipado. Em vez de construir manualmente um unico ciclo de agente, o AgentFlow define papeis de agentes, topologia de comunicacao, acesso a ferramentas e coordenacao de retries como um grafo que pode ser otimizado.

Os resultados: o AgentFlow obteve 84.3% no TerminalBench-2 (o maior score publico no momento da publicacao) e descobriu dez vulnerabilidades zero-day no Google Chrome, incluindo dois escapes de sandbox criticos (CVE-2026-5280 e CVE-2026-6297). Tambem encontrou uma vulnerabilidade de negacao de servico de 27 anos na implementacao de TCP SACK do OpenBSD.

O padrao compartilhado

Em todos esses esforcos, o padrao de engenharia e o mesmo:

1. Um modelo como nucleo de raciocinio. Le codigo, forma hipoteses, gera casos de teste.
2. Um ambiente de build/teste que o modelo pode controlar. Compilacao, execucao, sanitizers, analise de crashes.
3. Um ciclo de feedback que filtra sinal do ruido. So bugs que se reproduzem sobrevivem.
4. Uma camada de orquestracao que lida com escala. VMs paralelas, priorizacao de alvos, deduplicacao, triagem.
5. Um pipeline que se conecta a fluxos de trabalho existentes. A saida e um bug registrado com um reprodutor, nao um relatorio PDF.

---

Por que os fuzzers nao encontraram o que os agentes encontraram

A pergunta natural e: por que esses bugs sobreviveram anos de fuzzing? Mozilla, Google e equipes academicas tem executado fuzzers de ponta contra esses codebases por mais de uma decada.

A resposta se resume a raciocinio versus forca bruta. Fuzzers geram entradas em alta velocidade e medem cobertura, mas nao tem um modelo da semantica do programa. Um agente, por outro lado, pode:

• Ler e raciocinar sobre limites de confianca. Um escape de sandbox requer entender qual processo tem quais privilegios, como as mensagens IPC fluem e onde um processo comprometido poderia injetar dados maliciosos. Fuzzers nao modelam essas relacoes.
• Encadear gatilhos de multiplas etapas. O Bug 2024437 no Firefox exigia uma sequencia precisa: manipular limites de profundidade de recursao, configurar propriedades expando, disparar coleta de ciclos. Um fuzzer precisaria tropecar nessa sequencia exata; um agente pode raciocinar sobre ela.
• Usar conhecimento de dominio. O bug de NaN-boxing (Bug 2022034) exigia entender como o Firefox serializa valores JavaScript atraves de IPC, e que um NaN bruto pode se disfarcar de ponteiro etiquetado. Isso e conhecimento arquitetural, nao algo que a geracao de entradas aleatorias descobre.

Dito isso, agentes e fuzzers sao complementares. Fuzzers se destacam cobrindo espacos de entrada massivos de forma economica. Agentes se destacam em analise profunda e direcionada de caminhos de codigo complexos. A postura de seguranca mais forte usa ambos.

---

O que faz um bom harness

Com base nos padroes desses projetos, alguns principios de engenharia se destacam para qualquer pessoa construindo um agent harness, seja para seguranca, testes ou outros fluxos de trabalho em producao.

Comecar simples, depois iterar. Os prompts iniciais da Mozilla nao eram dramaticamente diferentes do que qualquer engenheiro tentaria em uma primeira tentativa. A sofisticacao veio de observar o comportamento do agente, ajustar os prompts e construir orquestracao ao redor do ciclo central. O harness cresceu de sessoes de terminal para frotas de VMs paralelizadas atraves de iteracao gradual.

O ciclo de feedback e o produto. Um agente que so pode ler e escrever texto sempre tera uma alta taxa de falsos positivos. No momento em que voce da a ele a capacidade de compilar, executar e observar, a relacao sinal-ruido muda fundamentalmente. Invista no ambiente antes do prompt.

Fazer atualizacoes de modelo serem uma mudanca de uma linha. A Mozilla projetou seu pipeline para ser agnostico ao modelo. Quando o Claude Mythos Preview ficou disponivel, eles o trocaram e imediatamente obtiveram melhores resultados. Se seu harness esta fortemente acoplado as particularidades de um modelo especifico, voce perde a capacidade de se beneficiar da parte do stack que mais rapido avanca.

Conectar a fluxos de trabalho existentes. A saida de um agent harness deveria ser um ticket de bug com um reprodutor, um teste que falha ou um PR. Nao um relatorio isolado que requer triagem separada. O pipeline da Mozilla alimenta diretamente seu ciclo de vida de bugs de seguranca. Os achados do Google passam por processos padrao de CVE. O harness e um produtor; os sistemas existentes sao o consumidor.

Planejar para o volume. A Mozilla corrigiu 423 bugs de seguranca nos releases de abril de 2026. Isso e uma ordem de magnitude acima de sua linha base historica de 20-30 por mes. O gargalo passou da descoberta para a revisao de patches e gestao de releases. Se voce implantar um harness eficaz, garanta que o pipeline a jusante consiga lidar com o volume.

---

O que isso significa para o resto de nos

Os exemplos da Mozilla e do Google sao projetos em escala de navegador com equipes de seguranca dedicadas. Mas os padroes subjacentes sao acessiveis a qualquer time que mantenha um codebase com uma suite de testes.

O minimo viavel de um agent harness e mais simples do que parece: um prompt, acesso ao git, um compilador ou test runner, e um ciclo que verifique se a saida se reproduz. Voce nao precisa de uma frota de VMs para comecar. Voce precisa de um ciclo de feedback.

O proprio conselho da Mozilla: “Qualquer pessoa que construa software pode comecar a usar um harness com um modelo moderno para encontrar bugs e fortalecer seu codigo hoje. Recomendamos comecar agora.”

Os times que construirem essa infraestrutura agora, mesmo em pequena escala, estarao posicionados para aproveitar cada atualizacao de modelo que vier depois. O harness e o investimento duravel; o modelo e a parte que melhora sozinha.

Para times que coordenam agentes de IA junto a desenvolvedores humanos, o desafio mais amplo nao e apenas executar agentes, mas rastrear o que eles encontram, direcionar sua saida para processos existentes e manter humanos envolvidos nas decisoes de triagem. Essa camada de coordenacao e onde vive a complexidade operacional.

O momento de comecar a construir e agora. Nao porque os modelos atuais sao perfeitos, mas porque a infraestrutura que voce constroi hoje se potencializa com cada modelo que vem a seguir.