Lacuna de Segurança Anthropic Google: Agentes de IA Seguiram Documentos Confiáveis Até Código Sem Proprietário

Anthropic e Google estão agora no centro de uma disputa de segurança após pesquisadores relatarem que agentes de programação executaram pacotes mencionados em documentação corporativa confiável. Um pacote de teste teria sido executado em um ambiente de uma empresa da Fortune 500 em quatro minutos. Claude, OpenAI Codex e Hermes, da Nous Research, apareceram em registros de processos posteriores, segundo os pesquisadores.

A descoberta não demonstra que Anthropic, Google ou OpenAI tenham distribuído malware deliberadamente. A maioria dos pacotes registrados para o experimento continha beacons inofensivos, que apenas informavam quando eram executados. A descoberta mais grave foi um pacote npm não relacionado, supostamente malicioso, conectado a instruções antes publicadas no site do provedor de autenticação Clerk.

Essa distinção é importante porque a cobertura inicial pode dar a entender que três fornecedores de IA violaram redes corporativas. As evidências apontam, em vez disso, para uma falha na cadeia de suprimentos de software. Os agentes confiaram em instruções com aparência oficial, recorreram a registros públicos de pacotes e executaram nomes que ninguém havia protegido.

O Google entra nessa história de segurança Anthropic Google por meio de seu suporte à verificação de arquivos llms.txt no Lighthouse, seu software de auditoria de sites. Claude e Codex entram por meio dos agentes que supostamente seguiram instruções de instalação. O problema comum não é um modelo ou uma empresa específica. É a fronteira em colapso entre documentação e ação executável.

Essa fronteira antes parecia clara. Um desenvolvedor podia ler um guia de configuração, verificar um pacote e decidir se deveria instalá-lo. Um agente autônomo de programação pode condensar essas etapas em uma única operação, muitas vezes usando as permissões já existentes do desenvolvedor.

O resultado é uma nova questão de segurança para toda organização que implanta agentes de programação: quando um software lê um documento, quem verifica se esse documento ainda aponta para algo confiável?

Agentes corporativos de IA executaram nomes que ninguém possuía

Pesquisadores transformaram documentação desatualizada em uma prova executável de que texto confiável pode se tornar um ponto de entrada.

O pesquisador de segurança Alon Hertz e seus colegas examinaram documentação legível por máquinas em 6.214 domínios ativos. A amostra incluiu contratadas de defesa, grandes empresas de tecnologia e organizações da Fortune 500.

Os pesquisadores relataram ter encontrado 8.265 arquivos llms.txt e llms-full.txt. Um arquivo llms.txt é uma convenção emergente que organiza o conteúdo de um site para modelos de linguagem e agentes de IA. Sua versão mais extensa pode fornecer documentação mais abrangente em um único arquivo legível por máquinas.

Entre os arquivos coletados, 120 sites supostamente faziam referência a pelo menos um pacote não registrado ou domínio não reivindicado. A equipe contabilizou 227 comandos envolvendo pacotes ou destinos inexistentes.

Não se tratava necessariamente de instruções hostis. Algumas pareciam ser comandos de instalação comuns que apontavam para nomes de pacotes que nunca haviam sido registrados. Outras mencionavam domínios que expiraram ou serviços que já não eram reivindicados.

Uma linha como pip install package-name torna-se perigosa quando o nome do pacote está disponível no PyPI. O mesmo princípio se aplica a npm, RubyGems, NuGet, crates.io, Packagist ou a um subdomínio de hospedagem abandonado.

Os pesquisadores registraram uma pequena seleção desses nomes disponíveis. Em seguida, publicaram pacotes contendo código projetado para contatar seu servidor quando executado. O relato da pesquisa de Hertz afirma que o primeiro retorno chegou de um ambiente da Fortune 500 em quatro minutos.

Outros dois sistemas supostamente executaram o código na primeira hora. Ao longo do tempo, a equipe recebeu várias dezenas de retornos de startups e grandes empresas.

