Os agentes de codificação baseados em inteligência artificial estão transformando o desenvolvimento de software, mas também introduzem riscos de segurança que nem sempre são evidentes. Uma pesquisa da Forever Security chama a atenção para uma técnica capaz de manipular ferramentas como OpenAI Codex, Claude Code e Cursor CLI por meio de arquivos Markdown maliciosos armazenados na pasta de downloads do usuário.
O ataque explora uma combinação perigosa: navegadores que salvam arquivos em diretórios predefinidos e assistentes de programação que interpretam arquivos locais como fontes legítimas de instruções. Dependendo do contexto de execução e das permissões concedidas, um documento aparentemente inofensivo pode influenciar o comportamento de um agente, provocar ações não autorizadas e colocar credenciais de desenvolvimento em risco.
O problema não depende necessariamente da exploração de uma vulnerabilidade tradicional no código dos agentes. O risco está na maneira como essas ferramentas interpretam instruções, acessam arquivos e executam comandos dentro do ambiente do desenvolvedor. Isso demonstra por que a segurança de sistemas com IA precisa considerar não apenas o modelo utilizado, mas também os diretórios acessíveis, as permissões concedidas e a origem dos dados processados.
Como funciona o sequestro de agentes de codificação
Arquivos como AGENTS.md e CLAUDE.md desempenham funções legítimas nos ambientes de desenvolvimento assistidos por inteligência artificial. Eles permitem registrar convenções de programação, instruções para executar testes, padrões arquiteturais, regras de formatação e orientações específicas para determinadas tarefas.
Em vez de repetir essas informações a cada interação, o desenvolvedor pode mantê-las em arquivos Markdown que o agente consulta durante o trabalho. Essa abordagem melhora a consistência das alterações e facilita a colaboração entre equipes.
Entretanto, essas instruções também podem se tornar um vetor de ataque quando o agente confia em conteúdo cuja origem não foi verificada. Um arquivo manipulado pode incluir ordens para executar comandos, acessar determinados diretórios ou transmitir informações para destinos externos.
O perigo aumenta quando o assistente possui acesso ao terminal, consegue ler arquivos pessoais ou recebeu autorização para utilizar credenciais armazenadas no ambiente. Nesse cenário, uma instrução maliciosa pode transformar uma tarefa aparentemente simples em uma tentativa de comprometimento do ambiente de desenvolvimento.
A técnica é especialmente preocupante porque não exige necessariamente que o desenvolvedor abra um projeto desconhecido ou execute manualmente um script suspeito. Dependendo do funcionamento da ferramenta, o simples início de uma sessão em determinado diretório pode colocar as instruções maliciosas no contexto do agente.
O perigo da pasta Downloads e do download silencioso
A pasta ~/Downloads é um alvo conveniente porque representa um dos destinos mais comuns para arquivos obtidos pela internet. Em muitos sistemas, navegadores utilizam esse diretório como local padrão para salvar documentos, arquivos compactados e outros conteúdos baixados.
O risco surge quando um agente de codificação é iniciado diretamente nessa pasta, em vez de ser executado dentro de um projeto específico e controlado.
Se o agente procurar instruções no diretório atual ou em arquivos que estejam disponíveis em seu contexto de trabalho, um documento malicioso poderá ser interpretado como parte das orientações da sessão. A possibilidade concreta depende das regras de descoberta de arquivos, da hierarquia de diretórios e do comportamento de cada ferramenta.
Uma página web maliciosa pode tentar explorar o processo de download para colocar um arquivo especialmente preparado nesse local. Alguns navegadores e configurações permitem iniciar downloads sem apresentar uma pergunta a cada arquivo, embora existam proteções contra downloads automáticos e comportamentos suspeitos. Portanto, o download silencioso não funciona de maneira idêntica em todos os navegadores ou configurações.
O ponto decisivo é a combinação entre a origem do arquivo e o contexto em que ele será interpretado. Um documento chamado AGENTS.md pode parecer uma configuração técnica comum, mas seu conteúdo pode conter instruções destinadas a manipular o comportamento de um assistente.
Imagine um desenvolvedor que abre o terminal na pasta de downloads para testar rapidamente uma ferramenta de IA. Se houver um arquivo de instruções malicioso nesse diretório e o agente o incorporar ao contexto, a sessão poderá começar com orientações que o usuário nunca pretendeu autorizar.
Esse cenário evidencia uma falha de procedimento que pode passar despercebida: um diretório de armazenamento temporário não deve ser tratado como um ambiente confiável para executar agentes com permissões amplas.
Casos reais: do pacote npm malicioso ao comprometimento de tokens OAuth
A pesquisa descrita pela Forever Security também chama a atenção para o histórico de ataques à cadeia de suprimentos de software, nos quais arquivos e componentes aparentemente legítimos são utilizados para introduzir instruções ou comportamentos maliciosos.
Um exemplo citado nesse contexto é o pacote npm function-color, associado a um incidente de segurança envolvendo conteúdo malicioso. Casos dessa natureza demonstram como dependências e artefatos de desenvolvimento podem servir de ponto de entrada para ataques, especialmente quando são incorporados a fluxos de trabalho automatizados sem verificação suficiente.
É importante distinguir, porém, os mecanismos envolvidos: um pacote malicioso distribuído por um gerenciador de dependências não representa necessariamente o mesmo vetor de ataque que um arquivo Markdown colocado na pasta de downloads. A conexão está no princípio de confiança indevida em conteúdo externo, não na equivalência entre os métodos de infecção.
Nos testes atribuídos à Forever Security, a pesquisa também descreve tentativas de induzir agentes a executar ações locais. Em um dos cenários, o OpenAI Codex teria executado a calculadora do sistema em aproximadamente 90% das tentativas realizadas nas condições avaliadas.
Esse resultado deve ser interpretado como uma observação experimental, e não como uma taxa universal de sucesso contra todas as instalações do Codex. O comportamento pode variar conforme a versão, as permissões, as configurações de segurança, o contexto de execução e as confirmações exigidas para executar comandos.
O impacto potencial é mais grave quando as instruções procuram acessar informações sensíveis. No caso do Claude Code, a pesquisa relata testes envolvendo o roubo de tokens OAuth, credenciais utilizadas para autenticar usuários ou aplicações em determinados serviços.
Tokens desse tipo podem permitir acesso a recursos protegidos sem que seja necessário conhecer a senha original da conta. O alcance de um eventual comprometimento depende das permissões associadas ao token, de sua validade e dos controles implementados pelo serviço.
Se um agente tiver acesso a credenciais armazenadas no ambiente e for induzido a expô-las, as consequências podem incluir acesso não autorizado a repositórios, serviços de desenvolvimento e outros recursos corporativos. Em ambientes empresariais, isso também pode facilitar ataques subsequentes contra sistemas internos.
Por isso, a proteção de agentes de codificação precisa abranger tanto a execução de comandos quanto o acesso a segredos e credenciais.
Por que isso não é considerado um bug pelos fabricantes
Uma das questões mais importantes dessa técnica é a distinção entre uma vulnerabilidade no software e o uso indevido de funcionalidades que operam conforme o projeto original da ferramenta.
Agentes como Claude Code, OpenAI Codex e Cursor CLI precisam interpretar instruções para executar tarefas de desenvolvimento. Ler arquivos de configuração, consultar documentação e utilizar o terminal são comportamentos esperados em ferramentas que automatizam parte do trabalho de programação.
O problema aparece quando essas capacidades são utilizadas em um contexto inadequado. Se um agente encontra um arquivo Markdown contendo instruções maliciosas e o interpreta como uma orientação legítima, ele pode agir de maneira tecnicamente compatível com suas regras de funcionamento, mas contrária à intenção do usuário.
Isso não significa que todo comportamento desse tipo seja inevitável ou que os fabricantes não tenham responsabilidades na implementação de mecanismos de proteção. Sistemas de IA precisam estabelecer limites claros para a execução de comandos, o acesso a arquivos e a utilização de informações potencialmente sensíveis.
Entretanto, a segurança também depende de como o usuário organiza o ambiente e define os privilégios disponíveis para o agente.
Um assistente executado dentro de um repositório isolado, com acesso restrito aos arquivos necessários, apresenta uma superfície de risco diferente daquela de um agente iniciado no diretório pessoal do usuário, onde podem existir chaves de acesso, configurações de serviços, documentos privados e outros dados importantes.
Outro aspecto relevante é a diferença entre instruções e permissões. Um arquivo Markdown pode solicitar que o agente leia um documento confidencial, mas isso não significa que a operação deva ser autorizada automaticamente. A ferramenta precisa respeitar os limites de acesso, as políticas de segurança e as confirmações exigidas para ações sensíveis.
Da mesma forma, a capacidade de executar comandos não deve ser confundida com autorização irrestrita para realizar qualquer operação solicitada por um arquivo local.
Para os desenvolvedores, a principal lição é não presumir que um agente seja capaz de distinguir perfeitamente todas as instruções legítimas das tentativas de manipulação. A confiança no conteúdo precisa ser acompanhada por controles técnicos que limitem o impacto de decisões incorretas.
Boas práticas para blindar seu ambiente de desenvolvimento
A proteção contra arquivos Markdown maliciosos exige medidas que reduzam a exposição dos agentes e impeçam que instruções inesperadas resultem em acesso indevido a recursos importantes.
Não existe uma configuração única capaz de eliminar todos os riscos, mas algumas práticas ajudam a construir uma defesa em profundidade.
1. Execute os agentes somente na raiz de projetos confiáveis
Evite iniciar agentes de codificação diretamente em ~/Downloads, no diretório pessoal ou em outras pastas que misturem arquivos de diferentes origens.
Prefira abrir o terminal na raiz de um repositório conhecido e verificado. Antes de iniciar o assistente, confirme o diretório atual e examine os arquivos de instruções presentes no projeto.
No Linux, comandos como pwd e ls -la ajudam a verificar o diretório de trabalho e identificar arquivos ocultos ou inesperados.
Também é importante compreender como cada ferramenta procura arquivos de instruções. Alguns agentes podem consultar arquivos em diretórios superiores ou aplicar configurações herdadas, de modo que estar dentro de um projeto não garante, isoladamente, que todas as instruções externas sejam ignoradas.
2. Configure o navegador para perguntar onde salvar arquivos
Sempre que possível, habilite a opção que solicita o local de destino antes de cada download.
Essa configuração reduz a possibilidade de páginas maliciosas colocarem arquivos inesperados em diretórios utilizados por ferramentas de desenvolvimento. Ela não substitui outras proteções, mas acrescenta uma etapa de verificação antes que o conteúdo seja armazenado.
Também evite autorizar downloads automáticos indiscriminadamente. Revise as permissões concedidas aos sites e mantenha o navegador atualizado.
Arquivos recebidos de fontes desconhecidas devem ser tratados como potencialmente não confiáveis, mesmo quando possuem extensões comuns, como .md, .txt ou .json.
3. Revise arquivos AGENTS.md e CLAUDE.md desconhecidos
Antes de iniciar uma sessão, examine arquivos de instruções encontrados em repositórios clonados, arquivos compactados extraídos ou diretórios compartilhados.
Procure orientações que solicitem operações desnecessárias, como:
- Executar comandos de shell sem relação com a tarefa.
- Ler arquivos de configuração pessoal ou credenciais.
- Transmitir dados para servidores externos.
- Desativar mecanismos de segurança.
- Instalar dependências ou executar scripts de origem desconhecida.
- Modificar arquivos fora do escopo do projeto.
Esses sinais não comprovam, individualmente, que um arquivo seja malicioso. Algumas operações podem ser legítimas em determinados projetos. O importante é avaliar a necessidade de cada instrução e verificar se ela corresponde ao objetivo do trabalho.
Nunca considere um arquivo confiável apenas porque seu nome corresponde ao padrão utilizado por uma ferramenta de IA.
4. Utilize sandboxes e containers de isolamento
Uma das medidas mais eficazes é executar agentes em ambientes isolados, utilizando tecnologias como Docker, máquinas virtuais ou mecanismos de sandbox compatíveis com o sistema operacional.
O objetivo é limitar o que o agente consegue acessar caso receba instruções maliciosas. Um container configurado corretamente pode restringir o acesso ao sistema de arquivos, reduzir privilégios e separar o ambiente de desenvolvimento dos dados pessoais do usuário.
Entretanto, a simples utilização de Docker não garante isolamento completo. Containers executados com privilégios elevados, acesso irrestrito ao socket do Docker ou montagens amplas do sistema de arquivos podem permitir que um comprometimento ultrapasse os limites esperados.
Prefira executar os agentes sem privilégios administrativos, disponibilizar apenas os diretórios necessários e evitar a montagem de pastas que contenham credenciais.
Quando possível, utilize ambientes descartáveis para tarefas envolvendo código desconhecido. Assim, alterações suspeitas podem ser investigadas sem expor diretamente o sistema principal.
5. Restrinja o acesso a tokens OAuth e outras credenciais
Tokens de autenticação, chaves de API e credenciais de serviços devem permanecer fora do alcance desnecessário dos agentes.
Evite disponibilizar arquivos completos de configuração pessoal dentro de ambientes automatizados. Utilize mecanismos específicos de gerenciamento de segredos e conceda somente as permissões indispensáveis para cada tarefa.
Também é recomendável separar credenciais de desenvolvimento e produção, limitar a validade dos tokens quando houver suporte e revisar periodicamente as permissões concedidas às aplicações.
Se houver suspeita de comprometimento, revogue os tokens potencialmente expostos, gere novas credenciais e examine os registros de acesso dos serviços envolvidos.
A investigação deve considerar não apenas os comandos executados pelo agente, mas também eventuais conexões externas e alterações realizadas no repositório.
O futuro da segurança em ferramentas autônomas de IA
A técnica descrita pela Forever Security evidencia um desafio crescente para a segurança de aplicações baseadas em inteligência artificial: os agentes não trabalham apenas com código, mas também interpretam instruções, acessam arquivos e interagem com sistemas externos.
Essa combinação amplia as possibilidades de automação, mas também cria novas formas de manipular o comportamento das ferramentas. Ataques de injeção indireta de prompt podem explorar informações recebidas de documentos, páginas web, repositórios e outros conteúdos que o modelo interpreta durante a execução de uma tarefa.
O risco se torna mais significativo quando essas informações podem influenciar agentes com acesso ao terminal, permissões para modificar arquivos ou capacidade de utilizar credenciais.
Por isso, a segurança dos assistentes de programação precisa evoluir em diferentes frentes. Fabricantes devem aprimorar os controles de execução e a separação entre instruções confiáveis e conteúdo externo. Desenvolvedores, por sua vez, precisam adotar ambientes restritos, revisar configurações e limitar privilégios.
Para equipes de segurança e administradores de sistemas Linux, isso também representa uma oportunidade de incorporar agentes de IA às políticas existentes de controle de acesso, auditoria e isolamento de processos.
A principal lição é simples: um agente de codificação não deve receber mais acesso do que o necessário para realizar seu trabalho. Quanto menores forem seus privilégios, menor será o impacto potencial de uma instrução maliciosa.
