O seu assistente de código com IA acabou de ler a sua carteira
As ferramentas de código com IA leem os ficheiros .env antes de você escrever qualquer coisa. As suas chaves de API — cada uma um cartão de crédito sem limite de gasto — estão na janela de contexto de outra pessoa antes de escrever o seu primeiro prompt. O problema não é a IA. O problema é que os segredos são ficheiros.
Abra o seu assistente de código com IA. Antes de escrever um único carácter, ele já leu o diretório do seu projeto. O seu ficheiro .env. As suas chaves de API. A sua palavra-passe de base de dados. A sua chave secreta do Stripe.
Você não lhe pediu isso. Não aprovou nada. É uma funcionalidade, não um erro — a ferramenta precisa do contexto do projeto para ser útil. Por isso lê tudo o que um programador consegue ler.
E um programador consegue ler tudo.
A versão greentext
Um post circulou esta semana, escrito como monólogo interno de um programador:
> Abrir o Claude Code. O seu .env é lido antes de escrever qualquer coisa. As suas chaves de API estão agora no chat. Você adiciona "não leia o .env" ao CLAUDE.md. Não funciona.
380 000 pessoas viram esse post. 2 700 guardaram-o nos favoritos. Não porque fosse novidade — porque era um espelho.
Todos os programadores que o leram tiveram o mesmo pensamento: é a minha configuração.
As instruções não funcionam
A primeira coisa que as pessoas tentaram foi escrever regras. "Não leia ficheiros .env." No CLAUDE.md, no AGENTS.md, em prompts de sistema. Proibições diretas e explícitas.
A ferramenta leu os ficheiros na mesma.
Isto faz sentido quando pensamos nisso. O ficheiro é lido como parte da construção do contexto do projeto — antes de as instruções sequer serem processadas. Dizer ao modelo para não ler um ficheiro que já leu é como dizer a alguém para esquecer o que acabou de ver. A informação está na janela de contexto. Já foi transmitida. A instrução chega depois do dano.
Um investigador descobriu que até regras de negação ao nível do ficheiro podiam ser contornadas através de scripts personalizados ou cadeias de pipes. Outro descobriu faturas elevadas de proxy porque as suas credenciais HTTP_PROXY estavam a ser carregadas e utilizadas automaticamente.
O dinheiro no seu .env
As pessoas enquadram isto como uma questão de privacidade. É uma questão financeira.
Abra um ficheiro .env típico num projeto em produção:
OPENAI_API_KEY=sk-... STRIPE_SECRET_KEY=sk_live_... AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=... DATABASE_URL=postgresql://user:pass@...
Essa chave da OpenAI é um cartão de crédito sem limite de gasto e sem PIN. Alguém com essa string pode fazer 40 000 dólares em chamadas de API durante a noite. A chave do Stripe pode emitir reembolsos, criar cobranças, aceder a dados de pagamento de clientes. As credenciais da AWS — dependendo da política IAM, que é quase certamente demasiado ampla — podem criar instâncias de GPU, aceder a buckets S3 ou apagar infraestrutura.
Isto não é uma lista de palavras-passe. É uma lista de carteiras, cada uma com um saldo diferente e sem fechadura.
29 milhões de carteiras no passeio
O relatório mais recente da GitGuardian contou 28,6 milhões de segredos expostos em commits públicos do GitHub em 2025. Um aumento de 34% em relação ao ano anterior, e o maior aumento anual alguma vez medido por eles.
Os números específicos da IA são piores. 1,2 milhões de segredos de serviços de IA expostos — um aumento de 81% ano após ano. Commits co-criados por ferramentas de código com IA vazaram segredos a uma taxa aproximadamente dupla da linha de base. E 24 000 segredos únicos foram encontrados em ficheiros de configuração MCP — a canalização que liga agentes de IA a serviços externos.
Doze dos quinze tipos de segredos vazados com crescimento mais rápido eram serviços de IA. Não bases de dados. Não fornecedores de cloud. Serviços de IA.
As ferramentas que estamos a usar para escrever código mais depressa estão a vazear as chaves dos sistemas a que esse código se liga.
O problema real
O programador que publicou aquela thread greentext terminou com uma correção prática — uma configuração settings.json que bloqueia leituras de ficheiros. Funciona. Por agora, para essa ferramenta.
Mas o problema real não é o Claude Code, nem o Cursor, nem o Copilot. O problema real é que os segredos são ficheiros.
Um ficheiro .env é um documento em texto simples que está no disco, legível por qualquer processo a executar como o seu utilizador. Antes das ferramentas de código com IA, os processos que liam o seu projeto eram git, npm, node, o seu editor. Confiava neles implicitamente. Não pensava no facto de os seus segredos estarem a um comando cat de distância da exposição.
As ferramentas de código com IA apenas tornaram o implícito explícito. Leem o seu projeto da mesma forma que todas as outras ferramentas — apenas acontece enviarem o contexto para algum lado onde você o pode ver.
O seu pipeline de CI também lê ficheiros .env. O seu test runner também. O seu linter também. O build do seu Docker também. Nenhum deles pediu permissão também. Você simplesmente não deu por isso porque não lhe mostraram uma transcrição de chat do que encontraram.
O padrão por baixo
70% dos segredos vazados em 2022 continuam ativos hoje. Não foram rotacionados. Não foram revogados. Continuam a funcionar, a conceder acesso, três anos depois.
Este é o número real. Não os 29 milhões de vazamentos — os 70% nunca corrigidos. Porque rotacionar uma chave significa encontrar todos os sistemas que a utilizam, atualizar todos os deployments, testar todas as integrações. A chave foi criada uma vez, colada num ficheiro .env, e nunca mais se pensou nela. O custo de a vazear é instantâneo. O custo de corrigir o vazamento é ilimitado.
Por isso a maioria das organizações não corrige. Não conseguem. Não sabem que chaves estão onde, quais continuam ativas, quais foram copiadas para outros ficheiros .env noutras máquinas por outros programadores que precisavam de fazer uma funcionalidade funcionar numa sexta-feira à tarde.
O que isto realmente significa
Cada ficheiro .env é uma aposta. Uma aposta de que nenhum processo o vai ler sem que deva. Uma aposta de que nenhuma ferramenta o vai enviar para algum lado inesperado. Uma aposta de que nenhum programador o vai fazer commit por acidente.
29 milhões de vezes no ano passado, alguém perdeu essa aposta. Só no GitHub público. Os repositórios privados — onde a GitGuardian encontrou segredos em 35% dos repositórios — nem sequer estão contados.
A correção não é uma regra no settings.json. A correção não é uma entrada no .gitignore. A correção não é escrever "NÃO LEIA O .ENV" em maiúsculas no seu ficheiro de instruções.
A correção é que o segredo não devia estar ali em primeiro lugar. Não num ficheiro. Não numa variável de ambiente carregada a partir de um ficheiro. Não em qualquer forma que um processo com as suas permissões consiga ler fazendo o que os processos fazem: ler ficheiros no diretório do seu projeto.
Se o segredo está no disco, será lido. A única questão é quando, e por quê.
---
Fontes
- GitGuardian — State of Secrets Sprawl 2025 — 28,6 M de segredos vazados, tendências de credenciais de serviços de IA, estatísticas de remediação
- GitGuardian: 29M Leaked Secrets — Why AI Agent Credentials Are Out of Control — cobertura do Help Net Security com análises específicas de IA
- Claude Code Can Consume, Transmit, and Compromise Your .env Files — análise de Martin Paul Eve sobre o falhanço das proibições no CLAUDE.md
- Claude Code Automatically Loads .env Secrets, Without Telling You — análise técnica da Knostic sobre o carregamento automático de segredos
- From .env to Leakage: Mishandling of Secrets by Coding Agents — análise mais ampla da Knostic abrangendo Claude e Cursor
- @zodchiii no X — O post viral que motivou este artigo (380 mil visualizações, 2,7 mil favoritos)