Pesquisa mostra como um README malicioso basta para comprometer agentes de codificação de IA durante o setup do projeto
O estudo demonstra sistematicamente que agentes de codificação de IA instalam dependências listadas em documentação de projeto (README, requirements, Makefile) sem verificar nome, origem ou histórico de vulnerabilidades, tornando a própria documentação um vetor de execução de código. Testando doze cenários em cinco classes de ataque contra harnesses de produção, os autores mostram que nomes com confusão de separador (como "azurecore" no lugar de "azure-core") e redirecionamento de registro escapam da detecção na maioria dos casos, mesmo quando typosquats óbvios são pegos.
Agentes de codificação que fazem setup automático de projetos leem arquivos como README, requirements.txt ou Makefile e instalam o que está listado ali, presumindo que a documentação do próprio projeto é uma fonte confiável — um pressuposto que os autores mostram ser falso na prática, já que basta editar esses arquivos de texto simples para redirecionar toda a instalação.
Os autores catalogaram cinco classes de ataque de supply-chain no momento de instalação de pacote, incluindo troca de nome por variante plausível (confusão de separador, como trocar um hífen por outro caractere no nome do pacote), redirecionamento para um registro de pacotes não confiável, e fixação de uma versão com vulnerabilidade conhecida já documentada. O achado mais notável é a inconsistência entre harness e modelo: o mesmo modelo de linguagem pode detectar o ataque quando roda dentro de um harness de agente e cair no mesmo ataque exato quando roda em outro harness — ou seja, a segurança no momento de instalação depende da combinação harness+modelo, não é uma propriedade só do modelo de linguagem usado.
Ataques de typosquatting clássicos, com nomes obviamente errados, já são bem detectados pelos agentes testados. Mas ataques de "ponto cego de fonte" — como redirecionamento silencioso para um registro diferente do oficial — passam despercebidos em quase todos os cenários testados, e esse padrão se repete tanto em npm quanto em Cargo, dois ecossistemas de pacotes amplamente usados. Isso significa que confiar apenas no bom senso do agente para validar dependências, sem uma verificação determinística externa, deixa uma lacuna real e replicável de execução remota de código já no momento de configurar um projeto.
Prompts de segurança explícitos no sistema reduzem parcialmente o problema, mas apenas na dimensão específica de ataque que mencionam explicitamente. Os autores mostram que uma checagem determinística pré-instalação — validando nome, origem e versão do pacote antes de qualquer código rodar — fecha a maior parte da lacuna, sugerindo que a defesa eficaz aqui é um gate mecânico fora do modelo, e não confiar no julgamento do LLM durante o setup.