HalluSquatting em agentes de código é o risco de um agente inventar um repositório, skill, pacote ou recurso externo, encontrar uma versão registrada por atacante e puxar esse conteúdo para dentro do loop. A falha não começa no diff. Ela começa antes, quando o agente decide de onde vem o próximo comando.

Em 8 de julho de 2026, o arXiv publicou "Beware of Agentic Botnets", com resultados de até 85% de geração de recursos alucinados em cenários de clone de repositório e até 100% em instalação de skills (arXiv, "Beware of Agentic Botnets", 2026). Para quem usa Codex, Claude Code, Gemini CLI, Copilot ou agentes com terminal integrado, a defesa é validar origem antes de executar.

Resumo prático

  • HalluSquatting transforma alucinação de nome em risco de supply chain.
  • O gate certo vem antes do clone, instalação, MCP ou shell.
  • Um subagente pesquisador pode validar origem sem permissão de escrita.
  • CI deve bloquear recurso externo novo que não aparece no lockfile.

Diagrama abstrato mostra um agente entre um repositório confiável e um recurso falso sem texto visível.

O que muda com HalluSquatting?

Em 2026, o paper "Beware of Agentic Botnets" mediu alucinações de identificadores em até 85% dos cenários de clone de repositório e até 100% em instalação de skills (arXiv, "Beware of Agentic Botnets", 2026). Isso muda a ameaça porque o agente não precisa receber um link malicioso. Ele pode buscar sozinho o recurso errado.

O ataque explora um hábito comum: pedir ao agente para "instalar a ferramenta certa", "clonar o exemplo oficial" ou "adicionar a skill recomendada". Se o modelo inventa um nome plausível, um atacante pode registrar esse nome e hospedar instruções ou código que o agente aceita como origem real.

Esse recorte complementa a quarentena de repositório para agentes de código. A quarentena pergunta se um repo desconhecido pode rodar. HalluSquatting pergunta se o repo que o agente pretende buscar existia, pertencia ao dono certo e deveria entrar no ambiente.

Cápsula citável: HalluSquatting é uma falha de origem em agentes de código: o modelo alucina um identificador externo, o atacante registra esse identificador e o agente puxa conteúdo para o loop. A defesa começa antes do clone, com verificação de dono, URL canônica e política de instalação.

Por que o agentic loop amplifica o problema?

Em 2026, a OpenAI descreveu o Codex como um harness que orquestra usuário, modelo e ferramentas dentro de um agentic loop (OpenAI, "Unrolling the Codex agent loop", 2026). No mesmo texto, a OpenAI explica que o loop pode repetir chamadas de ferramenta até chegar a uma resposta final. Esse desenho torna origem falsa muito mais perigosa.

Em uma busca manual, o desenvolvedor costuma olhar estrela, dono, domínio, README e histórico. Em um loop autônomo, o agente pode transformar uma sugestão fraca em ação: buscar, clonar, instalar, rodar teste e corrigir erro. Cada etapa parece localmente razoável, mas a cadeia inteira puxa confiança de um nome inventado.

O problema cresce quando o prompt fica longo. A OpenAI também observa que a entrada enviada ao modelo cresce ao continuar a conversa e que mudanças de ferramentas, modelo, sandbox, aprovação ou diretório podem gerar perda de cache (OpenAI, "Unrolling the Codex agent loop", 2026). Em loops de investigação com muitos logs, eu uso o RemoteCode para fazer Codex e Claude Code irem mais longe em fluxos agentic sem repetir contexto desnecessário. É uma ferramenta minha, então a recomendação aqui é editorial e ligada ao custo real de contexto.

Cápsula citável: O agentic loop amplia HalluSquatting porque uma alucinação vira sequência de tool calls. OpenAI descreve o Codex como harness de usuário, modelo e ferramentas; quando esse harness executa clone, instalação e shell, a validação de origem precisa ser uma etapa explícita do loop.

Como validar origem antes do primeiro tool call?

Em 2026, a pesquisa "Do Not Mention This to the User" analisou 98.380 skills e confirmou 157 maliciosas, com 632 vulnerabilidades distintas (arXiv, "Do Not Mention This to the User", 2026). Esse dado mostra que o risco não está só no nome alucinado. Ele também está no conteúdo instalado depois.

