Agentes de código com IA vazam mais segredos? Os números de 2026 da GitGuardian e um checklist de 10 minutos

Segundo o State of Secrets Sprawl 2026 da GitGuardian, os commits assistidos pelo Claude Code vazaram um segredo em 3,2% dos casos, contra uma base de 1,5% no conjunto de commits públicos do GitHub. O mesmo texto conta 24.008 segredos únicos em arquivos de configuração relacionados ao MCP no GitHub público, 2.117 deles válidos. São medições reais e têm limites: descrevem repositórios públicos, comparam com todos os commits e a própria GitGuardian alerta contra ler a diferença como falha da ferramenta. Este guia apresenta os números como a fonte os dá, explica por que os agentes e seus arquivos de configuração mudam onde os segredos vão parar e traz um checklist de cerca de 10 minutos.

O que a GitGuardian relatou sobre segredos e agentes de código com IA?

A GitGuardian vende detecção de segredos, então tem dados e também interesse no assunto. Vale ter as duas coisas em mente. Citamos as publicações dela e não acrescentamos nada: a página do relatório State of Secrets Sprawl 2026 e o texto da GitGuardian com os resultados. Os números abaixo vêm dessas duas páginas, como as lemos em 18 de outubro de 2026.

Algumas observações para ler a tabela.

Os 3,2% são uma taxa por commit. O texto fala em “secret-leak rate” e não define o termo. A leitura natural é a parcela de commits que contêm um segredo escrito direto no código, mas a fonte não diz isso expressamente.

A base é qualquer commit público. Não é uma base de commits humanos cuidadosos nem de commits de quem usa outras ferramentas de IA. Uma diferença entre 3,2% e 1,5% pode vir da ferramenta, do tipo de projeto em que ela é usada, de quanto código é revisado ou das três coisas. O relatório não as separa.

A GitGuardian não trata isso como falha da ferramenta. O texto diz que a diferença não deve ser lida como uma simples falha da ferramenta: as pessoas continuam decidindo o que aceitar, editar, ignorar ou enviar, e um usuário pode ignorar um aviso ou levar o modelo a escrever código inseguro.

Os números do MCP falam de repositórios públicos. Os 24.008 são segredos únicos encontrados em arquivos de configuração relacionados ao MCP enviados ao GitHub público. O texto acrescenta que guias populares de instalação do MCP costumam mandar colocar chaves de API direto em arquivos de configuração, em argumentos de linha de comando ou em strings de conexão. Não achamos em nenhuma das duas páginas tamanho de amostra, método de coleta ou período para esse número. Trate-o como uma contagem da GitGuardian, não como uma taxa.

Alguns detalhes aparecem em uma página só. A página do relatório não mostrava os 3,2% e 1,5% quando a lemos, apenas o resumo “cerca do dobro”. O texto tem os dois e também as 2.117. Quando um número aparece em uma página só, a tabela indica qual.

Outro número da mesma fonte muda o que você faz depois de um vazamento. A GitGuardian testou de novo credenciais válidas em 2022 e viu que mais de 64% ainda funcionavam em janeiro de 2026. Uma chave vazada não expira só porque ninguém reparou nela.

Por que os agentes de código mudam onde os segredos vão parar?

Um agente é um programa que lê arquivos, executa comandos e envia parte do que vê a um provedor de modelos. Esse é o trabalho dele. Para os segredos, disso decorrem três coisas.

Agentes leem os arquivos em que as pessoas guardam segredos. Um arquivo .env é o lugar padrão das chaves locais, e um agente que explora um projeto para entendê-lo muitas vezes abre esse arquivo. Os valores então viajam com o resto do contexto até o provedor. Uma regra como .gitignore mantém um arquivo fora de um commit, mas não promete nada sobre o que um agente pode ler, e cada agente trata isso de um jeito.

Agentes escrevem configuração. Quando um agente adiciona um servidor MCP, monta um teste ou liga um banco de dados, a mudança mais rápida que funciona costuma ser um valor literal em um arquivo. O commit seguinte o inclui. Uma pessoa talvez tivesse parado ali. Um agente a quem se pede para fazer o teste passar pode não parar, e quem revisa um diff longo pode não notar mais uma linha.

A configuração do MCP coloca credenciais em um tipo novo de arquivo. Um servidor MCP precisa se autenticar em algum lugar, e o arquivo de configuração é onde ficam seus ajustes. Guias que mostram uma chave dentro do arquivo fazem disso o caminho fácil. Esses arquivos também são fáceis de commitar: ficam na pasta do projeto, muitas vezes como .mcp.json, ao lado do código.

Nada disso quer dizer que as ferramentas sejam descuidadas. Um novo ator agora mexe nos arquivos onde ficam os segredos, em alta velocidade, e as proteções mais antigas foram pensadas para uma pessoa digitando um commit. As proteções que ainda funcionam são as que não dependem de alguém se lembrar.

O que dá para fazer em 10 minutos?

Cada passo tem seu tempo. Se você fizer só os dois primeiros, já tratou da exposição que é real.

1. Descubra o que um agente consegue alcançar (2 minutos)

Na pasta em que você trabalha, rode:

npx -y zn-gate reach

O comando lista os nomes, nunca os valores, dos segredos dos seus arquivos .env, os arquivos de credenciais da sua pasta pessoal, as variáveis de ambiente com nome de segredo e os achados em servidores MCP e nas configurações dos agentes. É somente leitura e não envia nada. Se preferir não usar uma ferramenta para isso, procure no seu projeto .env, .mcp.json, .cursor/, .codex/ e .claude/ e abra cada um.