O retorno registrava a cadeia de processos pai, que identifica os programas envolvidos no início de um processo. Segundo os pesquisadores, esses registros associaram algumas instalações a Claude, OpenAI Codex e Hermes, da Nous Research.

O experimento não exigiu comprometer esses modelos. Tampouco se baseou em uma vulnerabilidade de software recém-descoberta, mensagem de phishing ou senha de funcionário roubada. Os agentes supostamente encontraram instruções publicadas em sites legítimos e as seguiram com o acesso disponível em seus ambientes.

Essa é a inversão central. A documentação corporativa normalmente reforça a segurança ao mostrar aos desenvolvedores a forma aprovada de configurar software. Neste caso, referências abandonadas dentro dessa documentação criaram uma oportunidade para que outra pessoa definisse o que o comando aprovado executaria.

A descoberta também exige linguagem cautelosa. Os pesquisadores não identificaram publicamente as empresas afetadas, divulgaram todos os nomes de pacotes ou forneceram telemetria suficiente para que terceiros reproduzissem cada atribuição corporativa. Anthropic, OpenAI e Nous Research não comentaram antes da publicação da reportagem original.

Mesmo com essas limitações, o experimento demonstra um mecanismo plausível. Um registro público de pacotes atribui significado a quem controla um nome. A documentação oficial pode preservar esse nome muito depois de seu significado pretendido ter desaparecido.

Por que a cadeia de confiança Anthropic Google falhou

Os agentes não ignoraram o modelo de confiança. Eles seguiram um modelo de confiança que já não correspondia à forma como o software autônomo opera.

A documentação tradicional pressupõe que um leitor humano esteja entre as instruções e a execução. Esse leitor pode perceber um nome de pacote estranho, inspecionar seu publicador ou questionar por que um comando de configuração não tem um repositório de apoio.

Um agente pode realizar as mesmas verificações, mas apenas quando suas instruções e ambiente as exigem. Caso contrário, ele otimiza para concluir a tarefa solicitada. Encontrar documentação oficial e executar seu comando de instalação pode parecer o caminho válido mais curto.

A conexão Anthropic Google destaca como várias decisões razoáveis de forma independente podem se combinar em uma única cadeia arriscada. Sites publicam orientações legíveis por máquinas. As ferramentas Lighthouse do Google incentivam desenvolvedores a tornar essas orientações detectáveis. Agentes de programação buscam contexto autoritativo. Gerenciadores de pacotes tornam dependências fáceis de recuperar e executar.

Nenhum desses componentes precisa ser malicioso. O perigo surge quando o agente trata toda a cadeia como autenticada.

A orientação do Lighthouse do Google descreve uma auditoria para disponibilidade e formatação de llms.txt. O Lighthouse não certifica todos os comandos ou dependências nomeados em um arquivo. Portanto, passar em uma auditoria de formatação não diz nada sobre propriedade do pacote, identidade do publicador ou segurança do código.

Da mesma forma, HTTPS comprova que um arquivo veio do domínio mostrado na conexão do navegador. Não comprova que todos os pacotes mencionados ainda pertencem ao operador desse domínio.

Um registro público também pode servir um pacote escrito corretamente a partir de uma conta controlada por um invasor. Isso difere do typosquatting clássico, no qual invasores registram um erro de grafia semelhante a um pacote popular. Os nomes neste experimento teriam sido copiados diretamente da documentação oficial.

Isso torna as instruções mais persuasivas tanto para agentes quanto para humanos. Um desenvolvedor que revise uma transcrição de terminal pode ver um domínio oficial, um gerenciador de pacotes conhecido e um nome de dependência plausível. Todos os sinais visíveis podem parecer rotineiros.

O comportamento de busca do agente agrava o problema. Um usuário pode mencionar apenas um fornecedor ao solicitar uma integração. O agente pode localizar a documentação do fornecedor, descobrir llms.txt, selecionar um comando de instalação e chamar o gerenciador de pacotes sem receber um link suspeito do usuário.

