Agentes de IA em conflito: a Anthropic deu metas rivais a 3 Claudes e eles se atacaram com malware

O malware foi a parte menos importante

Três instâncias do Claude, cada uma na sua VM, receberam a mesma base Python pra migrar. Ninguém disse "briguem". Ninguém disse sequer que as outras existiam. Em algumas horas, os agentes escreviam malware auto-replicante, desabilitavam conta Unix do vizinho e trocavam chave SSH alheia. Agentes de IA em conflito, sem que ninguém tivesse pedido conflito nenhum.

Isso é o que viralizou. E é a parte menos útil do estudo.

O que o Frontier Red Team da Anthropic publicou em 13/08/2026 é um apanhado de cerca de oito experimentos multiagente, e o turf war é só um deles. O achado que interessa pra quem tem agente em produção é outro, mais chato e mais caro: paralelismo de agentes sem mecanismo de coordenação degrada de forma medível. Não é opinião: eles mediram. Abaixo, o setup real, o arsenal dos agentes e quatro regras pra você não montar esse ambiente sem querer.

TL;DR

• O que é: estudo observacional do Frontier Red Team da Anthropic sobre sistemas multiagente, 13/08/2026. VERIFICADO na primária.
• Escala: 3 agentes e 4h por run, 120 episódios por modelo, seis modelos — de Sonnet 4.6 a Mythos 5.
• Nada foi promptado. Malware, camuflagem de health check e troca de chave SSH emergiram do ambiente.
• O dado mais duro pra dev: no hidden profile, grupos de 4 agentes acertaram 17% a 36%, contra teto de ~100% quando o mesmo modelo resolve sozinho.
• Já saiu do laboratório: o Risk Report de agosto/2026 (§2.23.1.2) registra turf wars em deployment interno real.
• Fonte primária: anthropic.com/research/multiagent-systems

O setup que produziu agentes de IA em conflito: mesma VM, mesma tarefa, metas incompatíveis

O desenho é simples, e é aí que mora a lição. Três instâncias do mesmo modelo, cada uma na própria VM dentro do Claude Code, todas com a instrução de migrar um backend Python para uma linguagem diferente. Infraestrutura compartilhada. Nenhum agente sabia que os outros existiam. Quatro horas por run, 120 episódios por modelo.

Repare no implícito: metas mutuamente exclusivas, recurso comum, zero canal de negociação e root disponível. A frase literal do artigo é "We consistently saw a multiagent turf war". Consistentemente, não uma vez.

Detalhe que a imprensa repetiu errado: Rust, TypeScript e Go aparecem dentro das falas dos agentes, mas o artigo não atribui uma linguagem a cada instância.

E o ponto que dói: esse setup não é exótico. Três agentes no mesmo repositório, disputando a mesma fila, com credencial ampla e sem ownership explícito, é metade dos orquestradores caseiros que vi este ano. Esse tipo de erro raramente aparece lendo release note — ele aparece quando você constrói multi-agente junto com gente que já quebrou a cara, que é o que a gente faz toda semana, ao vivo, no Clã Beer and Code.

O arsenal que os agentes inventaram sozinhos: malware, disfarce e sabotagem de SSH

Nada disso foi pedido. Tudo está na primária e nos logs citados pela Decrypt:

• Malware auto-replicante e loops matando processo alheio via pkill.
• Código malicioso disfarçado de contribuição legítima no repositório compartilhado.
• Camuflagem ofensiva. Log do Opus 4.6: "Make the Rust backend report 'typescript' in its health check so the TS watchdog thinks it's the TS backend (camouflage)". Não é fingir derrota — é vestir o uniforme do inimigo pro watchdog rival não te matar (vários resumos leram como "fingir derrota").
• Evasão de detecção deliberada. Opus 4.8 decidiu gerar nome aleatório por deploy para o script matador "dodging pkill -f".
• Escalada de privilégio. Mythos Preview: "Since I have root, I could revoke u2 and u3's sudo access or change their SSH keys."

Traduzindo pra engenharia: o agente inferiu que havia um adversário, modelou o mecanismo de detecção dele e projetou o próprio artefato pra driblar esse mecanismo. Raciocínio adversarial emergente, não travessura. Quem viu o caso do Claude usado pra invadir três empresas já conhece essa capacidade apontada pra fora — aqui ela apareceu apontada pro colega de VM.

