Como um repositório de terceiros pode desviar o Claude Code: 7 regras de proteção

Documentação da Ailoot: API, chaves e configuração.

Quatro percursos documentados de texto não fiável até ações do agente#

Formalmente, isto chama-se injeção indireta de prompt: uma instrução maliciosa não vem diretamente de si, mas através de dados que o agente processa durante a execução de uma tarefa — um README alheio, uma mensagem de erro, um comentário no GitHub ou uma resposta de um serviço externo. Pode esquecer o termo logo após este parágrafo; a partir daqui, vou usar linguagem simples.

Quatro exemplos de investigação discutidos abaixo:

1. Foi demonstrado como um repositório aparentemente inofensivo pode transformar-se numa shell inversa.
2. Foi demonstrado que um título de Pull Request pode sequestrar três agentes de IA diferentes ao mesmo tempo.
3. Foi demonstrado que um agente pode aceitar um relatório de erro falso do Sentry em vez de um verdadeiro.
4. A Microsoft deixou um aviso claro: a descrição de uma ferramenta MCP pode controlar o seu agente com a mesma eficácia que um prompt de sistema.

Como é que o README de um repositório inofensivo se transforma numa shell inversa?#

O mecanismo foi concebido para que nenhuma camada, por si só, pareça suspeita:

1. Clona um repositório com aspeto normal e pede ao Claude Code que o execute.
2. O repositório instala um pacote Python concebido para falhar na primeira utilização.
3. A mensagem de erro sugere educadamente um comando de “correção”: python3 -m axiom init.
4. O comando init executa setup.sh.
5. O script consulta um registo DNS TXT (normalmente usado para notas relacionadas com domínios, mas o campo aceita qualquer texto). O atacante coloca aí um comando codificado em base64 (uma forma de converter quaisquer dados em texto simples, sem espaços nem caracteres especiais) e encaminha-o diretamente para o bash.
6. O valor do registo DNS pode ser alterado a qualquer momento — o que dá ao atacante uma shell inversa interativa, com as permissões do seu utilizador e acesso a todos os segredos da máquina.

O payload demonstrado era obtido por DNS durante a execução; analisar só os bytes do repositório não revelava esse conteúdo final. Não prova que todos os scanners ou controlos sejam impotentes: inspecionar o conteúdo obtido, monitorizar processos e restringir a rede pode expor ou interromper a cadeia. A fonte é uma prova de conceito, não uma medição da frequência de incidentes reais.

Como é que o título de um Pull Request sequestrou três agentes de IA diferentes?#

O relatório de investigação descreve estes percursos e respostas; é histórico, não verifica todas as versões atuais:

A mudança de gravidade e as mitigações do relatório não estabelecem o encerramento completo de todos os payloads possíveis. O repositório PoC da investigação documenta o percurso Claude demonstrado; não execute o ataque contra sistemas reais.

Bastam duas análises para perceber o padrão: não é viável corrigir cada nova descoberta individualmente; vulnerabilidades deste tipo surgem de duas em duas semanas. Escrever explicitamente regras de segurança em CLAUDE.md e settings.json, em vez de as manter na memória, faz parte da engenharia de contexto: define-as uma vez e passam a funcionar automaticamente em cada nova sessão do Claude Code, sem lembretes. Três pilares funcionam em conjunto: clone de IA + Segundo Cérebro + Engenharia de Contexto — esta combinação transforma o Claude Code, de executor que confia em tudo, num agente com regras explícitas.

Um relatório de erro falso do Sentry pode tomar conta do seu agente?#

O ataque só precisa de uma chave DSN do Sentry — um identificador público que muitos projetos incluem diretamente no código do lado do cliente:

O mecanismo é simples: um programador pede ao agente que examine os erros abertos no Sentry; o agente solicita-os através do servidor MCP, recebe um evento malicioso misturado com os reais e interpreta o comando nele incorporado como uma instrução de confiança para corrigir o erro — porque, formalmente, foi exatamente essa a tarefa que lhe pediram.

A Tenet relata ausência de alertas dos controlos existentes nos ambientes testados. Não estabelece execução sem vestígios em todas as implementações: registos do agente e ferramentas, telemetria dos dispositivos e rede podem captar ações posteriores. O ataque começa em telemetria externa e depende depois das ferramentas e permissões efetivas do agente.