2. Troque tudo o que foi exposto (3 minutos)

Se uma chave real já esteve em um arquivo commitado, em um branch enviado, em um chat ou em uma configuração que você compartilhou, trate-a como exposta. Crie uma chave nova no provedor, atualize os lugares que a usam e revogue a antiga. Faça isso mesmo que o repositório seja privado: a GitGuardian relata que repositórios internos têm cerca de seis vezes mais chance que os públicos de conter segredos escritos direto no código, e um repositório privado pode se tornar público ou ser copiado.

Troque primeiro e arrume depois. Apagar o arquivo ou reescrever o histórico do git não adianta se alguém já tem uma cópia da chave.

3. Tire os segredos dos arquivos de configuração do MCP (2 minutos)

Troque cada valor literal de uma configuração do MCP por uma referência a algo que esteja fora do arquivo. Qual forma funciona depende do seu cliente, então consulte a documentação dele. Muitos clientes permitem passar uma variável pelo nome ou expandir uma variável de ambiente na entrada, e um cofre ou gerenciador de segredos pode fornecer o valor na hora de iniciar. O objetivo é que o arquivo no seu repositório não contenha nenhum valor que funcione sozinho.

Esta é a forma da mudança, com um nome de exemplo e nenhum valor real:

{
  "mcpServers": {
    "example-service": {
      "command": "npx",
      "args": ["-y", "example-mcp-server"],
      "env": { "EXAMPLE_API_KEY": "<set in your environment, not here>" }
    }
  }
}

Se uma chave já estava no arquivo e o arquivo saiu da sua máquina, volte ao passo 2.

4. Adicione um scanner de segredos antes dos commits (2 minutos)

Um scanner que roda a cada commit pega o erro que passa por todo o resto. Duas opções comuns são o ggshield, da GitGuardian, e o gitleaks, que é código aberto. Os dois podem rodar como hook de pre-commit. Os comandos de instalação mudam entre versões, então siga as instruções atuais do README de cada projeto. Escolha um, rode uma vez sobre o seu histórico e ative para os commits novos.

Isso não substitui os outros passos. Um scanner de commits vê o que você commita. Ele não vê o que um agente lê do seu disco e envia a um modelo.

5. Restrinja o que o agente pode ler (1 minuto, mais as perguntas)

Use primeiro as configurações do próprio agente: a maioria tem regras de permissão e arquivos ignorados, e o comportamento exato varia. Depois, se quiser uma camada que funcione com vários agentes, o zn-gate é uma opção. É código aberto (MIT), roda na sua máquina e não exige conta.

npx -y zn-gate init
npx -y zn-gate env shadow .env
npx -y zn-gate check

O init encontra Claude Code, Codex CLI, Cursor e OpenCode, mostra a configuração de cada um e pergunta antes de cada mudança. O env shadow .env move os valores reais para um cofre criptografado local e deixa no arquivo marcadores como __ZN_STRIPE_KEY__. Na primeira vez, rode npx -y zn-gate unlock para criar o cofre. O check testa a configuração com um segredo falso em uma pasta temporária e avisa se algum agente não está protegido. Rode o init no seu próprio terminal: quando um agente ou um script o executa, ele só imprime os passos.

Depois revise no que este projeto configura seus agentes para confiar:

npx -y zn-gate audit
npx -y zn-gate scan .

O npx -y zn-gate audit revisa .claude/, .mcp.json, .codex/, .cursor/, hooks, AGENTS.md e CLAUDE.md, plugins e skills. Adicione --include-home para revisar também as configurações da sua pasta pessoal. O zn-gate scan procura segredos vazados nos arquivos de configuração e os relata com o próximo passo. As mesmas verificações podem rodar no CI como GitHub Action.

O que esses passos não cobrem?

• Chaves fora da sua máquina. Uma chave guardada no console de um terceiro, em uma variável de CI ou em um chat fica fora do que uma ferramenta local pode proteger. Limite essas chaves com tetos de gasto e vida curta.
• Segredos que suas ferramentas não reconhecem. Scanners procuram formatos e nomes conhecidos. Um token próprio sem forma reconhecível pode passar por qualquer um deles, zn-gate inclusive. Dar nomes claros às variáveis ajuda.
• Agentes e editores que o zn-gate só suporta em parte. O suporte varia por agente. A tabela de compatibilidade mostra o que cada um permite. Em alguns editores o zn-gate funciona apenas como servidor MCP que o agente escolhe chamar, o que não é proteção automática.
• O que os números significam para você. Os números da GitGuardian descrevem o GitHub público. Seus repositórios privados podem ser diferentes, para mais ou para menos.

O zn-gate é uma das formas de fazer o passo 5, e é a que nós construímos. Os outros passos não dependem dele. A troca de chaves e o scan são o que fecha a exposição que já existe.

Onde ler mais?

As duas páginas da GitGuardian citadas acima são as fontes primárias. Para os detalhes do zn-gate, veja a documentação de reach e do scrubber e cofre de segredos. Para o básico de manter um .env fora do alcance de um agente, leia como impedir com um único comando que Claude Code, Codex CLI, Cursor e OpenCode leiam seu .env. Para ver como um hook podia ser contornado e como isso foi corrigido, leia como um agente de código podia ler seu arquivo .env de forma indireta. O zn-gate tem licença MIT, roda localmente e não exige conta: GitHub e Install.