Segurança em ambientes corporativos ganhou um novo capítulo preocupante — e ele tem tudo a ver com agentes de inteligência artificial que você provavelmente já usa no trabalho. A notícia veio à tona depois de uma investigação detalhada e mostra como algo aparentemente inofensivo pode virar uma porta de entrada silenciosa dentro das redes de grandes companhias.
Pesquisadores de uma startup israelense que atua no modo furtivo descobriram que agentes como Claude, Codex (da OpenAI) e Hermes (da Nous Research) instalaram código sem dono dentro de redes de grandes empresas, incluindo algumas da lista Fortune 500. E o mais impressionante: várias dessas companhias chegaram a executar código de prova de conceito criado justamente para demonstrar o risco.
O mais surpreendente não foi o que esses agentes fizeram — foi de onde veio o gatilho.
A brecha não estava em um sistema obscuro ou em alguma vulnerabilidade exótica de infraestrutura. Estava escondida em arquivos de documentação que quase ninguém monitora de perto: os arquivos llms.txt e llms-full.txt, um padrão emergente que os sites usam para se comunicar com agentes de IA — algo parecido com o famoso robots.txt, mas voltado para máquinas inteligentes. Quando esses arquivos apontavam para pacotes ou domínios sem dono registrado, os agentes simplesmente seguiam as instruções. Sem questionar. Sem alertar ninguém. E foi exatamente isso que abriu a porta. 🚨
O que são os arquivos llms.txt e por que eles importam tanto
Se você já trabalhou com SEO ou desenvolvimento web, conhece bem o robots.txt — aquele arquivo simples que diz aos mecanismos de busca o que podem ou não indexar. O llms.txt segue uma lógica parecida, mas com um propósito diferente e bem mais recente: ele serve como um guia estruturado e legível por máquinas para que agentes de inteligência artificial entendam o conteúdo de um site e a sua estrutura de alto nível de forma mais eficiente. A ideia é boa, funcional e faz sentido dentro do ecossistema moderno de IA — mas, como qualquer padrão novo, ainda carrega fragilidades que precisam ser levadas a sério antes de virar regra em todos os ambientes.
Vale lembrar que existem exemplos de configuração correta desses arquivos por aí. A Cloudflare, por exemplo, mantém os seus arquivos llms.txt e llms-full.txt bem estruturados como referência. Ferramentas como o Google Lighthouse, voltadas para ajudar desenvolvedores web, também já incorporaram auditorias específicas para esse tipo de arquivo, o que mostra o quanto o padrão vem ganhando tração. Muitos sites, inclusive, hospedam as duas versões ao mesmo tempo, oferecendo tanto um resumo curto quanto uma versão completa da documentação.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
O problema identificado pelos pesquisadores israelenses é que esses arquivos podem conter referências a pacotes externos, repositórios e domínios que, em algum momento, deixaram de ter um dono ativo. Quando um agente de IA como o Claude, o Codex ou o Hermes lê essas instruções e decide segui-las — o que é exatamente o comportamento para o qual foram treinados —, ele pode acabar buscando recursos que foram registrados por pessoas mal-intencionadas. E aí o cenário muda completamente de figura. O agente não foi hackeado. Ele só fez o que estava programado para fazer, seguindo instruções que pareciam legítimas.
Esse tipo de ataque tem um nome no mundo da segurança: envenenamento de dependências, ou dependency confusion. Não é um conceito novo para quem trabalha com segurança de software, mas a novidade aqui é que ele foi adaptado para explorar a confiança automática que os agentes de IA depositam em fontes de instrução — e isso muda a escala do problema de forma significativa. Antes, um desenvolvedor humano poderia, em teoria, perceber algo errado antes de instalar um pacote suspeito. Um agente de IA, por outro lado, age com velocidade e volume muito maiores, sem a mesma capacidade de intuição ou ceticismo que um ser humano teria diante de algo fora do padrão.
Como os pesquisadores encontraram o problema
A metodologia usada na investigação é tão interessante quanto o resultado. Os pesquisadores fizeram uma varredura em 6.214 domínios ativos pertencentes a empreiteiras de defesa, empresas da Fortune 500 e gigantes da tecnologia. Nesse universo, encontraram 8.265 arquivos llms.txt e llms-full.txt — número maior que o de sites, justamente porque muitos hospedavam as duas versões.
Desses milhares de arquivos, 120 deles, cada um em um site diferente, apontavam para um ou mais pacotes de código ou nomes de domínio que não estavam registrados. Para testar o que acontece quando um agente de IA processa esses arquivos, os pesquisadores registraram alguns desses nomes abandonados e hospedaram pacotes que faziam qualquer máquina que os executasse entrar em contato com o servidor deles.
O resultado veio rápido. Em menos de uma hora, os pesquisadores receberam a primeira resposta de retorno vinda de uma empresa da Fortune 500. Com o passar do tempo, mais algumas dezenas de respostas chegaram — algumas de outras companhias da Fortune 500 e outras de startups. O sinal enviado por esses pacotes também registrava a cadeia de processos que originava cada instalação, revelando de forma clara que agentes de codificação como Claude, Codex e Hermes estavam envolvidos. Até o fechamento da reportagem original, Anthropic, OpenAI e Nous Research não responderam aos pedidos de comentário.
Como o código sem dono entrou nas redes corporativas
A sofisticação do ataque está justamente na simplicidade do vetor. Ninguém precisou invadir um servidor, explorar uma falha de dia zero ou engenheirar um ataque de phishing elaborado. Bastou registrar domínios e pacotes que estavam referenciados em arquivos llms.txt de sites legítimos — recursos que, em algum momento, estiveram ativos e depois foram abandonados. Com esses ativos sob controle, os pesquisadores simplesmente esperaram que um agente de IA bem-intencionado, executando tarefas rotineiras dentro de uma rede corporativa, fizesse o resto do trabalho.
Dentro das empresas afetadas — algumas com faturamento bilionário e presença global —, esses agentes de IA estavam sendo usados exatamente como as ferramentas prometem: para automatizar tarefas, consultar documentação, gerar código e integrar sistemas. O Codex, por exemplo, é amplamente usado por times de desenvolvimento para acelerar a escrita de código. O Claude tem sido adotado em fluxos de trabalho que vão desde análise de documentos até suporte interno. O Hermes, por sua vez, aparece em pipelines mais técnicos de processamento de linguagem. Todos eles, dentro do contexto investigado, foram vetores involuntários de um comportamento que nenhuma equipe de segurança estava monitorando porque ninguém sabia que precisava monitorar aquilo.
Vale destacar que, no caso testado pelos pesquisadores, os pacotes apenas enviavam um sinal de volta para provar o conceito. Mas nada impediria que um atacante real substituísse esse comportamento inofensivo por código malicioso com capacidade de executar comandos arbitrários, coletar informações do ambiente ou escalar privilégios dentro da rede. Os pesquisadores inclusive alertaram que pelo menos um site mal configurado estava direcionando visitantes — humanos ou IA — para malware ativo. O nível de dano em um cenário real variaria conforme as permissões que cada agente tivesse no momento da execução.
E esse é um ponto crítico que muitas equipes de TI ainda não incorporaram nas suas políticas de segurança: agentes de IA precisam ser tratados como entidades com permissões, assim como qualquer usuário humano ou sistema automatizado. Dar a um agente acesso irrestrito à rede porque ele foi contratado para ser útil é o mesmo erro conceitual de dar a um estagiário a senha do root no primeiro dia.
O modelo de confiança está quebrado
Um dos pesquisadores por trás da descoberta, Alon Hertz, resumiu o problema de forma direta em entrevista. Segundo ele, o modelo de confiança está quebrado. Os agentes tratam a documentação dos fornecedores como verdade absoluta e não a questionam — e os humanos que os supervisionam também não. Ele destaca que o uso de IA agêntica está explodindo e que esses agentes estão se espalhando por todas as camadas: SaaS, nuvem, endpoint.
Essa fala captura bem o cerne da questão. À medida que os agentes se multiplicam, cresce também a superfície da cadeia de suprimentos que pode ser explorada — e, como o próprio Hertz apontou, as proteções de hoje simplesmente não cobrem esse novo território. Estamos falando de um problema que não é técnico apenas na origem, mas também cultural e organizacional.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
O que as empresas precisam revisar agora
A descoberta acendeu um alerta que vai muito além desse ataque específico. Ela revela uma lacuna estrutural na forma como as empresas estão integrando agentes de IA nos seus ambientes de trabalho. A maioria das políticas de segurança corporativa ainda foi escrita pensando em humanos e em sistemas tradicionais — firewalls, antivírus, controle de acesso baseado em identidade. Agentes de IA autônomos são uma categoria diferente, e as regras para lidar com eles ainda estão sendo escritas em tempo real, enquanto as empresas já os usam em produção.
Do ponto de vista prático, algumas revisões são urgentes. Primeiro, qualquer arquivo do tipo llms.txt presente em repositórios ou sites corporativos precisa ser auditado. Referências a pacotes externos, domínios de terceiros e recursos fora do perímetro da empresa devem ser verificadas quanto à titularidade ativa e à confiabilidade da fonte. Segundo, as permissões dos agentes de IA precisam ser revistas com o mesmo rigor aplicado a usuários humanos — princípio do menor privilégio, logs de atividade, alertas para comportamentos fora do padrão. Terceiro, as equipes de segurança precisam começar a monitorar o que os agentes estão buscando e instalando, não apenas o que os humanos fazem.
Além disso, vale a pena que as equipes de desenvolvimento e segurança comecem a tratar os arquivos de instrução para agentes de IA com o mesmo cuidado que tratam arquivos de configuração críticos. Um llms.txt mal gerenciado pode ser tão perigoso quanto um config.yml exposto ou um .env sem proteção adequada. A cultura de segurança precisa evoluir para incluir esses novos artefatos digitais — e quanto mais cedo isso acontecer, menor será a janela de exposição para ataques que, como esse, exploram exatamente a falta de atenção coletiva a algo novo. 🔐
A boa notícia é que a startup israelense responsável pela descoberta comunicou os achados de forma responsável, e a demonstração serviu para expor um risco real antes que ele fosse explorado com fins maliciosos em larga escala. Mas o episódio serve como um lembrete poderoso: a velocidade com que a IA está sendo adotada no ambiente corporativo ainda não tem um equivalente na velocidade com que as práticas de segurança estão se adaptando a ela. E esse descompasso é, por si só, uma vulnerabilidade enorme que merece atenção redobrada de todos que trabalham com tecnologia hoje.
