AGENTS.md Malicioso: O Arquivo Que Você Escreveu Para Ajudar O Agente Pode Instalar Malware

Existe um hábito que quase todo dev tem e quase ninguém classifica como risco: baixar um zip ou clonar um repositório, abrir o terminal na pasta e chamar o agente de código para "dar uma olhada". A pasta Downloads, a área de trabalho, um diretório temporário com o material que alguém mandou por chat. É a rotina mais banal do mundo, e é exatamente a rotina que a pesquisa que li esta semana coloca no centro de um ataque.

O que me incomodou não foi a técnica em si, e sim o quanto ela se apoia numa convenção que a gente mesmo ajudou a popularizar. Passei boa parte do último ano defendendo que todo projeto deveria ter um arquivo de instruções para o agente: onde ficam os testes, como subir o ambiente, o que não mexer. O pressuposto implícito dessa defesa é que o arquivo foi escrito por alguém do time. Quando o arquivo vem de fora e se faz passar por um dos nossos, o pressuposto cai, e o agente, que foi desenhado para obedecer, obedece.

Antes de seguir, a transparência de sempre. Não reproduzi esse ataque, não rodei o pacote, não testei Codex nem Claude Code contra esses arquivos. O que sei vem de uma reportagem de 26 de outubro de 2026 baseada em pesquisa da Forever Security, da cobertura do Cyberpress e do resumo semanal do The Hacker News. Os números de taxa de sucesso, portanto, são os dos pesquisadores, obtidos em testes controlados deles, e não medidas independentes. Quando algo não estiver na fonte, vou dizer que a fonte não informa.

O caminho é este: primeiro o caso, desde a pasta Downloads até o pacote npm bloqueado. Depois a mecânica do ataque contra o Codex e a variante contra o Claude Code. Em seguida, por que um arquivo de instrução precisa ser tratado como entrada não confiável, quais defesas fazem sentido (as recomendadas pelos pesquisadores e algumas extensões minhas, rotuladas como tais) e o que ainda não sabemos.

O Caso: Do Download Ao Pacote function-color

A história começa de um jeito pouco glamouroso. Segundo a reportagem, a Forever Security bloqueou uma tentativa de um agente de IA de instalar um pacote npm malicioso chamado function-color. A instalação foi interrompida antes de qualquer código rodar, o que é o melhor desfecho possível para um incidente desse tipo. Foi ao investigar o episódio que os pesquisadores encontraram um AGENTS.md malicioso na pasta Downloads de um cliente.

Esse detalhe do lugar importa. Downloads é o diretório onde cai tudo o que vem de fora: anexo de e-mail, arquivo de chat, o zip de "exemplo do fornecedor". Não é uma pasta de projeto, ninguém a trata como código de confiança, e ainda assim é perfeitamente possível abrir um agente nela. O arquivo estava ali, com cara de documento de orientação, esperando que um agente fosse iniciado naquele diretório e o lesse como lê qualquer arquivo de instrução.

O arquivo se passava por orientação normal de engenharia. Não havia um "ignore suas instruções anteriores" gritando em maiúsculas. O texto, segundo a cobertura, mandava o agente alterar a própria configuração e preparar ferramentas controladas pelo atacante, tudo embrulhado como setup de ambiente. É o tipo de conteúdo que um humano apressado também aprovaria sem ler com atenção, porque se parece com o que esses arquivos costumam dizer.

Do lado do pacote, a Checkmarx ligou function-color à campanha npm chamada MALFEX. Pelo que foi reportado, ele embrulha o pacote function-flag, cuja rotina de instalação baixa e executa um payload para Windows. É a estrutura clássica de ataque à cadeia de suprimentos: um nome plausível, uma dependência que faz o trabalho sujo, um script de instalação que roda sem ninguém olhar. Já tratei do desenho geral desse risco em um post sobre supply chain de IA no pipeline de desenvolvimento, e o que muda aqui é o elo inicial da corrente: em vez de convencer um humano a rodar npm install, o atacante convence o agente.