Por isso, o incidente é mais amplo do que injeção de prompt. A injeção de prompt geralmente envolve conteúdo hostil tentando redirecionar um agente. Aqui, a própria instrução pode ser benigna e historicamente legítima. A falha de segurança ocorre depois, quando a propriedade do destino mencionado muda ou nunca existiu.

A convenção emergente llms.txt também não equivale a um padrão formal da web com uma arquitetura de segurança estabelecida. Sua utilidade vem de fornecer aos modelos contexto conciso e estruturado. Essa mesma conveniência pode concentrar instruções operacionais em um local no qual os agentes são incentivados a confiar.

A lacuna de segurança Anthropic Google é, portanto, um problema de proveniência. Proveniência significa evidências que mostram de onde veio um artefato e quem o controla. O agente verificou a localização do documento, mas aparentemente não estabeleceu a proveniência da dependência executável por trás do comando.

O verdadeiro adversário é a autonomia sem proveniência

O conflito definidor não é Claude versus Codex. É a execução autônoma versus a propriedade verificada de software.

Claude, Codex e Hermes usam modelos, interfaces e sistemas de permissão diferentes. Tratar esse evento como uma simples comparação entre essas ferramentas deixaria de lado a condição operacional compartilhada por trás das instalações relatadas.

Cada agente de programação pode ler o contexto de um projeto, consultar documentação, editar arquivos e chamar ferramentas de desenvolvimento. Essas capacidades tornam os agentes úteis porque eliminam transições manuais entre pesquisa e execução.

Elas também levam uma decisão de segurança para o fluxo de trabalho do agente. Alguém precisa decidir se uma dependência é autêntica, se sua versão é aceitável e se seus scripts de instalação devem ser executados.

Gerenciadores de pacotes executam código rotineiramente durante a instalação. Um pacote npm pode definir scripts de ciclo de vida, enquanto um pacote Python pode executar comportamentos relacionados à instalação por meio de seu processo de compilação. O comportamento exato varia, mas instalar não equivale a baixar texto inerte.

O exemplo do Clerk mostra por que isso importa. Pesquisadores descobriram que um arquivo de instruções no site legítimo do Clerk fazia referência a npx clerk-next-fix-auth-protection. O utilitário npx pode baixar um pacote e executar seu comando exposto sem adicioná-lo permanentemente ao manifesto de um projeto.

Segundo a investigação de segurança, alguém havia reivindicado esse nome de pacote e o usado para distribuir malware ativo. Posteriormente, o Clerk corrigiu a documentação.

Ainda não está claro se esse pacote causou infecções por meio de um agente de IA. A reportagem também observa que um binário existente do plugin ESLint legítimo do Clerk era seguro. Uma máquina sem esse binário legítimo poderia, em vez disso, recuperar o pacote controlado pelo invasor.

A diferença é sutil o bastante para escapar a uma revisão apressada. Ambos os caminhos começam com um comando publicado pelo fornecedor real. Ambos usam infraestrutura npm. O caminho perigoso depende de o binário esperado já existir localmente.

Esse é o dilema prático enfrentado pelas empresas. Os agentes entregam mais valor quando podem resolver dependências, executar testes e corrigir falhas sem esperar aprovação após cada comando. Essas mesmas permissões permitem que uma decisão equivocada de confiança se transforme em execução de código.

O fornecedor do modelo pode reduzir esse risco por meio de sandboxing e aprovações. A empresa ainda precisa configurar esses controles, manter políticas de rede e decidir quais fontes de pacotes um agente pode acessar.

O fornecedor de software é responsável por outra parte do problema. Sua documentação tornou-se um ativo operacional, e não conteúdo estático de marketing. Referências a pacotes, domínios de exemplo, comandos copiados e páginas arquivadas de configuração agora exigem a mesma gestão de ciclo de vida que código executável.

Os operadores de registros também influenciam o resultado. Reserva de namespaces, verificação de publicadores, varredura de pacotes suspeitos e histórico de propriedade podem ajudar. No entanto, os registros nem sempre conseguem saber que um nome não reivindicado aparece na documentação de terceiros.

