- O que é o llms.txt e por que ele importa?
- O experimento mostrou que o risco não era apenas teórico
- O perigo está na confiança automática
- Um novo tipo de supply chain está surgindo
- 1. Tratar documentação externa como dado não confiável
- 2. Reduzir permissões
- 3. Verificar dependências antes da instalação
- 4. Isolar ambientes de execução
- 5. Monitorar conexões inesperadas
- O problema também é para quem publica llms.txt
- A pergunta que fica para empresas e desenvolvedores
Principais destaques
- 120 arquivos
llms.txt e llms-full.txt encontrados em sites de empresas apontavam para pacotes ou domínios que não estavam registrados.
- Pesquisadores registraram alguns desses nomes e receberam conexões de empresas da Fortune 500 e startups, depois de agentes de programação processarem as referências.
- Claude, Codex e Hermes apareceram na cadeia de processos observada, levantando uma questão maior: até onde um agente de IA deve confiar na documentação que encontra na internet?
Arquivos criados para ajudar agentes de IA a entender sites podem estar criando uma nova porta de entrada para ataques. Pesquisadores encontraram referências abandonadas em mais de 100 domínios e conseguiram observar empresas reais acessando os recursos controlados no experimento.
O problema não começou com um malware
O cenário parece, à primeira vista, bastante simples.
Um site publica um arquivo de texto para explicar sua estrutura a agentes de inteligência artificial. O agente consulta esse arquivo, encontra uma referência para um pacote de software e tenta utilizá-lo.
Só que o pacote não existe mais.
Ou, pior, nunca pertenceu a quem o agente imaginava.
Foi justamente essa situação que pesquisadores de uma startup israelense investigaram. Eles analisaram 6.214 domínios ativos associados a grandes empresas de tecnologia, companhias da Fortune 500 e contratantes do setor de defesa.
Ao todo, encontraram 8.265 arquivos llms.txt e llms-full.txt. Muitos dos sites possuíam os dois formatos.
Dentro desse conjunto, 120 arquivos, hospedados em 120 sites diferentes, apontavam para pacotes de código ou domínios que não estavam registrados.
O número pode parecer pequeno diante de milhares de arquivos analisados. O detalhe importante é outro: esses nomes disponíveis poderiam ser assumidos por qualquer pessoa.
E foi exatamente isso que os pesquisadores fizeram para testar o risco.
O que é o llms.txt e por que ele importa?
O llms.txt é uma convenção relativamente nova criada para oferecer aos sistemas de inteligência artificial uma representação mais organizada de um site.
A proposta é facilitar a vida de agentes que precisam navegar pela web, encontrar documentação, compreender a estrutura de um serviço ou localizar informações relevantes sem necessariamente percorrer todas as páginas disponíveis.
A comparação mais simples é com o conhecido robots.txt.
O arquivo utilizado por sites para orientar mecanismos de busca informa, por exemplo, quais áreas devem ou não ser rastreadas. Já o llms.txt tenta fornecer contexto para modelos de linguagem e agentes de IA.
A diferença se torna especialmente importante agora que os sistemas deixaram de apenas responder perguntas.
Um chatbot tradicional lê uma página e produz uma resposta.
Um agente de IA, dependendo das permissões que recebeu, pode ler a página, interpretar uma instrução, abrir um terminal, instalar uma dependência, modificar um arquivo e executar um programa.
É aí que a fronteira entre informação e ação começa a ficar perigosa.
De texto para ação
Imagine um desenvolvedor pedindo a um agente:
“Configure esta biblioteca no meu projeto.”
O agente pesquisa documentação na internet. Encontra o site oficial. Lê o llms.txt. Localiza uma dependência. Consulta o gerenciador de pacotes e tenta instalar o componente.
Para o modelo, o caminho pode parecer perfeitamente lógico.
O problema é que o texto que orientou essa decisão não necessariamente é uma fonte de confiança suficiente para autorizar uma execução.
Uma pesquisa acadêmica publicada em 2026 sobre segurança de agentes descreve justamente essa mudança de cenário: sistemas capazes de consultar informações externas e acionar ferramentas ampliam o ataque para o momento em que o agente está executando uma tarefa, e não apenas para o software que foi previamente instalado.
O experimento mostrou que o risco não era apenas teórico
Os pesquisadores decidiram descobrir o que aconteceria se alguém assumisse alguns daqueles nomes abandonados.
Eles registraram uma seleção dos domínios e pacotes que estavam disponíveis e colocaram neles um código criado para o experimento.
A função era simples: quando uma máquina instalasse o pacote, o servidor dos pesquisadores receberia uma comunicação.
Não era necessário roubar dados.
Não era necessário explorar uma vulnerabilidade sofisticada.
O objetivo era responder a uma pergunta muito mais básica:
algum agente realmente tentaria instalar aquilo?
A resposta veio rapidamente.
Segundo os pesquisadores, menos de uma hora depois, uma empresa da Fortune 500 entrou em contato com a infraestrutura usada no teste.
Depois vieram outras.
Ao longo do experimento, foram observadas conexões de algumas dezenas de empresas, incluindo mais companhias da Fortune 500 e startups.
O resultado muda completamente a natureza do problema.
Não se tratava apenas de encontrar documentação incorreta.
Havia sistemas corporativos capazes de transformar uma referência abandonada em uma ação real.
A cadeia de processos revelou algo ainda mais importante
Os pesquisadores não ficaram apenas olhando para as conexões recebidas.
Eles também analisaram a cadeia de processos responsável pela instalação.
Essa análise permitiu identificar quais programas estavam envolvidos antes que o pacote chegasse ao estágio de execução.
Entre os agentes observados estavam:
Claude, da Anthropic
Codex, da OpenAI
Hermes, da Nous Research
A presença desses sistemas não significa, por si só, que os produtos tenham uma vulnerabilidade específica ou que seus desenvolvedores tenham criado deliberadamente um mecanismo inseguro.
O ponto levantado pela investigação é mais amplo.
Agentes de programação foram colocados em situações nas quais uma fonte externa de informação acabou influenciando uma ação executável.
Anthropic, OpenAI e Nous Research não haviam respondido aos pedidos de comentário dos pesquisadores até a publicação original.
O ataque se parece com um problema antigo, mas tem uma diferença nova
A ideia de assumir um domínio ou pacote abandonado não nasceu com a inteligência artificial.
A segurança digital já conhece há anos problemas envolvendo domínios expirados, dependências abandonadas e pacotes que deixam de ser controlados pelos seus proprietários.
Um domínio que desaparece pode ser registrado novamente.
Um pacote pode ser abandonado.
Uma aplicação antiga pode continuar apontando para um endereço que ninguém mais controla.
Em determinadas situações, um atacante consegue assumir esse recurso e colocá-lo novamente em circulação.
O risco é conhecido em ataques de cadeia de suprimentos.
Estudos sobre segurança de software também mostram que domínios antigos podem continuar presentes em integrações, redirecionamentos, sistemas de autenticação e outros componentes mesmo depois de terem deixado de ser administrados pelos proprietários originais.
A IA acrescenta uma nova camada
A novidade está no intermediário.
Antes, um desenvolvedor precisava encontrar aquele pacote, decidir utilizá-lo e executar o processo.
Agora, um agente pode fazer parte desse caminho.
Ele pode:
- encontrar a documentação;
- interpretar o conteúdo;
- procurar uma dependência;
- decidir como instalá-la;
- executar o comando;
- continuar a tarefa automaticamente.
Isso cria uma espécie de cadeia de confiança invisível.
O usuário confia no agente.
O agente confia na documentação.
A documentação aponta para um recurso.
O recurso pode estar abandonado.
E o software instalado passa a fazer parte do ambiente corporativo.
O elo mais fraco pode estar escondido em uma linha de texto que ninguém considerou uma instrução de segurança.
O perigo está na confiança automática
Alon Hertz, um dos pesquisadores envolvidos na investigação, resumiu o problema como uma quebra do modelo de confiança.
A lógica é compreensível.
Quando uma pessoa lê uma documentação oficial, normalmente presume que o conteúdo foi revisado pelo proprietário daquele serviço.
Agentes de IA podem fazer uma inferência parecida, mas com uma diferença importante: eles podem transformar a informação em ação muito mais rapidamente.
Essa diferença é fundamental.
Um erro em uma página pode gerar uma resposta errada.
Um erro em uma página lida por um agente com acesso ao terminal pode gerar uma instalação.
E um erro em uma página lida por um agente com acesso a uma máquina de produção pode ter consequências muito maiores.
Pesquisadores que estudam segurança de sistemas agênticos vêm apontando exatamente essa mudança. Em vez de pensar apenas em vulnerabilidades dentro do modelo, é necessário considerar o conjunto formado por modelo, contexto, ferramentas, permissões e recursos externos.
O que torna o cenário especialmente preocupante
Existe uma diferença importante entre um pacote malicioso tradicional e o tipo de situação encontrado nessa investigação.
Em um ataque convencional à cadeia de software, o criminoso pode tentar publicar uma versão comprometida de uma biblioteca popular, invadir um repositório ou distribuir uma atualização contaminada.
Nesse caso, o pacote pode ser legítimo em aparência, mas o atacante assume um nome que ficou disponível.
Isso se aproxima de problemas conhecidos como dependency confusion, nos quais sistemas acabam buscando uma dependência no lugar errado.
Com agentes de IA, existe uma camada adicional.
O próprio agente pode ser responsável por descobrir a dependência.
Isso significa que a superfície de ataque não está limitada ao repositório de código.
Ela também pode estar na informação usada pelo agente para decidir qual código utilizar.
E a documentação pode parecer inocente
Essa é talvez a parte mais desconfortável da descoberta.
Um arquivo llms.txt não precisa parecer suspeito.
Ele pode ser apenas um documento de texto.
Não precisa conter um executável.
Não precisa pedir uma senha.
Não precisa se apresentar como malware.
Basta apontar para um recurso que, naquele momento, não está sob controle de ninguém.
Se o agente interpretar aquele recurso como legítimo e tiver autorização suficiente para instalá-lo, o restante da cadeia pode acontecer automaticamente.
Um novo tipo de supply chain está surgindo
A indústria de software já aprendeu, da maneira difícil, que confiar cegamente em dependências externas é perigoso.
Agora os agentes de IA acrescentam outra dimensão: dependências de contexto.
O modelo precisa saber onde procurar.
Precisa decidir qual documentação usar.
Precisa escolher quais instruções seguir.
Precisa selecionar quais ferramentas chamar.
E precisa determinar quando uma ação é segura.
Um trabalho acadêmico de 2026 sobre ataques à cadeia de agentes chama atenção justamente para esse problema. Pesquisadores demonstraram cenários nos quais instruções aparentemente benignas podem levar agentes a gerar e executar comportamentos não autorizados, mostrando que mecanismos tradicionais baseados apenas na procura de códigos maliciosos conhecidos podem não ser suficientes.
Em outras palavras, não basta perguntar:
“Esse código é malicioso?”
Também é necessário perguntar:
“Por que o agente decidiu executar esse código?”
Essa segunda pergunta pode ser ainda mais importante em sistemas autônomos.
O que empresas podem fazer agora
A descoberta não significa que toda empresa que utiliza Claude, Codex ou outro agente de programação esteja automaticamente vulnerável.
O risco depende de uma série de fatores, principalmente das permissões concedidas ao agente e de como o ambiente de desenvolvimento está isolado.
Mas existem algumas medidas bastante claras.
1. Tratar documentação externa como dado não confiável
Um agente não deveria considerar automaticamente que tudo o que aparece em uma página oficial é uma autorização para executar comandos.
Documentação é informação.
Comando executável é outra coisa.
A separação precisa ser explícita.
2. Reduzir permissões
Um agente que consegue escrever arquivos é diferente de um agente que também consegue instalar pacotes.
Um agente que consegue instalar pacotes é diferente de outro que pode executar qualquer programa no sistema.
Quanto maior a autonomia, maior precisa ser o controle.
3. Verificar dependências antes da instalação
Pacotes encontrados automaticamente precisam passar por verificações de origem, nome, registro, versão e reputação.
Isso é especialmente importante quando a referência aparece em documentação e não em um manifesto de dependências previamente revisado.
4. Isolar ambientes de execução
Mesmo quando um agente precisa executar código, o ideal é que isso aconteça em ambientes controlados.
Contêineres, sandboxes e permissões mínimas podem limitar o impacto de uma instalação inesperada.
5. Monitorar conexões inesperadas
Uma instalação aparentemente banal que imediatamente inicia uma conexão externa pode ser um sinal importante.
Monitoramento de rede e de processos pode ajudar a identificar esse comportamento antes que ele evolua para algo maior.
O problema também é para quem publica llms.txt
A responsabilidade não está apenas nos fabricantes de agentes.
Empresas que criam esses arquivos também precisam olhar para eles como parte da superfície de segurança do próprio site.
Um endereço que deixou de existir não deveria continuar listado indefinidamente.
Um pacote renomeado precisa ser atualizado.
Uma dependência abandonada precisa ser removida.
E referências externas precisam ser tratadas com o mesmo cuidado aplicado à documentação tradicional.
O caso também serve como alerta para uma realidade curiosa da web moderna: um arquivo criado para facilitar a vida das máquinas pode acabar sendo uma instrução de alto impacto para sistemas que conseguem agir em nome dos humanos.
A próxima fronteira não é apenas fazer a IA raciocinar melhor
Durante muito tempo, a discussão sobre segurança de inteligência artificial esteve concentrada em respostas incorretas, alucinações e conteúdo gerado pelo modelo.
Isso continua sendo importante.
Mas agentes mudam a equação.
Uma resposta errada é um problema.
Uma ação errada pode ser um incidente.
Essa diferença explica por que a segurança de agentes está ganhando atenção própria. Estudos recentes tratam esses sistemas como uma nova superfície de ataque porque eles combinam modelos de linguagem com ferramentas, dados externos e capacidade de execução.
O caso dos arquivos llms.txt é um exemplo particularmente interessante porque não depende de uma grande falha no modelo.
O modelo pode estar funcionando como foi projetado.
O agente pode estar tentando completar corretamente a tarefa.
O problema aparece porque a informação na qual ele confiou não era suficientemente confiável para aquela ação.
Essa distinção será cada vez mais importante.
A pergunta que fica para empresas e desenvolvedores
Quanto mais agentes forem utilizados para escrever software, configurar servidores, operar serviços em nuvem e automatizar tarefas internas, maior será a quantidade de decisões tomadas com base em informações externas.
Isso transforma a internet em algo diferente para esses sistemas.
Para uma pessoa, uma página pode ser apenas uma página.
Para um agente, ela pode ser: documentação + instrução + descoberta de ferramenta + fonte de dependência + gatilho para uma ação.
É uma combinação poderosa.
E também perigosa.
O experimento dos pesquisadores mostra que não é mais suficiente proteger apenas o código que uma empresa deliberadamente escolheu instalar. Também será necessário entender como os agentes chegam até esse código e quais fontes influenciam suas decisões.
No fim, talvez a maior lição seja simples:
um agente capaz de executar comandos não pode tratar toda documentação da internet como se fosse uma fonte confiável de instruções.
A corrida para tornar a IA mais autônoma está avançando rapidamente. Agora, a segurança precisa acompanhar essa mesma velocidade.
Em uma frase
O caso mostra como um simples link abandonado em documentação para IA pode se transformar em uma dependência executável quando agentes recebem autonomia suficiente para instalar software.
Fontes e contexto
- A investigação original publicada pela Ars Technica analisou 6.214 domínios e encontrou 120 arquivos com referências para recursos não registrados.
- Cobertura independente do caso confirmou os principais números e o envolvimento observado de Claude, Codex e Hermes.
- Pesquisas acadêmicas recentes vêm tratando agentes de IA como uma nova superfície de ataque, especialmente quando eles podem consultar dados externos e executar ferramentas.
