O que está acontecendo
Três relatórios diferentes dos últimos meses apontam na mesma direção.
- Cequence (publicado em 28 de outubro): um scanner, cerca de 32 identidades falsas de IA, ativo pelo menos do fim de setembro ao fim de outubro. Cada endereço de nuvem disparava uma rajada de 50 a 190 requisições em uns oito segundos e seguia adiante. Ele usou mais de 300 endereços em um único dia, e nenhum dos endereços do fim de setembro apareceu de novo um mês depois. A análise da CSO Online observa que esse tipo de rotação torna listas estáticas de bloqueio de IP bem menos úteis.
- GreyNoise (agosto): outro grupo se passou por 13 crawlers de IA a partir de 824 endereços, nenhum dentro das faixas de IP publicadas pelas empresas. Os caminhos mais pedidos parecem uma lista de todos os lugares onde um framework poderia deixar segredos: /.env, /app/.env, /api/.env, /backend/.env, /.env.local, /.env.production, /.env.bak, /.aws/credentials. Os bots falsos nunca pediram /robots.txt. O crawler real da Anthropic pediu, e nunca solicitou um arquivo de credenciais.
- Symantec, via Help Net Security (23 de outubro): um honeypot que se passava por um serviço de IA desprotegido flagrou o agente autônomo de um atacante em ação. O prompt de jailbreak dele dizia ao modelo que ler arquivos .env, API keys e esquemas de banco de dados era trabalho normal de desenvolvimento. A maioria das mais de 127.000 requisições registradas pelo honeypot era reconhecimento, tentativas com chaves roubadas e sondagens por arquivos de configuração expostos.
O padrão é claro. Os atacantes sabem que donos de sites começaram a liberar crawlers de IA, então pegam esses nomes emprestados. E sabem que chaves de IA valem dinheiro de verdade: uma chave vazada da OpenAI, Anthropic ou Gemini pode gerar uma conta enorme antes que você perceba.
Por que isso importa para quem lança rápido
O user agent é só um cabeçalho que o visitante escreve sobre si mesmo. Ele não prova nada. Se a sua hospedagem, uma regra de CDN ou o seu WAF deixa passar "bots de IA conhecidos", você pode ter aberto a porta justamente para esse tráfego.
E, mais importante, o que eles procuram é um erro clássico de apps lançados às pressas. Um .env vai parar na raiz web porque o build copiou a pasta inteira do projeto. Um .env.production.bak fica esquecido depois de uma correção de madrugada. Uma imagem Docker serve /app como arquivos estáticos. Nada disso exige um exploit engenhoso. É uma requisição GET, e o bot não se importa se é a primeira ou a nonagésima que ele faz.
Como verificar o seu app
Comece pelos caminhos que os scanners realmente pedem. Rode o loop abaixo em um terminal, com o seu próprio domínio.
O que você quer ver é 404 ou 403 em todas as linhas. Um 200 é um problema, mas confira o corpo antes de entrar em pânico: muitas single-page apps devolvem index.html com 200 para qualquer caminho desconhecido. Rode curl -s https://yourapp.com/.env | head -5 e veja o que volta. Se aparecerem linhas KEY=value, trate todos os segredos desse arquivo como comprometidos.
for p in .env .env.local .env.production .env.bak .env.old \
app/.env api/.env backend/.env .aws/credentials .git/config; do
code=$(curl -s -o /dev/null -w "%{http_code}" "https://yourapp.com/$p")
echo "$code /$p"
doneAproveitando, verifique os vazamentos relacionados que entregam os mesmos segredos por outro caminho:
- Um diretório .git acessível permite que qualquer pessoa reconstrua seu código, incluindo qualquer .env que já tenha sido commitado.
- Chaves no seu bundle JavaScript nem precisam de scanner. Abra o DevTools e procure no bundle por sk-, AIza ou key.
- Source maps em produção podem entregar seu código original, com comentários e tudo.
Depois, confira seus logs. Procure requisições para /.env ou /.aws/credentials. Se alguma delas retornou 200, esse é o horário de início do seu incidente.
Como corrigir
1. Tire os segredos da raiz web. A correção de verdade é o arquivo simplesmente não estar lá para ser servido. Variáveis de ambiente ficam nas configurações da sua hospedagem (Vercel, Netlify, Railway, Fly e as demais têm isso), não em um arquivo que é publicado junto com os assets estáticos. Garanta que .env* esteja tanto no .gitignore quanto no .dockerignore.
2. Bloqueie dotfiles no servidor como segunda camada. No nginx:
# Deny all hidden files except the ACME challenge path
location ~ /\.(?!well-known) {
deny all;
return 404;
}No Apache (.htaccess):
<FilesMatch "^\.">
Require all denied
</FilesMatch>Em um app Express que serve arquivos estáticos, o express.static ignora dotfiles por padrão. Não mude isso com dotfiles: 'allow'.
3. Rotacione tudo o que foi exposto. Apagar o arquivo não desfaz o vazamento das chaves. Rotacione todos os segredos que já estiveram acessíveis, começando pelas chaves de pagamento, de banco de dados e de provedores de IA. Nosso post sobre o vazamento na Railway mostra como rotacionar os segredos do seu app sem downtime.
4. Pare de confiar no user agent. Se você libera crawlers de IA em um firewall ou rate limit, verifique-os pelas faixas de IP que as empresas publicam em vez de comparar o nome. A GreyNoise lista no relatório os arquivos JSON oficiais da Anthropic, OpenAI, Google e Perplexity. O conselho da Cequence é o mesmo: verificar por requisições assinadas, faixas de endereços publicadas ou integrações diretas.
5. Atualize suas ferramentas de desenvolvimento se estiverem expostas. A GreyNoise também viu esses scanners tentando explorar a falha de leitura de arquivos do Vite CVE-2025-30208. Se um servidor de desenvolvimento do Vite estiver acessível pela internet, atualize para 6.2.3, 6.1.2, 6.0.12, 5.4.15 ou 4.5.10 ou posterior, e, antes de tudo, não exponha servidores de desenvolvimento publicamente.
6. Defina limites de gasto nas chaves de IA. A maioria dos provedores de IA permite limitar o gasto mensal ou restringir chaves a projetos específicos. Isso não impede um vazamento, mas transforma uma surpresa de quatro dígitos em uma pequena.
Checklist rápido
Antes de fechar o terminal, confirme que:
- Todos os caminhos do loop de curl acima retornam 404/403, e não o seu arquivo.
- .env* está no .gitignore e no .dockerignore.
- Seu servidor ou hospedagem bloqueia dotfiles.
- Não há chaves secretas no bundle JS nem nos source maps.
- Toda chave que já esteve acessível foi rotacionada.
- As listas de permissão de crawlers de IA verificam faixas de IP, não só o user agent.
- Há limites de gasto nas chaves dos provedores de IA.
Verifique antes que os bots verifiquem
Esses scanners alternam entre centenas de endereços e gastam uns oito segundos em cada rajada. Você não vai vencer olhando logs. Você vence garantindo que não haja nada lá quando eles baterem na porta.
O AppSafe procura exatamente os vazamentos que esses bots buscam, incluindo arquivos .env acessíveis, diretórios .git expostos, dumps de banco de dados e API keys no bundle do frontend, e cada achado vem com um prompt de correção pronto para colar na sua ferramenta de IA. Se você ainda está no pré-lançamento, nosso checklist para apps feitos com IA é uma boa leitura complementar. Rode um scan gratuito do seu app e veja o que um bot veria.