Use um gate de origem antes de liberar rede, escrita ou execução. O agente pode sugerir um recurso, mas outro processo precisa verificar se ele existe no domínio esperado, se pertence ao mantenedor correto, se aparece em documentação primária e se a referência bate com o ecossistema do projeto.

Um padrão prático é dividir o fluxo. Primeiro, um subagente pesquisador sem escrita coleta evidências. Depois, o agente executor só recebe URLs aprovadas. Não aceite "parece oficial" como prova. Exija origem canônica, commit ou release fixada, hash quando aplicável e justificativa curta no PR.

Fluxo abstrato mostra validação de origem antes de o agente alcançar um recurso externo sem texto visível.

# Exemplo de lockfile simples para revisar recursos externos usados por agentes.
mkdir -p .agentic
printf '%s\n' \
  'github.com/org/repo@commit' \
  'registry.example/tool@version' \
  > .agentic/resources.lock

Experiência prática: eu prefiro fazer o agente explicar por que quer um recurso antes de permitir o clone. Se a explicação depende de "vi em algum lugar" ou "é o pacote comum", o gate falha. O executor só trabalha com recursos que passaram por prova simples.

Como isolar subagentes, MCP e rede?

Em 2026, a documentação do Claude Code diz que subagentes podem ter tools como allowlist e disallowedTools como denylist, inclusive para padrões MCP como mcp__* (Claude Code Docs, "Create custom subagents", 2026). Isso permite separar pesquisa, execução e revisão com permissões diferentes.

O subagente de pesquisa deve ler docs, consultar fontes e produzir uma decisão. Ele não precisa editar arquivo, instalar pacote ou chamar MCP de escrita. Já o executor deve receber apenas recursos aprovados e trabalhar com rede desligada sempre que possível. Se precisar de rede, abra uma janela curta e registre o motivo.

Para MCP, comece negando tudo e libere servidor por servidor. Um recurso alucinado pode não parecer perigoso até o agente acoplar GitHub, navegador, cloud, banco ou ticket. O controle bom é chato: menor ferramenta possível, menor escopo possível e revisão quando o agente pedir algo fora do contrato.

Diagrama abstrato mostra subagentes com permissões separadas antes de chegar a ferramentas externas sem texto visível.

Cápsula citável: Subagentes reduzem HalluSquatting quando pesquisa e execução têm permissões diferentes. Claude Code documenta allowlist e denylist de ferramentas, incluindo padrões MCP; o pesquisador deve validar origem sem escrita, enquanto o executor recebe apenas recursos aprovados.

Onde o CI deve bloquear a cadeia?

Em março de 2026, o GitHub informou que o Copilot code review cresceu 10 vezes e já respondia por mais de uma em cada cinco revisões de código no GitHub (GitHub Blog, "60 million Copilot code reviews and counting", 2026). Com esse volume, validação de origem precisa aparecer no PR, não só na máquina local.

O CI deve falhar quando um PR adiciona clone, skill, pacote, MCP ou script externo que não aparece no lockfile de recursos aprovados. Essa checagem não decide se o pacote é "bom". Ela decide se a origem foi revisada antes de entrar no loop agentic.

Também vale registrar o caminho de execução. Se o agente adicionou um script de bootstrap, o PR precisa mostrar quais URLs ele toca, quais comandos executa e qual usuário roda o comando. Esse controle conversa com evals de PR para agentes no CI e com hooks que seguram agentes de código.

Painel abstrato mostra lockfile e validação de CI antes de aceitar recursos externos sem texto visível.

Cápsula citável: CI deve tratar recurso externo novo como mudança de supply chain. GitHub relata que o Copilot code review já aparece em mais de uma em cada cinco revisões; nesse ritmo, repos, skills, MCPs e scripts adicionados por agente precisam de lockfile e revisão explícita.

Qual checklist usar antes de deixar o agente instalar algo?