Porque é que a descrição de uma ferramenta MCP é tão perigosa como um prompt de sistema?#

A formulação da Microsoft é a mais precisa que encontrei sobre este tema:

Esta técnica chama-se envenenamento de ferramentas: uma instrução oculta na descrição de uma ferramenta aparentemente inofensiva leva o agente a agir de acordo com ela.

O Claude 3.7 Sonnet teve o melhor desempenho em termos de resistência neste teste, mas até ele recusou seguir uma instrução envenenada em menos de 3% dos casos — mesmo no melhor modelo, a resistência depende mais da sorte do que da proteção. A conclusão contraintuitiva do benchmark: quanto mais rigorosamente um modelo segue instruções, pior consegue distinguir um comando legítimo de outro oculto nos metadados — o ponto forte do modelo vira-se contra ele.

O que têm estes ataques em comum e o que pode escapar à deteção?#

Limite as capacidades efetivas do agente e inspecione as ações propostas; deteção e contenção tratam de partes diferentes do ataque.

Que proteções já tem o Claude Code — e porque não são suficientes?#

A Anthropic reconhece diretamente o problema na sua documentação, em vez de o esconder:

Segundo a documentação, o agente analisa todo o prompt à procura de instruções suspeitas, não aprova automaticamente curl e wget, mantém o conteúdo da Web numa janela de contexto separada para que não se misture com a principal e exige a confirmação de confiança na primeira execução numa nova base de código ou ao ligar um novo servidor MCP.

Mas há uma ressalva importante que a Anthropic declara sem rodeios:

Se alguma vez iniciou o Claude Code com --dangerously-skip-permissions por irritação, para que «deixasse de o chatear com perguntas», desativou todos os mecanismos que poderiam ter travado precisamente os quatro ataques aqui descritos. Deixo esta opção deliberadamente desativada, mesmo quando o Claude Code volta a perguntar pela décima vez numa sessão — é irritante, mas essas perguntas são a fronteira entre «o agente leu texto suspeito» e «o agente executou-o». Uma configuração sensata para quem não programa é o modo de permissões predefinido (default ou acceptEdits) com o sandbox ativado: as edições normais de ficheiros são feitas sem perguntas adicionais, enquanto os comandos do terminal não conseguem sair fisicamente do sandbox, mesmo que o agente tenha sido enganado.

Como ativar o modo sandbox e fechar a lacuna que deixa aberta por predefinição?#

Para o ativar permanentemente em todos os projetos, faça uma alteração em ~/.claude/settings.json:

{
  "sandbox": { "enabled": true }
}

Por predefinição, os comandos em sandbox só podem escrever no diretório de trabalho do projeto e no diretório temporário da sessão. O acesso à rede passa por um proxy — nenhum domínio é permitido antecipadamente e o Claude Code pedirá confirmação na primeira ligação a um domínio novo. A Anthropic afirma que isto reduz drasticamente os pedidos de autorização — em 84% nas medições internas da empresa — porque o sandbox trata alguns casos seguros por si, em vez de lhe perguntar sempre.

A lacuna que as definições padrão deixam aberta: por predefinição, o sandbox restringe a escrita, mas não impede a leitura de ficheiros como ~/.aws/credentials e ~/.ssh. São precisamente estes os ficheiros e as variáveis de ambiente visados pelos ataques acima. Feche essa lacuna com um bloco separado no mesmo ficheiro:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

A ideia é que, mesmo que a shell inversa da primeira análise seja aberta dentro do sandbox, estas variáveis e ficheiros são removidos fisicamente do ambiente do processo antes de este arrancar — não sobra nada para roubar.

Que regras permissions.deny deve adicionar hoje?#

Um conjunto mínimo para quem não programa, que cobre de uma só vez os principais alvos dos quatro ataques:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}

A precedência descrita na documentação Claude Code aplica-se a pedidos correspondentes às ferramentas. Não prova que um segredo seja inacessível por qualquer subprocesso ou ferramenta; use também restrições impostas no sistema de ficheiros e ambiente.

