Como manter seus segredos fora do código gerado por IA e dos commits do Git

Os agentes de codificação de IA são rápidos, mas têm um ponto cego: eles colam alegremente uma chave de API em um arquivo, ecoam um token em um log ou fazem commit de um .env que você pretendia manter apenas localmente. Todo agente com acesso ao terminal — Claude Code, Cursor, Gemini CLI, Codex — também consegue ler a configuração do seu shell e os arquivos do projeto, que é exatamente onde as credenciais costumam se esconder. Este guia apresenta uma configuração prática e em camadas para que seus segredos fiquem fora do código gerado por IA e fora do seu histórico do Git.

Por que isso importa ainda mais com a IA

Uma chave vazada é um dos erros mais comuns e mais caros em software, e os assistentes de IA elevam o risco de duas maneiras. Primeiro, eles geram código rapidamente, então uma chave embutida no código pode acabar em uma dúzia de arquivos antes que você perceba. Segundo, os agentes ingerem contexto de forma agressiva — como diz um artigo sobre gerenciamento de segredos, a configuração do seu shell deve referenciar as chaves, não contê-las, porque o agente pode ler tudo o que seus dotfiles expõem. A solução não é desconfiar da ferramenta; é garantir que não haja segredos em texto puro para ela encontrar, antes de mais nada.

Passo 1: Mantenha os segredos em variáveis de ambiente, nunca no código

A regra básica: nenhuma chave de API, senha ou token deve jamais aparecer como uma string literal no código-fonte. Coloque-os em um arquivo .env na raiz do seu projeto e leia-os em tempo de execução.

# .env  — never committed
ANTHROPIC_API_KEY=sk-ant-...
DATABASE_URL=postgres://...

// app.js — reads from the environment, no secret in the file
const apiKey = process.env.ANTHROPIC_API_KEY;

Dessa forma, o código que você (e seu agente de IA) edita contém apenas o nome do segredo, nunca o seu valor.

Passo 2: Garanta que o .env nunca possa ser commitado

Adicione-o ao .gitignore antes de escrever um único segredo:

.env
.env.local
*.env

Em vez disso, faça commit de um .env.example com placeholders vazios, para que os colaboradores saibam quais variáveis configurar:

ANTHROPIC_API_KEY=
DATABASE_URL=

Se você já fez commit de um .env real, removê-lo em um novo commit não é suficiente — ele permanece no histórico. Rotacione a chave exposta imediatamente e trate-a como comprometida.

Passo 3: Ative a proteção contra push do GitHub

A proteção contra push do GitHub examina os commits no momento do push e bloqueia o push se detectar um segredo, interrompendo o vazamento antes que ele chegue ao remoto. Ela reconhece mais de 200 padrões de segredos de provedores como AWS, OpenAI, Stripe e muitos outros, e as atualizações de 2026 ampliaram os padrões bloqueados por padrão. É gratuita para repositórios públicos — ative-a nas configurações do seu repositório, em Settings → Code security. Pense nela como um cinto de segurança para o momento em que um agente (ou você) escorrega.

Passo 4: Não deixe os agentes coletarem a configuração do seu shell

Agentes com acesso ao shell conseguem ler .zshrc, .bashrc e .zshenv. Se você exportou chaves nesses arquivos por conveniência, o agente pode vê-las. Mantenha os segredos de uso geral da máquina fora dos seus dotfiles — carregue-os de um gerenciador de segredos ou do keychain do sistema operacional sob demanda, em vez de exportar texto puro na inicialização do shell.

Passo 5: Limite o escopo e rotacione

Dois hábitos limitam o dano caso algo de fato vaze, conselho também presente no guia de segurança de chaves de API da OpenAI:

• Privilégio mínimo: dê a cada chave o escopo mais restrito de que ela precisa e use chaves separadas por projeto e ambiente, para que um vazamento não exponha tudo.
• Rotacione regularmente: rotacione as chaves em uma programação e imediatamente sempre que suspeitar de exposição. Uma chave rotacionada transforma uma violação em um não evento.

Uma rápida lista de verificação

Antes de soltar um agente em um repositório:

1. Os segredos ficam no .env, lidos via process.env — nunca embutidos no código.
2. O .env está no .gitignore; apenas o .env.example é commitado.
3. A proteção contra push está ativada no remoto.
4. Nenhuma chave em texto puro nos dotfiles do shell.
5. As chaves têm escopo restrito e são rotacionadas em uma programação.

Nada disso te atrasa depois de configurado — e permite que você delegue mais trabalho ao seu agente de IA com muito menos com o que se preocupar.