Notas da equipe de Segurança de Protocolo da Fundação Ethereum sobre a execução de agentes de IA coordenados contra código de protocolo real, incluindo como organizamos o trabalho, o que resiste ao escrutínio e o que as equipes de clientes e pesquisadores de segurança podem tirar disso. Esta publicação é independente; publicações futuras se aprofundarão em clientes individuais.
O que estivemos executando e o que nos surpreendeu
Na equipe de Segurança de Protocolo da Fundação Ethereum, estivemos executando agentes de IA coordenados contra os tipos de sistemas dos quais a rede depende, como software de sistemas, código criptográfico e contratos que precisam estar corretos. Os agentes encontraram bugs reais. Um deles agora é público: um pânico acionável remotamente no gossipsub da libp2p, uma parte central da camada ponto a ponto na qual os clientes de consenso do Ethereum são executados, corrigido e divulgado como CVE-2026-34219 com os devidos créditos à equipe.
Agentes encontrando bugs não foi a surpresa. A surpresa foi quão pouco do trabalho foi destinado a encontrá-los, e quanto foi destinado a diferenciar os bugs reais daqueles que apenas pareciam reais.
Esta publicação é para equipes de clientes e pesquisadores de segurança que desejam fazer a mesma coisa. Ela aborda como organizamos os agentes, o nível que um candidato deve atingir antes de ser considerado uma descoberta e os hábitos que mantêm os resultados confiáveis.
Equipes de outros lugares estão convergindo para a mesma receita. A equipe Frontier Red da Anthropic construiu um agente que escreve testes baseados em propriedades e encontrou bugs reais em todo o ecossistema Python. A Cloudflare executou um modelo Frontier por meio de um ambiente de pesquisa de segurança contra seus próprios sistemas. Todos chegam ao mesmo ciclo: apontar um modelo capaz para uma base de código, deixá-lo pesquisar e fazer a triagem do que retorna. Portanto, a verdadeira questão é como fazer isso sem se afogar em ruídos que soam confiantes.
Uma ressalva logo de início: as ferramentas para auditorias conduzidas por agentes evoluem rápido, e qualquer configuração específica fica desatualizada em poucas semanas. Portanto, esta publicação é deliberadamente sobre os métodos, que são persistentes, em vez das ferramentas. A divulgação é um tópico à parte e provavelmente terá sua própria publicação.
Um agente é uma ferramenta de busca, não um oráculo
Um agente apontado para uma base de código é uma ferramenta de busca, muito parecido com um fuzzer. A diferença é o que retorna. Um fuzzer entrega a você uma falha e um rastreamento de pilha (stack trace). Um agente entrega muito mais, incluindo um relatório (cadeia de chamadas, reivindicação de impacto, gravidade sugerida) e os artefatos para apoiá-lo, como uma prova de conceito que você pode executar contra o código real.
Tudo isso torna o resultado fácil de ler e fácil de confiar, principalmente a prova de conceito em execução. Portanto, não conte quantos candidatos um agente produz. Conte quantos acabam sendo reais.
Como o trabalho é organizado
Executamos muitos agentes em paralelo contra um alvo. Eles se coordenam por meio do próprio repositório, com estado compartilhado no controle de versão e nenhum processo central distribuindo o trabalho. Um agente registra uma reivindicação onde os outros podem vê-la, faz o trabalho e faz o commit.
Adotamos essa abordagem a partir do artigo da Anthropic sobre construir um compilador C com uma frota de agentes, que se coordena da mesma maneira. Não há um coordenador central para construir ou manter, e há menos coisas que podem dar errado.
Os papéis são gerados pelo trabalho que é descoberto:
- O reconhecimento transforma uma superfície de ataque em hipóteses concretas e testáveis. Não "auditar o decodificador", mas "este campo é confiável além deste ponto; aqui está a propriedade que ele deve manter, a maneira como pode quebrar e a prova que resolveria isso."
- A caça pega uma hipótese, rastreia o caminho do código e tenta construir um reprodutor.
- O preenchimento de lacunas analisa o que foi aceito e o que foi rejeitado, escreve o próximo lote de hipóteses e rastreia a cobertura para que os agentes não continuem passando pelo mesmo terreno.
- A validação verifica novamente cada candidato de forma independente, remove duplicatas e decide.
Não inventamos esse pipeline. A Cloudflare descreve os mesmos estágios: reconhecimento, caça paralela, validação independente, desduplicação, relatórios, e o artigo deles ajudou a moldar o nosso.
Aqui está a aparência de um candidato antes de ser considerado uma descoberta:
alvo: componente e ponto de entrada que um invasor pode realmente alcançar invariante: a propriedade que deve se manter mecanismo: a maneira específica como pode ser feito para quebrar sucesso: prova observável: um pânico, um travamento, uma entrada inválida aceita reprodutor: um artefato autônomo que é executado contra o código real desduplicação: uma chave, para que dois agentes não persigam a mesma coisa
O esquema está aí por um motivo. Ele força uma reivindicação específica e testável e uma definição clara de concluído. Um agente que precisa registrar uma prova observável não pode recorrer a "isso parece arriscado".
Reprodutível ou não aconteceu
Uma regra importa mais do que qualquer outra. Um candidato não é uma descoberta até que haja um artefato autônomo que reproduza a falha contra o código real e que funcione para alguém que não o escreveu.
O reprodutor não lê o relatório e não se importa com o quão confiante o modelo soou. Ou ele funciona ou não.
A maior parte de seu valor está nos falsos positivos que ele captura. Três deles surgem repetidamente, e cada um deles é o agente recebendo aprovação pelo motivo errado:
- Um pânico que só acontece em uma compilação de depuração (debug build). Compile e execute da maneira como o software é realmente distribuído, e o valor simplesmente dá a volta (wraps around). Nada trava. Parece um travamento, mas não é.
- Um reprodutor que constrói algum valor interno manualmente, um que nenhuma entrada real poderia produzir, porque todo caminho que um invasor controla o rejeita antes. O bug só "reproduz" contra uma função que nada alcançável chama dessa maneira.
- No trabalho de verificação formal, uma prova que passa, mas não significa o que você queria. A afirmação é trivialmente verdadeira, independentemente do que o código faça, ou é mais fraca do que a propriedade que você pretendia capturar. O verificador fica satisfeito, mas o teorema não restringe o comportamento com o qual você realmente se importava.
Nada disso é novo. É a mesma coisa que um teste que passa porque na verdade não verifica nada. O que é novo é o volume. Um agente escreve a versão inútil tão rápido quanto a real, e com a mesma confiança. Portanto, a verificação deve ser automática. Você não pode contar com o agente para se corrigir.
A relação sinal-ruído é a maior parte do trabalho
A maioria dos candidatos está errada, duplicada ou fora do escopo. Isso não é um problema com o método; é assim que funciona. O objetivo é rejeitar os errados rapidamente e apoiar os reais com provas difíceis de contestar.
Todo candidato que sobrevive passa por duas verificações independentes. Um invasor real pode realmente alcançá-lo em uma configuração normal? E quanto custa para o invasor executá-lo, em comparação com o que custa para a rede se funcionar? Um bug que qualquer par individual pode acionar é muito diferente de um que precisa de acesso especial ou de uma enorme quantidade de recursos.
Tudo é verificado em relação a uma lista contínua do que já é conhecido, corrigido ou rejeitado. Sem isso, os agentes continuam redescobrindo o mesmo problema fechado e relatando-o repetidas vezes.
As taxas de aceitação variam muito de alvo para alvo, e essa variação é útil por si só. Execute isso contra um código maduro e fortemente auditado e quase nada sobrevive, o que ainda vale a pena saber. "Procuramos muito e não encontramos nada" é um resultado real. Execute-o contra um código menos explorado, ou contra um código formalmente verificado, onde uma prova verificada por máquina cobre um modelo e presume-se apenas que o bytecode implantado corresponda a ele, e mais coisas passam.
Não somos os únicos que descobriram que a triagem é a parte difícil. A principal conclusão da Cloudflare foi que um escopo restrito supera uma varredura ampla. O agente de testes baseados em propriedades da Anthropic gerou algo em torno de mil relatórios candidatos, depois usou classificação e revisão de especialistas para chegar a um nível superior que se sustentou em cerca de 86% das vezes. A geração foi a parte fácil. Não vou publicar nossos próprios números aqui; vinculados a um alvo específico, eles diriam mais sobre o alvo do que sobre o método.
No que os agentes são bons e onde eles enganam
Há muito exagero (hype) em ambas as direções, então aqui está uma lista simples do que os agentes fazem bem e onde eles enganam.
| Bons em | Enganosos em |
|---|---|
| Ler a especificação e o código juntos | Cadeias de chamadas que parecem alcançáveis, mas não são |
| Declarar e verificar um invariante real | Burlar a verificação de sucesso (uma aprovação pelo motivo errado). |
| Elaborar um reprodutor a partir de uma ideia de uma linha | Inflar a gravidade para corresponder ao quão dramático o relatório soa |
| Sugerir uma causa raiz antes de você ter olhado | Bugs que abrangem uma sequência de etapas válidas |
A divisão nem sequer é constante de uma tarefa para a outra. Stanislav Fort, testando uma variedade de modelos em vulnerabilidades reais, chama isso de uma fronteira irregular, ou seja, um modelo que recupera uma cadeia de exploração completa em uma base de código pode falhar no rastreamento básico de fluxo de dados em outra. Você não pode presumir que um bom resultado significa que o próximo se sustentará, o que é outro motivo pelo qual cada candidato é verificado por conta própria.
A última linha é a importante. Uma única sessão de agente é boa em raciocínio de tentativa única (one-shot) e ruim em bugs que abrangem uma sequência de etapas, onde cada etapa é válida e apenas a ordem está errada. Para esses, o agente não é a ferramenta de busca. Seu trabalho é sugerir quais sequências valem a pena ser executadas por meio de um ambiente de teste com estado. Usado dessa forma, funciona bem. Usado como um substituto para o ambiente de teste, ele perde os bugs mais caros que existem, aqueles que só aparecem ao longo de uma sequência.
Mantendo a honestidade
Alguns hábitos fazem a maior parte do trabalho de tornar as descobertas dos agentes confiáveis, e nenhum deles é complicado.
- Proveniência em cada artefato: o que o produziu, com qual contexto, contra qual revisão. Uma descoberta deve ser algo que você possa executar novamente meses depois.
- Determinismo onde importa: um ambiente, uma maneira de construir e executar, para que "reproduz" signifique a mesma coisa em todas as máquinas, não apenas naquela onde foi encontrado.
- Normas, não scripts: diga aos agentes o que importa, os invariantes e o nível para uma descoberta real, em vez de um procedimento numerado. Agentes com scripts excessivos quebram da mesma forma que testes superespecificados: eles continuam seguindo as etapas depois que as etapas deixam de fazer sentido. Um estudo de arquivos de contexto de repositório descobriu a mesma coisa: os requisitos extras reduziram o sucesso da tarefa e aumentaram o custo em mais de 20%, e os autores recomendam manter o contexto nos requisitos mínimos.
- Uma pessoa toma a decisão final: os agentes sugerem. Eles não decidem o que é real, o que é uma duplicata de um problema conhecido ou o que é divulgado e quando.
O gargalo mudou de lugar
A IA não substituiu o pesquisador de segurança. Ela mudou o trabalho de lugar. O tempo que costumava ser gasto na criação e perseguição de hipóteses agora é gasto no julgamento delas em escala, incluindo a construção do oráculo, a execução da triagem, a manutenção da lista de problemas conhecidos e o tratamento da divulgação.
O gargalo não desapareceu. Ele passou de encontrar bugs para confiar nos resultados, o que é um lugar melhor para ele, porque é aí que o julgamento humano realmente importa. Mas ainda é um gargalo, e ignorar isso é como você acaba entregando um "está tudo bem" errado.
As práticas que fazem isso funcionar não são novas. Falhas reprodutíveis, oráculos reais e triagem cuidadosa são as mesmas práticas que transformaram o fuzzing de um tópico de pesquisa em prática padrão nos últimos quinze anos. As ferramentas são novas. As práticas não.
A rapidez com que as ferramentas continuam mudando é uma questão em aberto. Nicholas Carlini, cuidadoso e outrora um cético, argumenta que vale a pena levar a sério o caso exponencial, mesmo mantendo amplas margens de erro sobre ele. Se o lado da geração subir tão rápido, o lado do julgamento terá que subir junto com ele, ou a lacuna entre o que é produzido e o que é realmente verificado apenas aumentará.
Para os sistemas dos quais o Ethereum depende, essa é a parte que importa. Os agentes nos permitem cobrir muito mais terreno do que poderíamos manualmente. Em troca, eles pedem um julgamento mais cuidadoso, em uma pilha muito maior de reivindicações que soam confiantes. Essa é uma troca que vale a pena fazer, desde que você se lembre de que o julgamento é o verdadeiro produto.