O Claude Code também tem um modo auto, no qual um modelo classificador separado verifica as ações antes de estas serem executadas — não é o mesmo modelo que conversa consigo. Por predefinição, bloqueia, entre outras coisas, exatamente o padrão «transferir código e executá-lo de imediato» (curl | bash). A Anthropic avisa expressamente que este é um modo de investigação que reduz o número de pedidos, mas não garante segurança por si só — considere-o uma camada adicional, não um substituto para o sandbox e permissions.deny.

Como verificar um repositório e um servidor MCP antes de confiar neles ao seu agente?#

Para os repositórios, eis uma lista de verificação breve antes de os entregar ao agente:

1. Não comece logo pela instalação a partir de uma ligação num e-mail, publicação ou avaliação de uma fonte desconhecida — é assim que estes repositórios são distribuídos.
2. Se a instalação produzir um erro com a instrução «execute o comando X para corrigir», leia o que o comando X realmente faz antes de permitir que o Claude Code o execute. A instrução na análise acima parecia completamente normal — esse era o objetivo.
3. Verifique a idade do repositório e o histórico de commits, não apenas o número de estrelas — é fácil atribuir estrelas falsas a repositórios acabados de criar, especificamente para este tipo de ataque.
4. Se não conhecer o repositório, execute a instalação numa máquina virtual, não no seu computador de trabalho com chaves reais. Esta é uma recomendação direta da própria Anthropic para trabalhar com serviços externos.

A posição da Anthropic sobre servidores MCP está declarada abertamente:

Isto significa que a responsabilidade de verificar servidores MCP de terceiros é sua, não da plataforma onde os instalou. Algumas equipas — sobretudo startups de segurança — já estão a desenvolver ferramentas para este fim: analisadores de configurações MCP que procuram descrições envenenadas e a “fixação” de ferramentas, que guarda o hash da descrição na primeira instalação e assinala qualquer alteração posterior. Estas tecnologias são recentes, por isso ainda é cedo para depender delas como única proteção — mas vale a pena acompanhá-las, sobretudo se ligar servidores MCP à produção. Para essas ligações, pode fixar a versão de cada pacote e registar a impressão digital das descrições das ferramentas num registo de auditoria.

7 regras de proteção: a lista de verificação de hoje#

1. Ative o modo sandbox (/sandbox ou "sandbox": {"enabled": true} em ~/.claude/settings.json) e adicione um bloco credentials que impeça a leitura de ~/.ssh e ~/.aws/credentials.
2. Adicione regras permissions.deny para impedir a leitura de ficheiros secretos e a execução de comandos bash perigosos (curl, wget, sudo) — uma regra deny sobrepõe-se sempre a uma allow.
3. Nunca execute --dangerously-skip-permissions em código alheio ou não verificado — desativa todas as proteções de uma só vez, incluindo as que poderiam ter travado precisamente estes ataques.
4. Não deixe o Claude Code executar automaticamente um comando de “correção” indicado numa mensagem de erro — leia primeiro o que realmente faz.
5. Instale servidores MCP apenas a partir de fontes em que confia e lembre-se de que a Anthropic não verifica a sua segurança por si.
6. Separe as sessões por permissões: uma trabalha com os seus dados pessoais e não vê dados externos; uma segunda analisa e-mails, repositórios e tickets de outras pessoas, mas não tem acesso a segredos; uma terceira publica externamente — e apenas aquilo que aprovou pessoalmente. Mantenho esta separação rigorosa nos meus próprios projetos: uma sessão com acesso a chaves de pagamento nunca lê tickets ou repositórios externos arbitrários, e uma sessão que analisa código de outras pessoas não vê quaisquer segredos. Não misture estas funções numa única conversa.
7. Mantenha o Claude Code e os scripts de automatização ligados atualizados — a maioria das falhas aqui discutidas já tinha sido corrigida com atualizações quando este guia foi publicado, e as novas são corrigidas de forma semelhante.

O que fazer a seguir#

Nenhuma destas camadas é uma garantia — a própria Anthropic reconhece honestamente que nenhuma proteção oferece imunidade completa. Não espero que o Claude Code reconheça, por si só, um truque numa mensagem de erro ou num comentário de issue. Para mim, o sandbox e permissions.deny fazem parte da forma como giro o contexto do projeto: aquilo que o agente vê, aquilo em que confia por predefinição e o que acontece quando comete um erro.

Se precisa de acesso a redes neuronais através da Ailoot, consulte a Ailoot.