Há uma lacuna que a própria reportagem admite. Os pesquisadores não conseguiram determinar como o arquivo chegou à máquina do cliente. O resumo do The Hacker News menciona que uma página web criada para isso poderia, em tese, disparar o download, mas isso é uma possibilidade descrita, não um caminho confirmado. Voltarei a essa incerteza mais adiante, porque ela muda bastante a avaliação de risco real.

Como O Ataque Funciona No Codex

A parte mais instrutiva da pesquisa é a sequência de passos contra o Codex, porque ela mostra que o ataque não depende de nenhuma vulnerabilidade de memória ou de bypass criptográfico. Depende de o agente fazer o que um arquivo de setup pede. O arquivo posava de configuração de ambiente e instruía o agente a três coisas, em ordem.

Primeiro, adicionar uma entrada de servidor MCP em ~/.codex/config.toml. Segundo, lançar outra sessão do Codex com as aprovações e as proteções de sandbox contornadas. Terceiro, rodar um comando configurado que instalava o function-color. Cada passo, isolado, parece uma tarefa de configuração. Juntos, formam uma cadeia: registrar uma ferramenta controlada pelo atacante, abrir uma sessão sem as travas, e usar essa sessão para executar a instalação.

O detalhe que mais me chama a atenção é o do segundo passo. As aprovações e o sandbox são justamente a camada que a gente espera que segure um agente enganado. Se o próprio agente pode abrir uma segunda sessão com essas camadas desligadas, a proteção deixa de ser um muro e passa a ser uma configuração que quem controla o agente pode contornar. Não tenho como afirmar, pela fonte, que mecanismo exato permitiu isso; a cobertura descreve o resultado, e eu prefiro não especular sobre o interior da ferramenta.

O segundo ponto é o escopo da mudança. Como a alteração foi feita na configuração global, em ~/.codex/config.toml, e não numa configuração de projeto, sessões futuras em outras pastas também podiam rodar o comando do atacante. Pense no que isso significa. O arquivo malicioso ficou numa pasta, mas o efeito sai dela: o agente aberto semana que vem no repositório do seu produto, que não tem nada a ver com Downloads, herda a entrada de MCP plantada. A persistência não está no arquivo original, está na configuração que o agente foi convencido a escrever.

Sobre a eficácia, a Forever reportou sucesso em mais de 90% dos testes com o Codex. Aqui cabe cuidado com a leitura. A maioria desses testes usou uma carga inofensiva, uma calculadora, justamente para provar a execução sem causar dano, e o pacote malicioso real foi testado à parte, em uma VM isolada. Isso é metodologicamente sensato, e também significa que o número mede a capacidade de executar um comando escolhido pelo atacante, não a taxa de infecção por malware em máquinas reais. É resultado de pesquisa, de um fornecedor de segurança, em ambiente que ele controla.

Um cenário hipotético ajuda a medir a distância entre o laboratório e o dia a dia. Imagine uma dev que recebe de um contato um zip com "o projeto de exemplo" e, sem pensar muito, abre o Codex na pasta extraída para entender a estrutura. Se houver um arquivo de instruções ali dentro, o agente o lê como parte do contexto. A pergunta de segurança não é se ela é descuidada; é se o fluxo normal de trabalho, aquele que qualquer um de nós repete, dá ao atacante uma chance de escrever algo.

A Variante Contra O Claude Code

A segunda demonstração da Forever mira o Claude Code e usa um CLAUDE.md forjado, o equivalente do arquivo de instruções naquela ferramenta. É uma prova de conceito dos pesquisadores, e a estrutura do ataque é parecida na lógica, mas diferente no alvo. Em vez de instalar um pacote, o objetivo foi redirecionar o tráfego.