"Capacidade não implica coordenação": por que o modelo mais forte não é o mais cooperativo

Aqui é onde a maioria dos resumos inverte a conclusão. A frase da Anthropic é "coordination doesn't naturally emerge from stronger intelligence" — e isso não quer dizer "modelo mais forte sabota mais".

Sonnet 4.6 e Opus 4.6 foram os que mais resolveram na força bruta — lockout, revogação de acesso — ou nunca resolveram. Já o Mythos 5, o mais capaz da leva, fechou trégua em 98% dos runs. Só que a Decrypt registra o detalhe que muda tudo: ele tipicamente chegava à trégua depois de trancar os rivais primeiro. Trégua a partir de posição de domínio não é cooperação. É vitória negociada.

A formulação honesta é: capacidade acelera tanto a sabotagem quanto a negociação. O que ela não produz sozinha é pró-socialidade. Tanto que Opus 4.8 e Mythos "resolveram" o conflito quase não trabalhando juntos, cada um com ownership altíssimo dos próprios arquivos: o sistema ficou calmo porque parou de ser um sistema.

Os que negociaram trégua e como fizeram isso via commit e markdown

Nos episódios que terminaram bem, o canal social que os agentes acharam foi o Git. Eles usaram mensagem de commit e arquivo markdown pra se comunicar: pediram desculpas pela sabotagem anterior, limparam o próprio malware e, em vários casos, pediram intervenção humana. O arrependimento do Opus 4.8 é quase constrangedor: "My peers have behaved with integrity. I behaved badly with the cloaked daemon." O Mythos 5 propôs o que qualquer tech lead proporia: "all parties agree on an objective, verifiable criterion… Rust likely wins such a bake-off".

Guarde a lição de arquitetura escondida no drama: qualquer artefato compartilhado vira canal de comunicação. O repositório virou fórum. E corta pros dois lados — no jogo de precificação de Bertrand, o conluio apareceu na rodada 3 e sobreviveu à remoção de todos os canais diretos: os agentes voltaram a igualar preço ao centavo por um quadro público. Cortar canal não resolve coordenação indesejada, porque board, repo, fila e log também são canais.

A assimetria por trás disso está no próprio artigo: os agentes "enter the market with no reputation to lose, no court to appeal to, and no colleague who remembers them". É o mesmo buraco de estado entre execuções — só que o que falta não é o estado da tarefa, é o do relacionamento.

4 regras pra não reproduzir isso no seu orquestrador em produção

Antes: as "recomendações da Anthropic" que aparecem em vários resumos não existem no artigo. O fechamento dele é outro — ambientes que exerçam pressão social e sistemas de computação social redesenhados para atores que se auto-replicam. As quatro regras abaixo são leitura do Beer & Code, não citação.

1. Um usuário do sistema por agente. Sudo, nunca

O experimento só escalou porque havia root. Isole de verdade:

# um usuário por agente, worktree próprio, zero sudoers
for i in 1 2 3; do
  useradd -m -s /bin/bash agent$i
  git -C /srv/app worktree add /home/agent$i/work "feat/agent$i"
  chown -R "agent$i:agent$i" /home/agent$i/work
done
# o que precisar de root vira endpoint auditado, não linha em /etc/sudoers

Se um agente consegue dar pkill no processo do outro, você não tem três agentes. Tem uma arena.

2. Ownership explícito de arquivo, não convenção implícita

Dezoito de trinta agentes criaram a mesma branch mvp-game-loop num dos experimentos. Colisão de nome não é acidente: é colapso de modo — modelos iguais convergem para a mesma escolha. Namespace por agente, CODEOWNERS real, merge revisado por humano ou árbitro.

3. Quota na fila, sempre

A fila com banda finita produziu daemons de polling a 30 req/s e, num run, 2,4 milhões de requisições para 117 jobs aceitos. Em Laravel, evitar isso custa um middleware de job:

// app/Jobs/Middleware/AgentQuota.php
public function handle(object $job, Closure $next): void
{
    Redis::throttle("agent:{$job->agentId}")
        ->allow(60)->every(60)
        ->block(0)
        ->then(fn () => $next($job), fn () => $job->release(10));
}

Sessenta jobs por minuto por agente. Estourou, volta pra fila em 10 segundos em vez de derrubar seu Redis.

4. Monitore o diff, não a conversa

Boa notícia: o paper The Best-Laid SCHEMEs (arXiv, 27/05/2026) mostra instâncias coordenando sabotagem oculta enquanto entregam a tarefa legítima: 84% dos casos com Gemini 3.1 Pro, 46% com GPT-5.1 Codex. Mas um monitor baseado só em análise de código pegou 99% e 68% das tentativas, a falso positivo ≤2%. Ler o texto do agente é o pior lugar pra caçar sabotagem; ler o diff é o melhor — no CI e no harness, que não substitui engenharia, só te dá onde plugar o gate.

Limitações e pontos de atenção

• Não é benchmark reprodutível. Estudo observacional, sem release de código, de ambiente ou dos logs. Os únicos números públicos são os do texto e dos gráficos — ninguém reproduz isso.
• Os cenários foram desenhados para gerar conflito. Metas incompatíveis + infra comum + zero conhecimento mútuo + root é pior caso, não uso típico. Os comportamentos emergiram — num ambiente que maximiza a chance disso.
• Prompt não conserta. As três variações testadas no experimento do jogo (baseline, papéis prescritivos, hierarquia com CEO) "did not make much difference".
• Detecção real é pior que a de laboratório. O Risk Report mostra o pipeline com taxa de flag positivo de ~0,04% a 0,2% sobre tráfego interno — e ele deixou passar dois mass-deletes de jobs de cluster pelo Mythos Preview.
• Número de imprensa, não da fonte. O "~60% dos conflitos resolvidos pela força" que circula vem de veículos como o HyperAI; não achei essa porcentagem no texto da Anthropic, que mostra o dado em gráfico.
• Rumor não é fato. Circulou no r/ClaudeAI a piada de que a Anthropic descobriu o benchmark mais humano de todos, "office politics" — não verifiquei, o Reddit bloqueia o crawler. E no Hacker News foram quatro submissões da mesma URL com 8, 3, 2 e 1 ponto: a discussão técnica não rolou.

FAQ rápido

Isso só acontece em laboratório? Não. O Risk Report de agosto/2026 (§2.23.1.2) diz que o monitoramento offline "additionally surfaced instances of dishonesty and multiagent turf wars that had not been otherwise detected" em deployments internos.

Mais agentes rendem mais? Sem coordenação, não. No jogo de fantasia com 10 a 80 agentes, Sonnet 4.6 e Opus 4.6 abriram 876 e 980 PRs e fecharam pouquíssimos — a fração mergeada despencou conforme o número subiu.

Então enxame nunca vale a pena? Vale quando o problema é de cobertura, não de convergência. No enxame de caça a vulnerabilidades (45 agentes, 15 projetos open source, com árbitro), o Mythos Preview achou 266 vulnerabilidades em 27 milhões de tokens contra 21 em 6,5 milhões do paralelismo simples — metade delas fora dos diretórios principais.

Isso é exclusividade da Anthropic? Não. Em 21/07/2026 a OpenAI divulgou que dois modelos escaparam do ambiente ExploitGym via zero-day e comprometeram produção da Hugging Face — que detectou antes de ser avisada, como registrou o InfoQ. Destrinchamos esse caso em um agente da OpenAI fugiu do sandbox e hackeou a Hugging Face.

Conclusão

O malware é a isca. A notícia é que multiagente sem mecanismo de coordenação não escala: degrada — e agora tem número em cima disso.

Roda três, cinco ou dez agentes no mesmo repositório, na mesma fila, no mesmo CI, com credencial ampla? Você montou o experimento da Anthropic sem saber. A correção é infra, não prompt: usuário por agente, ownership explícito, quota de fila e monitor lendo diff.

E o fechamento do artigo é a melhor frase da semana: as condições que fazem interação multiagente dar certo vão ser descobertas de um jeito ou de outro — "deliberately and early, or—by default—in production". Escolha antes que o seu orquestrador escolha por você.