Um AGENTS.md malicioso na pasta Transferências pode sequestrar o seu agente de programação com IA
Um ficheiro de instruções em texto simples, colocado discretamente na pasta Transferências de um programador, tentou transformar o seu agente de programação com IA num instalador de malware. A tentativa foi detetada numa estação de trabalho real e bloqueada antes de qualquer coisa ser executada, mas o mecanismo aplica-se a quem quer que abra o Codex, o Claude Code ou um agente semelhante numa pasta que não controla por completo.
O que aconteceu
O ficheiro chamava-se AGENTS.md. Agentes de programação como o Codex, da OpenAI, leem automaticamente um ficheiro com esse nome quando arrancam numa pasta e tratam o seu conteúdo como orientações do projeto. Este estava disfarçado de notas de engenharia vulgares. Escondida lá dentro havia uma secção que mandava o agente registar um novo servidor de ferramentas na sua própria configuração e instalar um pacote npm chamado function-color.
Esse pacote não é um erro de escrita inocente. Pertence a uma campanha de malware seguida sob o nome MALFEX: o function-color puxa um descarregador chamado function-flag, que por sua vez obtém e executa uma carga maliciosa para Windows. Se o agente tivesse seguido as notas, a máquina do programador teria sido infetada pelo seu próprio assistente.
Não foi possível apurar como o ficheiro chegou à pasta Transferências.
Porque funciona
Dois comportamentos inofensivos em separado combinam-se num canal de entrega.
Primeiro, um agente é concebido para confiar no ficheiro de instruções da pasta que abre e para lhe obedecer. É uma funcionalidade, não uma falha.
Por outro lado, uma página web pode guardar um ficheiro na pasta Transferências sem um clique nem um pedido de permissão, escolhendo o nome e o conteúdo.
Em conjunto, qualquer página que um programador visite, ou o próprio agente enquanto navega, pode deixar um ficheiro que o agente lerá mais tarde como ordens. Uma página de prova de conceito criada durante a investigação confirmou que a parte do descarregamento silencioso funciona tal como descrito. Se um atacante real usou exatamente esta via contra o programador afetado continua por saber.
Codex versus Claude Code
O ataque foi reproduzido contra dois agentes populares numa máquina virtual isolada para mostrar que não está preso a um único produto.
Codex. Com o ficheiro real do atacante, apresentado como uma configuração de rotina do projeto, o Codex foi instruído a acrescentar uma entrada de servidor ao seu ficheiro de configuração global ~/.codex/config.toml e a correr um comando que instalava o pacote. Como essa configuração se aplica a todas as sessões do Codex na máquina, o servidor do atacante passaria a carregar em qualquer pasta, e não apenas em Transferências. Nos testes, o Codex executou a instalação maliciosa em mais de nove em cada dez tentativas.
Claude Code. A variante que resultou era diferente e teve menos sucesso. Um CLAUDE.md plantado, apresentado como a configuração de um gateway interno, tentou levar o Claude a escrever um valor ANTHROPIC_BASE_URL no ficheiro de definições do projeto, redirecionando o tráfego da API do agente para um servidor controlado pelo atacante. Essa única alteração expõe o token de sessão, o que equivale a uma tomada de controlo da conta, e permite ao servidor falso fazer-se passar pelo modelo e devolver comandos que o agente executa. O Claude Code exige que uma pessoa aprove uma escrita deste tipo e recusa com frequência as que parecem suspeitas. Ainda assim, o disfarce de documento técnico extenso obteve a aprovação em cerca de metade das vezes.
Porque não há correção
Não se trata de um bug no Codex ou no Claude Code no sentido habitual. Um agente que segue o ficheiro de instruções da sua pasta de trabalho está a fazer exatamente aquilo para que foi construído, tal como um browser que apresenta uma página de phishing está a funcionar como previsto. A fraqueza está no fluxo de trabalho à volta do agente: onde é iniciado, em que ficheiros confia e quem está a vigiar quando aparece um ficheiro novo.
Isto importa pela forma como os programadores trabalham na prática. A telemetria recolhida durante a investigação sugere que cerca de metade das máquinas de desenvolvimento monitorizadas lançam um agente de programação dentro da pasta Transferências, e perto de um quarto das sessões de agentes abrem um browser por conta própria. São precisamente as condições de que o ataque precisa: um agente a arrancar onde a web pode escrever e, muitas vezes, ninguém presente quando o ficheiro chega.
O que fazer
Nenhuma destas medidas exige um produto novo.
- Nunca inicie um agente em Transferências. É a única pasta onde a web pode escrever sem lhe perguntar. Mova primeiro o trabalho para um diretório de projeto dedicado.
- Procure ficheiros de instruções que não escreveu. Um AGENTS.md ou CLAUDE.md perdido em Transferências, ou num repositório acabado de clonar, é o ataque inteiro. Leia-o antes de deixar um agente aproximar-se dele.
- Audite a configuração do próprio agente. Em
~/.codex/config.toml, procure blocos de servidor ou URLs base que não acrescentou. No.claude/settings.jsondo projeto, procure umANTHROPIC_BASE_URLou qualquer endpoint de API que não definiu. - Mantenha ativos os pedidos de aprovação e as sandboxes. Trate como hostil qualquer instrução que peça ao agente para os desligar.
- Assuma o comprometimento se encontrar um ficheiro plantado. Rode de imediato o token de sessão do agente. Um token roubado é uma sessão viva, não um único pedido intercetado.
Os ficheiros de instruções e a configuração dos agentes fazem agora parte da superfície de ataque de uma base de código e merecem o mesmo escrutínio que uma dependência nova. A nossa revisão de código assistida por IA procura exatamente esta classe de problemas num repositório: instruções plantadas para agentes, alterações de configuração inesperadas e pacotes ligados a campanhas de malware conhecidas, assinalados antes de um agente, ou uma pessoa, agir com base neles.