Essa divisão de responsabilidades torna a simples atribuição de culpa pouco útil. A narrativa Anthropic Google é importante porque atravessa limites entre produtos. Uma ferramenta de busca ou documentação pode facilitar a localização de instruções, um agente de IA pode interpretá-las, e um registro pode fornecer o artefato mencionado.

A segurança falha quando cada participante presume que outro participante verificou a propriedade.

As salvaguardas existentes para agentes não eliminam o risco

Claude e Codex já oferecem controles relevantes, mas esses controles só funcionam quando as organizações preservam seus limites restritivos.

As orientações de segurança do Claude da Anthropic descrevem injeção de prompt como texto hostil que tenta manipular as instruções de um assistente. Elas também documentam controles de permissão e restrições para comandos que recuperam conteúdo web arbitrário.

O Claude Code pode usar sandboxing para limitar o acesso ao sistema de arquivos e à rede. Os processos filhos herdam essas restrições do sistema operacional, o que ajuda a impedir que um comando permitido escape silenciosamente para um processo menos restrito.

A OpenAI descreve uma abordagem em camadas semelhante. Seu modelo de segurança do Codex combina limites de sandbox, políticas de aprovação, acesso de rede gerenciado, regras e telemetria voltada a agentes.

A OpenAI afirma que suas implantações gerenciadas não dão ao Codex acesso externo irrestrito. Destinos esperados podem ser permitidos, domínios desconhecidos podem exigir aprovação, e as equipes de segurança podem exportar logs que abrangem prompts, chamadas de ferramentas, aprovações e decisões de rede.

Essas salvaguardas são importantes, mas não invalidam automaticamente as conclusões dos pesquisadores. As organizações podem configurar agentes com acesso mais amplo. Desenvolvedores podem aprovar comandos. Instalações locais podem herdar permissões e conectividade de rede do usuário que as executa.

Um registro de pacotes também é um destino esperado em muitos ambientes de desenvolvimento. Bloquear todo o acesso ao npm ou PyPI interromperia builds comuns, atualizações de dependências e a configuração de testes. Permitir esses domínios remove um sinal de rede evidente que poderia distinguir uma instalação maliciosa.

Softwares de detecção e resposta de endpoint enfrentam um desafio semelhante. Um agente de programação inicia um gerenciador de pacotes padrão, que entra em contato com um registro conhecido por uma conexão criptografada. O processo pode se assemelhar à atividade normal de desenvolvedores até que o pacote baixado execute algo claramente hostil.

O beacon da pesquisa foi intencionalmente mínimo. Segundo relatos, ele entrou em contato com um servidor e registrou o contexto de execução. Um atacante real poderia tentar roubo de credenciais, descoberta de ambiente, persistência ou modificação de código-fonte.

No entanto, as evidências públicas não mostram que os pacotes experimentais realizaram essas ações. Tampouco estabelecem que dezenas de empresas sofreram comprometimento em produção. Elas executaram código de prova de conceito, o que é grave, mas mais restrito do que uma violação confirmada.

Essa distinção cética deve orientar a resposta empresarial. As equipes não devem presumir que todo uso de Claude, Codex ou Hermes gera uma infecção. Elas devem identificar as condições necessárias para que esse caminho funcione.

O agente precisa ter acesso à documentação relevante. Ele precisa de autoridade para invocar um gerenciador de pacotes. O ambiente deve permitir a obtenção a partir do registro. O pacote precisa executar código relevante, e os controles existentes precisam falhar em conter seu comportamento.

Remover qualquer uma dessas condições pode interromper a cadeia. Restringir o acesso à rede é uma opção. Exigir aprovação humana para a instalação de dependências é outra. Executar agentes em contêineres descartáveis pode limitar as consequências quando um pacote é executado.

As organizações também podem impor um proxy interno de dependências. O proxy pode permitir pacotes e versões aprovados enquanto rejeita namespaces desconhecidos. Essa abordagem afasta a decisão de confiança de um agente que lê documentação pública.