O arquivo fez o agente gravar uma URL base de API controlada pelo atacante em .claude/settings.json. A partir daí, o tráfego de API do agente passou a ir para o servidor dos pesquisadores. Esse servidor capturou um token OAuth, e o token foi reutilizado com sucesso contra o serviço legítimo. Releia essa última parte: não foi só um vazamento teórico de credencial, a credencial capturada funcionou do outro lado.

O servidor também podia devolver instruções que levavam à execução de comandos. Isso fecha o ciclo de um jeito desconfortável. Quem controla o endpoint de API controla o que o agente "ouve" como resposta do modelo, o que dá ao atacante um canal contínuo de comando, e não apenas um golpe único. Pela descrição, o vazamento do token e a execução de comandos são consequências da mesma mudança de uma linha de configuração.

Os números dessa variante são mais modestos, e vale registrá-los com a mesma honestidade com que registrei o do Codex. O Claude aceitou a mudança de configuração em cerca de metade dos testes, e a execução via subagente aconteceu menos vezes que isso. Metade ainda é muito para uma mudança de configuração sensível, mas não é a taxa próxima de 90% do outro caso, e as duas ferramentas não são comparáveis entre si: os testes são diferentes, os objetivos são diferentes, e a fonte não detalha o número de repetições. Eu evitaria qualquer conclusão do tipo "uma ferramenta é mais segura que a outra" a partir disso.

O que as duas demonstrações compartilham é mais importante que a diferença. Em ambos os casos, o dano real vem de o agente escrever em uma configuração que governa seu próprio comportamento futuro: uma lista de servidores MCP no Codex, um endpoint de API no Claude Code. O arquivo de instrução é só o veículo. A alavanca é a capacidade do agente de modificar o ambiente onde ele próprio roda. Se você já acompanhou casos em que o agente é levado a vazar credenciais por meio do prompt, como o AgentCorruption, que cobri em outubro, o padrão é familiar: a credencial é o prêmio, e o texto que o agente lê é o caminho até ela.

Por Que Arquivo De Instrução É Entrada Não Confiável

Há uma assimetria de design por trás de tudo isso. Um agente de código é construído para tratar o conteúdo de certos arquivos como instrução com autoridade. É o ponto do AGENTS.md: dizer ao agente como se comportar naquele projeto. Só que, do ponto de vista do modelo, um texto em markdown não carrega certificado de origem. O arquivo escrito pelo seu tech lead e o arquivo plantado por um atacante na pasta Downloads têm a mesma forma, o mesmo tom, e chegam pelo mesmo canal.

Quando expliquei a lógica dos steering files e do AGENTS.md num projeto agêntico, defendi o formato como contrato entre o time e o agente. Continuo achando que é útil. O que esse caso ensina é que o contrato só vale se a procedência do arquivo vale. Um arquivo de instrução é, na prática, código executável em linguagem natural: ele decide o que uma ferramenta com acesso ao seu shell e às suas credenciais vai fazer. Ninguém executa um script baixado de origem desconhecida sem ler; o mesmo critério deveria valer para o arquivo que dirige o agente.

O modelo de ameaça, então, não exige nada sofisticado. Exige que o atacante consiga colocar um arquivo de instruções onde o agente vai olhar, e que o agente tenha permissão de mexer em configuração, de rodar comandos ou de abrir outra sessão. Os pesquisadores não sabem como o arquivo chegou à máquina do cliente, e o resumo do The Hacker News sugere uma página web que dispararia o download. Se esse tipo de entrega for viável em escala, a barreira de entrada do ataque é baixa. Se não for, o risco concentra-se em quem baixa material não confiável, o que continua sendo muita gente.

