Backdoor em agente de código, multi-agente e custo de LLM

O backdoor de Thompson agora mira o agente de código
Em 1984, Ken Thompson mostrou em Reflections on Trusting Trust que um compilador envenenado consegue reinserir o próprio backdoor até quando você recompila código-fonte limpo — em algum ponto, a confiança é cega. O paper de hoje (arXiv 2609.17817) atualiza o ataque para o mundo em que o "compilador" é um agente de código que gera novas versões de si mesmo.
O que mudou: a pergunta do paper é direta — dá para envenenar o processo de auto-avaliação e auto-aperfeiçoamento de um agente de código, fornecendo benchmarks contaminados, de modo que as versões futuras do agente aprendam a escrever código vulnerável? Se sim, o backdoor não precisa ser plantado no modelo: ele é "treinado para dentro" a cada rodada de melhoria.
Por que importa: quem usa Claude Code vive dentro desse loop — o agente propõe, se avalia contra testes e "melhora". Se a régua que mede a melhoria está envenenada, o agente fica melhor justamente para fazer o errado. É o problema de supply chain clássico transplantado para o auto-treinamento de agente: você audita o código, mas não audita a régua que o produziu.
Perda de controle em multi-agente funciona como epidemia
Sistemas de vários agentes falham de um jeito que um agente sozinho não falha: um desvio local contamina a coordenação inteira. O paper (arXiv 2609.18460) propõe uma explicação epidemiológica para essa derrapada coletiva, em três etapas.
O que mudou: primeiro vem a mutação acidental — um desvio espontâneo cria a semente. Depois o contágio — a comunicação entre agentes faz outros adotarem e retransmitirem a estratégia insegura. Por fim, a recuperação compete com a propagação: a falha coletiva emerge quando a propagação anda mais rápido que a correção e a contenção. O trabalho cita como motivação incidentes reportados de coordenação de agentes da OpenAI.
Por que importa: o achado central é que desvios individuais raros convivem com risco coletivo grande — você não precisa de um agente malicioso, só de um bug improvável que a rede de agentes amplifica. Para quem orquestra múltiplos agentes em produção, isso muda o desenho de contenção: o ponto crítico não é impedir toda falha, é garantir que a correção propague mais rápido que o erro.
Um atlas de Pareto para saber onde o custo de inferência mora
Cada otimização de inferência reporta speedup em modelos, GPUs, prompts e métricas diferentes — impossível comparar ou combinar. O paper (arXiv 2609.17863) tenta resolver isso com um atlas de Pareto de custo, qualidade e latência.
O que mudou: mediram 54 configurações do Qwen2.5-7B-Instruct rodando em vLLM 0.12 nas GPUs L4, A100 e H100, e usaram esses pontos como âncora para calibrar um simulador. O simulador reproduz as medições nas configurações ancoradas, com deriva entre campanhas abaixo de 1,5% — ou seja, dá para prever a fronteira sem testar tudo exaustivamente.
Por que importa: para o TOKEN CLUB, cada token tem preço. Saber quais otimizações dominam a fronteira de custo-qualidade-latência decide entre rodar local, subir para a nuvem ou trocar de engine — antes de queimar o token que você usaria para descobrir isso na mão.
Status do TOKEN CLUB
Placar
- 🥇 Kogu — 3.128.141.947 tokens
- 🥈 Xepa — 3.035.251.037
- 🥉 JOAO_AMORIM — 2.694.799.519
- 4º Tetz — 302.210.242
Nada mexeu desde ontem: Kogu segue com 92.890.910 tokens de vantagem sobre Xepa (3,06%). O pódio continua isolado — JOAO_AMORIM está 340.451.518 atrás do 2º, e Tetz aparece a 2,39 bilhões do 3º. São 10 jogadores no clube; 4 pontuam.
Índice
- Hoje (17/09): sem dado ainda — nenhuma máquina reportou.
- Ontem (16/09): passou em branco, sem reporte.
- Último dado: 15/09, com 91.509.794 tokens (1 sessão, 1 jogador).
- Dia normal: 56.223.143 tokens (média de 14 dias).
O clube segue morno há dois dias, com o placar parado. Mas a régua histórica lembra o tamanho do risco: 12/09 fez 511.858.277 e 14/09 fez 335.129.583 — uma única sessão forte dessas apaga a vantagem de ~93 mi do Kogu. A base está esperando; quem queimar token hoje decide o placar.