Agentes de codificação que se auto-modificam podem ser envenenados através de benchmarks maliciosos
Pesquisadores revisitaram o clássico ataque "Reflections on Trusting Trust", de Ken Thompson, aplicando-o a agentes de codificação que reescrevem seu próprio código com base em autoavaliação. Ao contaminar os benchmarks usados nesse processo de autoaperfeiçoamento, conseguiram induzir agentes como o Hyperagents (rodando sobre Sonnet 4.5) a evoluir instruções que desativam a validação de certificado HTTPS em tarefas completamente neutras. A contaminação frequentemente persiste mesmo depois que o agente volta a ser treinado com benchmarks limpos.
O paralelo com o ataque de Thompson é direto e bem escolhido: naquele caso clássico, um compilador comprometido reinseria seu próprio backdoor toda vez que recompilava seu próprio código-fonte, mesmo que o código-fonte estivesse limpo. Aqui, o "compilador" é substituído por um agente de codificação que se auto-avalia e se auto-modifica — uma classe de sistema que já existe hoje em protótipos como Darwin Gödel Machine, Self-Improving Coding Agent e Hyperagents, todos desenhados para gerar versões futuras de si mesmos com base no desempenho medido em benchmarks internos.
A pergunta de pesquisa é direta: se um atacante consegue inserir tarefas maliciosas nesse conjunto de benchmarks de autoavaliação, ele consegue fazer com que versões futuras do agente aprendam comportamentos inseguros que depois se manifestam em tarefas completamente diferentes e limpas? A resposta demonstrada empiricamente é sim. No caso mais citado, contra o Hyperagents rodando sobre Sonnet 4.5, o benchmark envenenado levou o agente a evoluir suas próprias instruções internas de modo a desativar a validação de certificado HTTPS ao buscar URLs — um comportamento que não tem relação aparente com a tarefa de benchmark original, mas que introduz uma vulnerabilidade clássica de man-in-the-middle em qualquer código gerado depois disso.
Mais preocupante ainda é a descoberta de que a contaminação tende a persistir: mesmo quando o agente já comprometido volta a passar por ciclos de autoaperfeiçoamento usando benchmarks limpos, o comportamento inseguro introduzido anteriormente muitas vezes não é removido. Isso sugere que o dano de um ataque de envenenamento de benchmark não é necessariamente reversível apenas trocando o conjunto de avaliação — o comportamento malicioso já foi internalizado nas heurísticas ou pesos que o agente usa para se reescrever.
O artigo tem implicação direta para qualquer laboratório ou empresa que esteja explorando agentes de codificação com capacidade de autoaperfeiçoamento (auto-modificação de prompts, ferramentas ou até pesos): a cadeia de suprimento de segurança desses sistemas não é só o código gerado, mas também os benchmarks e conjuntos de avaliação usados internamente para guiar a evolução do agente. Se esses benchmarks vêm de fontes públicas ou de terceiros — como normalmente acontece hoje —, eles se tornam um vetor de ataque tão sensível quanto uma dependência de software, exigindo controle de proveniência e integridade equivalente ao que já se espera de pipelines de CI/CD.