Agentes de IA instalam malware via `llms.txt`: entenda o risco e como se proteger
Pesquisa revela como agentes como Claude e Codex executam comandos de instalação a partir de documentação online, criando um novo vetor de ataque de supply chain em empresas.
Pesquisadores de uma startup israelense identificaram 227 comandos de instalação de código em arquivos de documentação de mais de 100 websites, incluindo os de empresas da Fortune 500. A vulnerabilidade é explorada quando agentes de inteligência artificial, como Claude, Codex da OpenAI e Hermes da Nous Research, interpretam e executam essas instruções cegamente, instalando pacotes de código não-proprietário dentro de redes corporativas. Em testes, os pesquisadores registraram um pacote apontado em um desses arquivos e, em menos de uma hora, receberam uma conexão de volta de um computador dentro de uma empresa da Fortune 500, confirmando a execução do código.
A mecânica do ataque: como llms.txt se torna uma arma
A falha reside em arquivos de texto simples, llms.txt e llms-full.txt, uma convenção emergente para que sites forneçam resumos e estruturas de conteúdo legíveis por máquina, de forma análoga ao que o robots.txt faz para os motores de busca. O problema ocorre quando esses arquivos estão mal configurados e contêm instruções para instalar pacotes de código de registros públicos como PyPI (Python) ou npm (JavaScript), mas apontam para pacotes ou domínios que não existem ou não estão registrados.
Um atacante pode identificar esses nomes de pacotes ou domínios não reclamados, registrá-los e hospedar conteúdo malicioso. Quando um agente de IA com permissão para executar comandos de shell acessa a documentação da empresa, ele a trata como uma fonte autoritativa e confiável. Ao encontrar uma linha como pip install [pacote-malicioso], o agente a executa sem questionar, instalando o malware diretamente na máquina onde está operando. Essa vulnerabilidade transforma um simples arquivo de documentação em um vetor de ataque direto à cadeia de suprimentos de software.
O experimento que acendeu o alerta
Para validar a hipótese, os pesquisadores conduziram um estudo em larga escala, analisando 6.214 domínios de empresas de defesa, Fortune 500 e Big Techs. A varredura encontrou 8.265 arquivos llms.txt e llms-full.txt, dos quais 120, em sites distintos, continham 227 comandos apontando para pacotes ou domínios não registrados. A lista de agentes identificados executando os pacotes de teste incluiu:
Gostou desta análise? Receba a próxima primeiro.
Edição diária da IA News com impacto real para empresas — grátis no seu e-mail.
- Claude: Modelo da Anthropic.
- Codex: Modelo de geração de código da OpenAI.
- Hermes: Modelo da Nous Research.
O teste de prova de conceito (PoC) foi simples e eficaz: ao registrar alguns dos nomes de pacotes órfãos e aguardar, os pesquisadores receberam dezenas de conexões de máquinas de dentro de várias empresas, confirmando que os agentes de IA estavam ativos e executando as instruções encontradas. Segundo Alon Hertz, um dos pesquisadores, “o modelo de confiança está quebrado. Os agentes tratam os documentos do fornecedor como a verdade absoluta e não os questionam — e nem os humanos que os supervisionam”.
De teoria à prática: o ataque real em clerk.com
Longe de ser uma ameaça teórica, a pesquisa descobriu pelo menos um ataque ativo explorando a vulnerabilidade. Um arquivo llms.txt no site legítimo clerk.com continha o comando npx clerk-next-fix-auth-protection. O comando npx pode buscar e executar um pacote sem adicioná-lo ao manifesto de dependências do projeto, tornando sua detecção mais difícil. Os pesquisadores descobriram que alguém já havia registrado o pacote clerk-next-fix-auth-protection e o estava usando para distribuir malware ativo. A Clerk já corrigiu o problema em seu site.
A raiz do problema: o colapso da fronteira entre dados e código
Esta vulnerabilidade expõe uma limitação fundamental dos atuais modelos de linguagem grandes (LLMs): eles não conseguem estabelecer uma fronteira confiável entre dados e instruções. Para um agente de IA, todo conteúdo que ele lê é um input, e todo input é uma instrução em potencial. Uma página de documentação, para o modelo, não é diferente de um comando direto do usuário. Como os pesquisadores escreveram, “o corpus inteiro de dados publicados que os agentes agora estão programados para consumir tornou-se silenciosamente uma superfície de execução”.
A origem dessas entradas defeituosas nos arquivos de documentação varia. Algumas são erros humanos antigos, pré-IA, que foram copiados para os novos formatos. Outras, suspeitam os pesquisadores, podem ter sido geradas por IA que alucinaram nomes de pacotes ou, ironicamente, foram elas mesmas vítimas de instruções maliciosas em outras fontes de dados.
Análise IA News
A leitura da nossa redação
Análise IA News
A descoberta de que agentes de IA podem ser induzidos a instalar malware representa mais do que uma simples vulnerabilidade de software; é uma falha sistêmica no paradigma de confiança que sustenta a automação por IA. A utilidade de um agente autônomo está diretamente ligada à sua capacidade de interagir com sistemas externos e seguir instruções. A pesquisa mostra que essa mesma capacidade, se não for rigorosamente controlada, é o seu maior ponto fraco. A premissa de que a documentação oficial de uma empresa é inerentemente segura foi quebrada.
O ataque explora uma área cinzenta entre dados e código, criando um novo e sutil vetor de ataque de supply chain. Ameaças tradicionais focam em comprometer dependências de software conhecidas. Aqui, o ataque começa muito antes, com a inserção de uma linha de texto em um arquivo de documentação aparentemente inofensivo. Ferramentas de segurança que escaneiam repositórios de código ou monitoram bibliotecas em busca de vulnerabilidades conhecidas (CVEs) são cegas para esse tipo de ameaça, pois a instrução maliciosa é executada em tempo real por um agente supostamente confiável.
Os desenvolvedores de LLMs e agentes, como Anthropic e OpenAI, têm o dever de implementar 'guardrails' mais robustos. Isso pode incluir sandboxing para a execução de qualquer código, listas de permissão estritas para registros de pacotes e a exigência de aprovação humana explícita para qualquer ação de instalação ou modificação de sistema. Os alertas gerados por essas ações não podem ser triviais, precisam ser claros sobre o risco de execução de código externo.
Para as empresas que utilizam esses agentes, a governança se torna a principal linha de defesa. É imperativo tratar agentes de IA como entidades de privilégio mínimo, restringindo seu acesso a redes, sistemas de arquivos e, crucialmente, a capacidade de executar comandos de shell. A supervisão humana, como a pesquisa aponta, é falível. A solução está em controles técnicos e políticas que impeçam a execução de comandos não autorizados por padrão, em vez de depender da vigilância de um operador.
Nos próximos meses, os decisores devem observar como os fornecedores de IA responderão a essa classe de vulnerabilidade. A solução não será um único patch, mas uma reavaliação da arquitetura de segurança para sistemas autônomos. A métrica de sucesso não será apenas o que a IA pode fazer, mas quão transparentes e controláveis são suas ações, especialmente ao interagir com o mundo exterior.
Contexto para empresários e decisores
No Brasil, a adoção de agentes de IA para automação de tarefas de desenvolvimento e análise de dados está em aceleração, impulsionada pela busca por eficiência. Contudo, a maturidade da governança de segurança para essas novas ferramentas ainda é baixa. O mercado competitivo incentiva fornecedores a liberarem funcionalidades cada vez mais autônomas, muitas vezes sem os devidos controles de segurança. Um incidente de segurança decorrente desta vulnerabilidade pode acarretar custos elevados de remediação, perdas por exfiltração de dados e danos reputacionais significativos, colocando sobre as empresas a responsabilidade integral pela avaliação e mitigação da ameaça.
Impactos para empresas
- 1Aumento do risco de supply chain attack: Comprometimento da rede corporativa através da instalação de malware por agentes de IA, contornando defesas que focam apenas em repositórios de código.
- 2Exposição de dados sensíveis e propriedade intelectual: O código malicioso executado pode exfiltrar informações confidenciais, segredos comerciais e dados de clientes, resultando em perdas financeiras e quebra de conformidade.
- 3Custos operacionais e financeiros imprevistos: Necessidade de investir em auditorias de segurança, correção de sistemas e contenção de incidentes, além da interrupção de operações críticas dependentes da IA.
- 4Erosão da confiança na automação por IA: A percepção de que agentes de IA não são seguros pode retardar a adoção de projetos de automação e inovação, colocando a empresa em desvantagem competitiva.
Conclusão editorial
A corrida para implantar agentes de IA autônomos negligenciou o princípio de nunca confiar em input externo. A recomendação é uma pausa tática, não uma paralisia: suspenda temporariamente o uso de agentes com permissão para instalar pacotes para uma auditoria de governança. Apenas com estratégias robustas de validação de fontes e privilégio mínimo a automação por IA será sustentável e segura, transformando essa vulnerabilidade em uma lição de arquitetura.
— Redação IA News
Fontes utilizadas
Apuração, análise e conclusão editorial produzidas pela redação do IA News a partir das fontes acima. O conteúdo não reproduz o texto original.