O resumo do The Hacker News da semana de 26 de outubro coloca o caso numa categoria maior, a dos agentes sequestrados ou rogue. No mesmo resumo aparecem registros que, vistos juntos, desenham um período em que o agente de IA é tratado como superfície de ataque e como ator ao mesmo tempo: bancos dos Estados Unidos detectando agentes de IA de terceiros operando em contas de clientes e restringindo ou liberando apenas leitura, segundo o Axios; a CrowdStrike relatando quatro atores usando Claude Code para tomar decisões e executar comandos; e a Rapid7 dizendo que 8% dos relatos de ameaça citam IA como componente operacional. São números de fornecedores e de imprensa, e não sei como cada um foi medido. Há também uma cobertura em tempo real da Fox News sobre os bancos e os agentes de IA, de 28 de outubro, que trata do mesmo tema. Em junho, o próprio The Hacker News já tinha publicado uma matéria cujo título descreve um ataque de "agentjacking" enganando agentes de código para rodar código malicioso; cito só como sinal de que o assunto não é novo, sem atribuir detalhes a ela, porque não li o conteúdo.

Defesas Práticas

Separo esta seção em duas partes, para não misturar o que veio da pesquisa com o que é inferência minha. As recomendações da Forever, segundo a cobertura, são cinco e relativamente simples. Não iniciar agentes de código na pasta Downloads. Inspecionar arquivos AGENTS.md e CLAUDE.md desconhecidos antes de usá-los. Revisar a configuração do Codex em busca de servidores MCP inesperados. Verificar as configurações do Claude em busca de endpoints ou proxies desconhecidos. E manter ligados os prompts de aprovação e os controles de sandbox.

Cada uma delas ataca um passo específico da cadeia. Não abrir o agente em Downloads reduz a chance de o arquivo plantado ser lido. Inspecionar arquivos de instrução desconhecidos corta o veículo. Revisar ~/.codex/config.toml e .claude/settings.json detecta o que já foi plantado. E manter aprovações e sandbox é a rede de segurança. Perceba que a última só funciona se o agente não puder desligá-la sozinho, o que o caso do Codex questiona.

Agora as extensões minhas, que são raciocínio sobre as recomendações e não achados da pesquisa. A primeira: tratar os arquivos de configuração global do agente como arquivos sensíveis, no mesmo grau de um ~/.ssh/config ou de um ~/.npmrc. Quem faz backup ou versiona dotfiles pode colocar ~/.codex/config.toml e as configurações do Claude sob controle de versão e olhar o diff de vez em quando. Uma mudança inesperada numa lista de servidores MCP ou numa URL base de API é exatamente o tipo de coisa que um diff revela em segundos. Não testei isso; é a aplicação de uma prática conhecida a um arquivo novo.

A segunda: separar o lugar onde se abre o agente do lugar onde se guarda material não confiável. Um cenário hipotético seria um time que define uma pasta de trabalho dedicada para código de terceiros, aberta apenas em máquina virtual ou contêiner descartável, e proíbe iniciar agentes com acesso à configuração real do usuário em qualquer outra origem. A VM isolada que os próprios pesquisadores usaram para testar o pacote real é a versão profissional dessa ideia.

A terceira: pensar em credenciais como se o agente fosse comprometível. Tokens de curta duração, escopo mínimo e rotação reduzem o valor do que um endpoint falso consegue capturar. Isso vale para a variante do Claude Code, em que o token capturado funcionou do outro lado. E a quarta, para quem tem responsabilidade de AppSec: incluir arquivos de instrução na revisão de código e na análise de repositórios de terceiros. Se o time já escaneia dependências, faz sentido escanear também os AGENTS.md, CLAUDE.md e equivalentes que chegam com um repositório clonado, procurando instruções que mexam em configuração, abram sessões ou instalem pacotes. Um caso anterior que cobri, o GhostApproval, sobre symlinks e agentes de código, vai na mesma direção: o que o agente alcança importa tanto quanto o que ele lê.

O Que Ainda Não Sabemos

A lista de incertezas é longa, e acho que vale enumerá-la para evitar tanto o alarmismo quanto a complacência. A primeira e mais importante: como o arquivo chegou à máquina do cliente. Os pesquisadores não conseguiram determinar. A hipótese da página web é possível em tese, segundo o resumo do The Hacker News, mas não foi demonstrada como a origem. Sem isso, não dá para saber se o vetor é um descuido individual, uma campanha dirigida ou uma entrega automatizada.

