Uma investigação de segurança vinculou Claude, OpenAI Codex e os agentes de codificação Hermes da Nous Research à instalação de pacotes de software não reivindicados em ambientes corporativos. A atividade surgiu quando pesquisadores testaram arquivos de documentação que direcionavam agentes para pacotes e domínios que nenhuma organização possuía no momento.

Os resultados importam porque os comandos pareciam instruções comuns de configuração para desenvolvedores e, em vários casos, vinham de sites corporativos legítimos. Os pesquisadores disseram ter recebido um callback de uma empresa da Fortune 500 dentro de uma hora após registrar alguns nomes de pacotes e domínios abandonados para um teste de prova de conceito. As evidências não estabelecem um comprometimento generalizado, mas mostram como agentes de IA com acesso ao shell podem transformar documentação obsoleta em um ponto de entrada da cadeia de suprimentos de software.

O que os pesquisadores encontraram

De acordo com a Ars Technica AI, uma startup de segurança furtiva em Israel analisou 6.214 domínios ativos associados a contratadas de defesa, empresas da Fortune 500 e grandes empresas de tecnologia. A equipe identificou 8.265 arquivos usando as convenções emergentes llms.txt e llms-full.txt, que sites usam para fornecer descrições e navegação legíveis por máquina para sistemas de IA.

Entre esses arquivos, 120 hospedados em sites separados faziam referência a um ou mais nomes de pacotes não registrados ou domínios não reivindicados. Ao longo dos arquivos, os pesquisadores contaram 227 comandos para instalar pacotes ou acessar domínios que não tinham proprietário no momento da varredura. Muitas referências envolviam ecossistemas de pacotes comuns, incluindo PyPI e npm.

Para testar o risco, os pesquisadores registraram vários dos nomes abandonados e hospedaram pacotes projetados para contatar seu servidor quando executados. O beacon resultante identificou processos pai associados a Claude, Codex e Hermes. Os pesquisadores também receberam callbacks de algumas dezenas de organizações, incluindo algumas empresas da Fortune 500 e startups, após os pacotes de teste serem processados.

A investigação não mostrou que essas empresas estavam infectadas com malware. Mostrou que seus ambientes executaram código de prova de conceito ou, de outra forma, alcançaram a infraestrutura dos pesquisadores. Anthropic, OpenAI e Nous Research não haviam respondido aos pedidos de comentário até a publicação, segundo a Ars Technica AI.

Um problema de documentação se torna um risco de execução

A exposição vem da forma como os agentes de codificação de IA combinam navegação, recuperação e execução de comandos. Um agente pode ler a documentação de um fornecedor, tratar seu conteúdo como autoritativo e então executar o comando de configuração em um ambiente local ou corporativo. Se o pacote referenciado nunca tiver sido registrado, um atacante pode reivindicar o nome mais tarde e publicar código malicioso sob ele.

Um padrão documentado usava instruções pip install ou npm install para pacotes que não existiam. Outro fazia referência a um domínio inexistente de uma estrutura de testes. Assim, o problema de segurança não se limita a um site malicioso ou a um prompt deliberadamente envenenado. Um autor de documentação pode ter inserido anos atrás uma dependência incorreta, obsoleta ou alucinada, deixando a referência disponível para outra pessoa reivindicar.

Os pesquisadores também descreveram um caso envolvendo o site da Clerk. Um arquivo llms.txt incluía um comando npx associado a um nome de pacote que mais tarde foi reivindicado e usado para distribuir malware em atividade. Como o npx pode buscar e executar um binário de pacote sem adicioná-lo ao manifesto de dependências de um projeto, o comando criou um caminho particularmente direto para a execução.

A Clerk posteriormente corrigiu o problema na documentação. A empresa disse que usuários que já haviam instalado um pacote relacionado, @clerk/eslint-plugin, não foram expostos ao pacote malicioso nas circunstâncias que descreveu. Ainda não está claro se a confusão envolvendo a Clerk causou infecções reais.

Por que as defesas convencionais podem perder o sinal

A investigação destaca uma lacuna entre o ponto em que uma decisão insegura é tomada e o ponto em que as ferramentas de segurança corporativa normalmente procuram abuso. Um agente de codificação executando pip ou npm contra um repositório de pacotes conhecido pode se parecer com atividade normal de desenvolvimento. Ferramentas de detecção e resposta de endpoint podem ver um assistente de IA aprovado lançando um gerenciador de pacotes familiar por meio de uma conexão de rede permitida.