Em 2026, o paper "MalTool" construiu 1.300 ferramentas maliciosas autônomas e 5.727 ferramentas reais com comportamento malicioso embutido (arXiv, "MalTool", 2026). O número reforça uma regra simples: nome, descrição e aparência não bastam para confiar em ferramenta de agente.

Use este checklist antes de permitir que um agente clone, instale ou execute recurso externo:

  • Verifique se o recurso existe em documentação primária, não só em resposta do modelo.
  • Confirme dono, domínio, organização e histórico público do projeto.
  • Fixe commit, versão ou hash antes de executar.
  • Registre a justificativa no PR ou no log do agente.
  • Bloqueie rede depois que os artefatos aprovados forem baixados.
  • Separe subagente pesquisador sem escrita do executor com sandbox.
  • Negue MCP por padrão e libere apenas servidores necessários.
  • Faça o CI falhar quando .agentic/resources.lock não contém o novo recurso.
Sinal observado Decisão prática
Recurso existe em fonte primária e está fixado Permita com revisão normal.
Nome só aparece na fala do agente Bloqueie e peça prova de origem.
Instalação executa script remoto Exija sandbox, hash e revisão de segurança.
MCP novo aparece junto com clone desconhecido Negue a ferramenta até separar os riscos.

O erro comum é corrigir HalluSquatting com mais prompts. Prompt ajuda, mas não fecha a porta. A porta fecha quando origem, permissão, rede e CI viram controles verificáveis.

Cápsula citável: O checklist mínimo contra HalluSquatting combina origem primária, versão fixada, subagente sem escrita, sandbox sem rede, MCP negado por padrão e CI com lockfile. A defesa não depende de o modelo "lembrar melhor"; depende de o ambiente rejeitar origem não aprovada.

Perguntas frequentes (FAQ)

HalluSquatting é só typosquatting com outro nome?

Não. Em 2026, o arXiv descreveu HalluSquatting como exploração de identificadores alucinados por LLMs em aplicações agentic (arXiv, "Beware of Agentic Botnets", 2026). Typosquatting depende de erro humano de digitação. HalluSquatting depende de o agente inventar um nome plausível e puxar o recurso.

Isso afeta só skills de agentes?

Não. Em 2026, o paper reportou até 85% de geração alucinada em cenários de clone de repositório e até 100% em instalação de skills (arXiv, "Beware of Agentic Botnets", 2026). O padrão vale para repo, pacote, skill, template, plugin e qualquer recurso que o agente possa buscar.

Um subagente pesquisador resolve o risco?

Ajuda, mas não resolve sozinho. Em 2026, a documentação do Claude Code permite restringir ferramentas de subagentes com allowlist e denylist (Claude Code Docs, "Create custom subagents", 2026). Use isso para impedir escrita e MCP na etapa de pesquisa, mas mantenha lockfile e CI.

Por que colocar isso no CI?

Porque o risco escala com revisão agentic. Em 2026, o GitHub disse que Copilot code review cresceu 10 vezes e já responde por mais de uma em cada cinco revisões no GitHub (GitHub Blog, "60 million Copilot code reviews and counting", 2026). CI cria prova repetível quando o PR muda supply chain.

Fontes

  • arXiv, "Beware of Agentic Botnets: Scalable Untargeted Promptware Attacks via Universal and Transferable Adversarial HalluSquatting", consultado em 2026-07-12, https://arxiv.org/abs/2607.07433
  • arXiv, "Do Not Mention This to the User: Detecting and Understanding Malicious Agent Skills in the Wild", consultado em 2026-07-12, https://arxiv.org/abs/2602.06547
  • arXiv, "MalTool: Malicious Tool Attacks on LLM Agents", consultado em 2026-07-12, https://arxiv.org/abs/2602.12194
  • OpenAI, "Unrolling the Codex agent loop", consultado em 2026-07-12, https://openai.com/index/unrolling-the-codex-agent-loop/
  • Claude Code Docs, "Create custom subagents", consultado em 2026-07-12, https://docs.anthropic.com/en/docs/claude-code/sub-agents
  • GitHub Blog, "60 million Copilot code reviews and counting", consultado em 2026-07-12, https://github.blog/ai-and-ml/github-copilot/60-million-copilot-code-reviews-and-counting/