Somente prompts de aprovação são menos confiáveis quando apresentam apenas um comando familiar. Um revisor precisa de contexto sobre propriedade do pacote, idade, identidade do publicador, histórico de downloads e se a dependência aparece em uma lista de materiais de software aprovada.

A lição não é que as salvaguardas são inúteis. É que controles projetados em torno de comandos obviamente maliciosos podem deixar passar comandos legítimos que são resolvidos para propriedade não confiável.

A documentação agora faz parte da cadeia de suprimentos de software

As empresas precisam tratar cada referência executável na documentação como uma dependência que pode expirar, sofrer desvios ou mudar de proprietário.

A resposta imediata começa pelo inventário. As organizações devem pesquisar llms.txt, llms-full.txt, portais para desenvolvedores, guias arquivados, exemplos de código, artigos de suporte e referências de API geradas em busca de comandos de instalação.

Cada pacote, domínio, repositório, imagem de contêiner e subdomínio hospedado referenciado precisa ter um proprietário. Um nome que ninguém reconhece não deve permanecer público enquanto uma investigação estiver em andamento.

As equipes devem verificar se os nomes de pacotes públicos correspondem às contas reais da organização no registro. Também devem inspecionar se pacotes com escopo estão disponíveis nos casos em que um nome global, sem escopo, aparece em documentação antiga.

Os pipelines de documentação precisam de testes automatizados. Um build pode verificar se cada pacote existe, pertence a um publicador aprovado, é resolvido para um repositório esperado e não mudou de proprietário.

A verificação de links por si só é insuficiente. Um pacote malicioso ou domínio recuperado pode retornar uma resposta bem-sucedida. O pipeline precisa validar a identidade, e não a disponibilidade.

As empresas devem reservar nomes antes de publicar documentação. Isso é semelhante ao registro defensivo de domínios associados a um produto importante, mas namespaces de pacotes exigem manutenção contínua.

O mesmo princípio se aplica quando um projeto é descontinuado. Remover um pacote sem remover suas instruções de instalação cria uma lacuna de propriedade. Abandonar um subdomínio de hospedagem enquanto se mantêm links para ele pode permitir que outra parte herde um caminho confiável.

A documentação gerada por IA merece escrutínio adicional, mas páginas escritas por humanos não estão isentas. Os pesquisadores encontraram evidências de que algumas referências questionáveis antecediam a era atual dos agentes. Copiar essas páginas para llms-full.txt tornou erros antigos mais fáceis de serem consumidos por software autônomo.

As empresas que implantam agentes precisam de um plano de controle complementar. As sessões dos agentes devem ser executadas com identidades dedicadas, em vez da conta irrestrita de um desenvolvedor. As credenciais devem ter escopo limitado ao repositório e à tarefa atuais.

A instalação de pacotes deve ocorrer em um ambiente isolado com acesso limitado a segredos. Se uma dependência precisar de acesso à rede durante a instalação, esse acesso deve ser explícito e registrado.

As equipes devem preservar o contexto de raciocínio do agente junto à telemetria do sistema operacional. Um log de processo pode mostrar que o npm foi iniciado, enquanto registros nativos do agente podem mostrar qual documento forneceu o nome do pacote.

Esse contexto importa durante a resposta a incidentes. Os investigadores precisam distinguir uma dependência de projeto aprovada de um pacote selecionado depois que um agente navegou por instruções externas.

Listas de permissões de dependências podem reduzir o risco, mas exigem um caminho de exceção para novos pacotes. Essa exceção deve coletar evidências de procedência e exigir um responsável humano nomeado.

As organizações também devem manter um registro pesquisável das fontes consultadas pelos agentes. Isso pode incluir snapshots de documentação, metadados de pacotes, decisões de aprovação e alterações de código geradas. Uma base de conhecimento técnico controlada pode ajudar revisores a reconstruir por que um agente selecionou uma dependência.

A lição mais ampla vai além de llms.txt. Agentes de programação consomem descrições de issues, arquivos de repositórios, resultados de busca, documentação de pacotes, respostas do Model Context Protocol e guias internos gerados.

Qualquer uma dessas fontes pode conter uma instrução. Se o agente tiver ferramentas, a instrução pode se tornar uma ação.

Isso faz da integridade da documentação parte da segurança da cadeia de suprimentos de software. A empresa não pode proteger apenas repositórios de código-fonte e servidores de build enquanto deixa instruções legíveis por máquina fora de seu controle.

Três sinais mostrarão se o setor aprendeu

A próxima fase depende de documentação, permissões de agentes e identidade de registro melhorarem juntas.

O primeiro sinal é a divulgação e a remediação nos 120 sites afetados. A equipe da Hertz afirma que contatou organizações afetadas e equipes de segurança relevantes, mas o registro público não identifica a maioria dos domínios.

Observe se as empresas estão auditando arquivos llms.txt, reservando nomes de pacotes e publicando comunicados de incidentes. Uma limpeza coordenada reforçaria o argumento de que a documentação legível por máquina é uma infraestrutura sensível à segurança.

O silêncio não provaria que nenhuma correção ocorreu. Muitas organizações corrigem referências expostas sem divulgação pública, especialmente quando os pesquisadores usaram código inofensivo e não encontraram roubo de dados confirmado.

O segundo sinal é uma verificação de procedência no nível do produto por parte dos fornecedores de agentes. Claude, Codex e Hermes já podem pedir aprovação antes de comandos, mas a aprovação se torna mais útil quando a interface explica a dependência por trás do comando.

Uma mudança significativa alertaria que um pacote é novo, não verificado, não relacionado à conta de publicador conhecida do fornecedor ou ausente do gráfico de dependências existente do projeto. Um sistema mais forte poderia exigir aprovação explícita sempre que documentação pública apontasse para um pacote não reconhecido.

Esse recurso fortaleceria a resposta de segurança Anthropic Google porque abordaria o ponto de decisão antes da execução. Outro alerta genérico sobre comandos de shell ofereceria menos proteção.

O terceiro sinal é a integração entre registros e políticas empresariais. Gerenciadores de pacotes e proxies internos podem expor histórico do publicador, idade do namespace, status de assinatura e mudanças de propriedade. Plataformas de agentes podem usar esses metadados antes de selecionar ou instalar uma dependência.

Uma política empresarial pode permitir automaticamente pacotes estabelecidos, enquanto isola pacotes desconhecidos para revisão. Ela também pode rejeitar um pacote cujo nome apareça em documentação oficial, mas que não tenha uma conexão verificável com o publicador.

Esse sinal enfraqueceria o alerta mais amplo dos pesquisadores se verificações confiáveis de procedência interrompessem o caminho de ataque em vários agentes. Ele fortaleceria o alerta se os agentes continuassem instalando nomes recém-reivindicados apesar da disponibilidade de dados de identidade.

As evidências atuais sustentam uma conclusão ponderada. Segundo relatos, os pesquisadores demonstraram execução de código em ambientes corporativos reais e conectaram parte da atividade a agentes de programação proeminentes. Eles não demonstraram que os fornecedores dos modelos instalaram malware intencionalmente nem que cada callback relatado representou um comprometimento grave.

A conclusão mais importante é estrutural. Documentação confiável, execução autônoma e registros públicos agora formam uma cadeia de suprimentos que muitos programas de segurança não inventariam.

Desenvolvedores e compradores empresariais devem fazer perguntas diretas antes de ampliar as permissões dos agentes. O agente pode acessar registros públicos de pacotes? Ele verifica a identidade do publicador? Os comandos de instalação são isolados? As equipes de segurança conseguem reconstruir qual documento causou uma ação?

A lacuna de segurança entre Anthropic e Google não será resolvida apenas com um comportamento melhor dos modelos. Responsáveis pela documentação, registros, fornecedores de agentes e administradores corporativos controlam, cada um, um elo diferente.

Antes de conceder maior autonomia a um agente de programação, teste toda essa cadeia com uma dependência não reconhecida. Se o agente a instalar sem apresentar sua procedência, o ambiente estará tratando a documentação como autoridade, e não como evidência.