O problema é a relação não verificada entre a documentação e a dependência. Um agente pode confirmar que o arquivo veio de um domínio HTTPS oficial e que o comando usa um registro padrão, enquanto falha em verificar a propriedade do pacote, a identidade do publicador, a procedência ou se a dependência é esperada no projeto. Essas verificações não fazem necessariamente parte do fluxo de trabalho padrão do agente.

Isso está relacionado à injeção de prompt, mas é mais amplo em um aspecto importante. A injeção de prompt geralmente envolve instruções inseridas deliberadamente para manipular um modelo. No cenário descrito pelos pesquisadores, a instrução original pode ser genuína e benigna. O perigo aparece depois, quando um pacote ou domínio abandonado se torna disponível para um atacante.

O que isso significa para construtores de IA e equipes corporativas

Para desenvolvedores de agentes de IA, os resultados fortalecem o argumento de tratar a documentação recuperada como entrada não confiável, e não como uma extensão do comando do usuário. Agentes que podem executar comandos de shell devem separar a leitura de instruções da autorização de execução, exigir confirmação para novas dependências e verificar a propriedade e a procedência dos pacotes antes da instalação. Sandboxing e acesso restrito à rede podem reduzir as consequências quando essas verificações falham.

Equipes de produto que implantam agentes de codificação dentro das empresas enfrentam uma questão de governança mais imediata: se um assistente deve ter acesso irrestrito a repositórios internos, registros de pacotes, credenciais e sistemas próximos à produção ao mesmo tempo. Uma política útil de implantação pode permitir geração e teste de código em um ambiente isolado, enquanto bloqueia a instalação arbitrária de pacotes ou exige uma lista de dependências aprovada.

As equipes de segurança devem auditar arquivos llms.txt e llms-full.txt em seus próprios domínios, mas o risco não se limita a esses formatos. Os agentes também consomem arquivos README, guias de SDK de fornecedores, threads de issues, exemplos e documentação de terceiros. As organizações precisarão de verificação de dependências e controles de procedência em todo o caminho de recuperação, incluindo parceiros confiáveis e projetos da comunidade.

A implicação de mercado é prática, não especulativa. Assistentes de codificação de IA estão recebendo mais autoridade para agir, enquanto as defesas da cadeia de suprimentos de software ainda são amplamente projetadas para desenvolvedores humanos e sistemas de build convencionais. Quanto mais frequentemente os agentes instalarem ferramentas automaticamente, mais importante se torna registrar por que uma dependência foi escolhida e qual fonte a autorizou.

O que observar a seguir

O primeiro sinal será se Anthropic, OpenAI ou Nous Research divulgam mudanças na forma como seus agentes lidam com comandos de instalação, pacotes não registrados e instruções recuperadas. Pesquisadores de segurança e usuários corporativos também devem observar controles de registros de pacotes que sinalizem a reutilização de nomes abandonados e plataformas de agentes que adicionem verificações de procedência antes da execução.

Um segundo sinal é se as empresas auditam e corrigem sua documentação legível por máquina. A varredura dos pesquisadores mostrou que algumas entradas defeituosas antecediam a era da IA, sugerindo que a limpeza sozinha pode não resolver o problema. As equipes precisarão monitorar a propriedade dos pacotes ao longo do tempo, não apenas validar uma dependência quando a documentação é publicada pela primeira vez.

Por fim, equipes de resposta a incidentes podem procurar evidências de callbacks semelhantes ou reivindicações de pacotes fora de testes controlados. A cobertura atual demonstra exposição e pelo menos um caso de malware ativo envolvendo uma referência de documentação, mas não quantifica infecções confirmadas entre as organizações afetadas.

Perspectiva da Creati.ai

Este incidente é um aviso sobre autoridade, não apenas sobre precisão do modelo. Um agente de IA pode fazer uma solicitação tecnicamente correta a um registro de pacotes e ainda assim estar agindo com base em uma instrução insegura. Essa distinção é fácil de perder quando o comando se originou em um domínio oficial do fornecedor.

Para as empresas, a resposta sensata não é abandonar assistentes de codificação, mas restringir o que eles podem executar e exigir procedência verificável das dependências. Até que os agentes consigam distinguir de forma confiável material de referência de autorização, toda instalação automatizada deve ser tratada como uma ação sensível à segurança.