A segunda: a escala real. A reportagem descreve um arquivo encontrado em um cliente e testes controlados da Forever. Não encontrei, nas fontes que li, qualquer número de quantas máquinas receberam esse tipo de arquivo ou de quantos agentes chegaram a executar a cadeia fora do laboratório. A tentativa de instalação do function-color foi bloqueada antes de rodar código; isso é um dado a favor das defesas, mas também mostra que o ataque foi interrompido, não que seja raro.

A terceira: o quanto os resultados de laboratório se transferem. A taxa acima de 90% no Codex foi medida majoritariamente com carga inofensiva; a taxa de cerca de metade no Claude Code é de uma prova de conceito com um arquivo forjado. Nenhuma das duas é uma medida de comportamento em produção com usuários reais, com versões atualizadas das ferramentas e com as configurações que cada pessoa escolhe. As ferramentas também mudam rápido: não sei dizer, pela fonte, se os fornecedores já ajustaram algo em resposta, e não vou supor.

A quarta: a relação com a campanha MALFEX. A Checkmarx ligou o function-color a ela, e o function-flag carrega um payload para Windows. Mas a fonte não diz se os operadores da campanha são os mesmos que criaram o arquivo de instruções, nem se o AGENTS.md malicioso faz parte de uma estratégia deliberada de atingir agentes de código ou se é uma peça isolada. Ligar as duas coisas com firmeza seria ir além do que foi reportado. Para acompanhar o assunto semana a semana, existe a série "Last week in Agent Security" na DEV Community; cito só como lugar de acompanhamento, sem atribuir a ela nenhum fato deste texto.

Conclusão

O que esse caso me deixa não é medo de arquivo markdown, é uma revisão de premissa. Escrevemos arquivos de instrução para ajudar o agente, e eles ajudam, mas estamos tratando um canal de comando como se fosse um canal de documentação. A diferença é a procedência: um AGENTS.md que passou por pull request no seu repositório tem uma história de revisão; um que apareceu numa pasta de downloads não tem nenhuma, e para o agente os dois podem parecer idênticos.

Reconheço os limites do que escrevi. Estudei uma reportagem, a pesquisa de um fornecedor e dois resumos de imprensa, e não reproduzi nada disso. Os percentuais são dos pesquisadores, em testes que eles desenharam. É possível que o risco real, hoje, seja menor do que o título sugere, e também é possível que seja maior, se a entrega por página web se mostrar viável. Não tenho como decidir entre essas hipóteses com o que li, e desconfio de qualquer um que diga que tem.

Minha posição prática é modesta e barata: não abrir agente em pasta de procedência desconhecida, ler antes de confiar em qualquer arquivo de instrução que não seja do time, olhar de vez em quando as configurações globais do agente e deixar aprovações e sandbox ligados. Nenhuma dessas coisas é sofisticada, e é justamente por isso que vale fazê-las. O arquivo que a gente escreveu para o agente trabalhar melhor merece o mesmo respeito que damos a um script: confiar nele só depois de saber de onde veio. Mesmo o post que escrevi em 26 de outubro sobre memória do Grok Build e AGENTS.md defendia o arquivo versionado pela auditabilidade, e este caso mostra o outro lado da mesma moeda: auditabilidade só protege quem de fato audita.

Fontes:

AGENTS.md Malicioso: O Arquivo Que Você Escreveu Para Ajudar O Agente Pode Instalar Malware

AGENTS.md Malicioso: O Arquivo Que Você Escreveu Para Ajudar O Agente Pode Instalar Malware

O Caso: Do Download Ao Pacote function-color

Como O Ataque Funciona No Codex

A Variante Contra O Claude Code

Por Que Arquivo De Instrução É Entrada Não Confiável

Defesas Práticas

O Que Ainda Não Sabemos

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose