Agentes de código com IA estão vazando segredos. Confira seus repositórios

Se você usa o Claude Code ou qualquer outro agente de código com IA, dedique dez minutos aos seus repositórios antes de tudo. Procure arquivos de configuração de agentes que foram commitados, troque todas as credenciais que eles guardam e ative o secret scanning do GitHub. Chaves roubadas são revendidas rápido (a Unit 42 descreve um caso que levou minutos), então as verificações vêm antes da história.

Faça estas verificações nos seus repos primeiro

Comece pelo arquivo no centro do caso do Claude Code: .claude/settings.local.json. A empresa de segurança Apiiro encontrou 104.185 cópias dele em 103.617 repositórios públicos, e 1.122 dessas cópias continham pelo menos um segredo (The Hacker News). Veja como procurar o seu.

1. 1Busque o arquivo pelo nome na sua organização do GitHub (troque pelo nome da sua org; requer o GitHub CLI).
2. 2Verifique se o arquivo chegou a ser commitado em cada repo em que você trabalha, inclusive em branches antigas. O histórico guarda o que o último commit apagou.
3. 3Leia as aprovações salvas em busca de qualquer coisa que lembre uma senha, token ou string de conexão.
4. 4Escaneie o histórico completo e adicione uma regra para senhas digitadas dentro de comandos, que os conjuntos de regras padrão costumam deixar passar.

# 1. Find the files across an organization
gh search code --owner YOUR-ORG --filename settings.local.json

# The same search in the GitHub web search box
#   org:YOUR-ORG path:.claude/settings.local.json

# 2. Was it ever committed, on any branch?
git log --all --oneline -- .claude/settings.local.json .claude/settings.json

# 3. List what you have approved with "don't ask again"
jq -r '.permissions.allow[]' .claude/settings.local.json

# 4. Grep the folder and its history for the usual suspects
grep -rEn 'PGPASSWORD=|sshpass -p|mysql -p|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{20,}' .claude/
git log --all -p -- .claude | grep -E 'PGPASSWORD=|sshpass -p|mysql -p|AKIA[0-9A-Z]{16}'

São chamadas padrão de git, jq e grep, mas trate o resultado como uma pista, não como um veredito. A busca de código do GitHub só enxerga o que está em uma branch hoje, e é por isso que o passo 2 existe.

Para a varredura com scanners, Gitleaks e TruffleHog são as duas ferramentas que a Apiiro usou. Rode-as no histórico e depois adicione uma regra personalizada, porque as regras padrão pegam uma chave, mas não uma senha que vem depois de uma flag.

gitleaks git --redact -v .
trufflehog git file://.

# .gitleaks.toml
[extend]
useDefault = true

[[rules]]
id = "password-inside-command"
description = "Password passed on a command line"
regex = '''(PGPASSWORD=|sshpass -p |mysql -p)\S+'''

Essa regra personalizada vale a pena. A Apiiro rodou as duas ferramentas em todos os arquivos que encontrou: o gitleaks sinalizou 564 dos 1.122 arquivos com segredos, o TruffleHog sinalizou 643, e nenhum dos dois pegou 215, em sua maioria senhas digitadas depois de PGPASSWORD=, sshpass -p ou mysql -p (The Hacker News).

A Apiiro também recomenda que as equipes de segurança tratem .claude/, .cursor/, .gemini/, .specstory/ e arquivos de memória de agentes como portadores de segredos, assim como o .env. Nós faríamos a mesma busca para cada agente instalado na sua equipe: uma transcrição salva pelo Cursor, pelo GitHub Copilot ou pelo Codex também pode conter uma chave colada.

Como um clique de aprovação coloca uma senha no seu repo

O Claude Code pergunta antes de executar a maioria dos comandos de shell. Se você escolhe "Yes, and don't ask again", ele grava uma regra de permissão em .claude/settings.local.json. A documentação da Anthropic diz que uma aprovação de Bash feita assim dura "permanently per repository and command" (documentação do Claude Code). O problema é o formato da regra. Ela pode ser um padrão como npm test *, ou pode ser o comando exato, e quando o comando exato contém uma senha, a senha passa a ficar salva em texto puro.

O arquivo deveria ficar local. Segundo a documentação de configurações da Anthropic, na primeira vez que o Claude Code o grava em um repo que ainda não o ignora, ele adiciona **/.claude/settings.local.json ao git excludes global, e um arquivo criado à mão precisa de uma linha sua no .gitignore (documentação do Claude Code). Isso protege um computador, não um clone novo, um arquivo feito à mão ou um commitado antes de a regra de ignore existir.

Mais de um terço dos segredos que a Apiiro encontrou abrem um banco de dados diretamente, incluindo 379 senhas de bancos. O restante inclui 43 logins SSH de servidores públicos, 42 tokens do GitHub, GitLab e npm e 23 chaves da AWS. Sessenta e três organizações eram donas de arquivos afetados e, em metade dos repos com algum segredo, o arquivo estava lá havia pelo menos 217 dias. A Apiiro não testou se algum deles ainda funciona, embora uma empresa notificada tenha confirmado que sua chave estava ativa.

A resposta da Anthropic até agora é um comentário no Hacker News

Um relatório de bug aberto em 2025 foi fechado por um bot automático como "not planned" após 60 dias sem atividade, e os pesquisadores da Apiiro dizem que nenhum dos relatórios relacionados que eles citam recebeu resposta da Anthropic (The Hacker News). A resposta pública veio no Hacker News, de um comentarista que se apresentou como "Boris from the Claude Code team". Ele escreveu que "Historically Claude Code has not done secret scrubbing", que a equipe está "looking into what we can do to prevent this" e que, neste caso, "the files were manually created and checked in". Acrescentou: "Permission rules are old hat. Everyone should be using auto mode instead."

Os dados da Apiiro combinam mal com a explicação do arquivo feito à mão. Em 539 dos 1.105 repositórios rastreados, um commit com o Claude como coautor alterou o arquivo. Uma linha de coautor não prova quem rodou o git, mas é difícil conciliá-la com arquivos criados manualmente. Para nós, os dados de commit são mais difíceis de descartar do que o comentário, e trataríamos o arquivo como algo que o Claude Code pode commitar até a Anthropic dizer o contrário.

O Grok Build vazou duas vezes, de formas diferentes

Duas histórias do Grok Build estão sendo confundidas, e elas exigem correções diferentes. (A cobertura chama a empresa de SpaceXSI ou SpaceXAI.)

A primeira veio no começo de 2026. Um pesquisador que publica como cereblab analisou o Grok Build 0.2.93 e relatou que ele enviava repositórios Git rastreados inteiros, com histórico de commits, segredos commitados e chaves de API, para um armazenamento na nuvem (The Next Web). Segundo essa análise, o envio foi cerca de 27.800 vezes maior do que a tarefa exigia, e a opção de privacidade, segundo o relato, não fazia nada. A xAI havia divulgado a ferramenta com a frase "nothing from your codebase transmitted to xAI servers during a session". Elon Musk reconheceu as transferências e disse que os dados anteriores dos usuários seriam apagados. O TNW acrescenta que nenhuma auditoria independente confirmou a exclusão.

A segunda é a que está agora no noticiário, e não tem nada a ver com repositórios. A empresa de segurança Claroc descobriu que os links de compartilhamento do Grok Build podem ser encontrados por pessoas para quem nunca foram enviados (Claroc). O Engadget relata que cada link usava uma frase aleatória de quatro palavras com até 38 bits de entropia, colocada "to the left of the domain" (Engadget). Isso a coloca no hostname, e a Claroc explica que serviços de DNS passivo coletam essas consultas. Chats compartilhados do ChatGPT e do Gemini guardam o segredo no caminho da URL, que o DNS nunca vê. "Nobody would guess one", escreve a Claroc, "and nobody needs to, because the dataset lists them."

Os apps expostos continham material real. A Claroc lista um mapa de territórios de vendas com 594 contas estratégicas, oito propostas de publicidade no X, quatro painéis de contas de anunciantes ativos, o app de funcionários de um grupo hospitalar com uma lista de mais de 3.500 pessoas e o quadro de turnos em tempo real de um corpo de bombeiros, com nome e número de matrícula de cada bombeiro. Dos endereços testados, 94,7% abriram sem nenhum login. A Claroc estima que cerca de 2% dos apps continham material grave o bastante para ser classificado como alto ou crítico.

A Claroc diz que a SpaceXSI derrubou os 24 apps criados por seus funcionários, "but not the apps of other Grok users and organizations". O Engadget acrescenta que a empresa, segundo o relato, só respondeu depois que a Claroc marcou Musk e outro executivo da empresa no X. O post da Claroc diz que a SpaceXSI respondeu às perguntas de um repórter, afirmando que os apps do Grok são privados até que o criador decida compartilhá-los, mas não respondeu ao relatório em si. Não encontramos nenhuma declaração dizendo que os outros apps serão derrubados.

A correção para os usuários é direta. Trate tudo o que for criado ou compartilhado pelo Grok Build como público, derrube os links de que você não precisa e troque qualquer credencial que tenha passado por um app que você compartilhou. Nenhuma linha de .gitignore ajuda aqui.

Chaves roubadas são revendidas em minutos

A Unit 42, da Palo Alto Networks, descreve o "token jacking", em que chaves de API de IA roubadas são revendidas por "transfer stations" do mercado cinza, que vendem acesso com desconto a modelos de ponta (Unit 42). Entre as fontes de chaves listadas estão repositórios de código expostos, infostealers e pacotes npm envenenados. Em um caso, os atacantes integraram credenciais expostas a uma transfer station em minutos, e "nearly a million dollars in charges" se seguiram até a descoberta. A Unit 42 diz que as vítimas têm "very little recourse to recover funds". As defesas que ela indica são as manjadas: limites de gasto com alertas, tokens de curta duração no lugar de chaves de longa duração e revisão de todas as contas privilegiadas que podem alterar limites.

Corrija o vazamento: ignore, deixe de rastrear, depois troque as chaves

Primeiro troque as chaves, depois faça a limpeza. Uma chave revogada é inútil em todo fork e cópia em cache, enquanto uma chave que você apenas apagou do último commit continua ativa no histórico. O GitHub diz para trocar uma credencial exposta imediatamente e classifica a limpeza do histórico como "time-intensive and often unnecessary if you've already revoked the credential" (documentação do GitHub).

# Rotate the exposed credentials first (table below), then:

# Stop tracking the local file (keeps your copy on disk)
git rm --cached .claude/settings.local.json

# Add to the repo's OWN .gitignore, not just your global excludes
printf '%s\n' '.claude/settings.local.json' '.specstory/' >> .gitignore

git add .gitignore
git commit -m "Stop tracking agent local settings"

# Drop any allow rule that looks like it holds a secret, even if never committed
jq '.permissions.allow |= map(select(test("PGPASSWORD|password|token|secret|key"; "i") | not))' \
  .claude/settings.local.json > .claude/settings.local.json.new \
  && mv .claude/settings.local.json.new .claude/settings.local.json

Pense bem antes de ignorar .cursor/ ou .gemini/ por inteiro, porque algumas equipes commitam regras compartilhadas ali de propósito.

Como trocar chaves nos principais provedores

Todo provedor tem um botão no console para isso, e a ordem segura é criar a substituta, fazer o deploy e só então desativar a chave antiga. Apagar primeiro pode derrubar a produção.

Para qualquer provedor que não esteja na tabela, incluindo Anthropic e xAI, não verificamos os passos de rotação, então siga a documentação dele. No caso de senhas de banco de dados e logins SSH, a maior parte do que a Apiiro encontrou, troque a senha, encerre as sessões abertas e depois confira os logs de acesso a partir do dia em que o arquivo foi commitado pela primeira vez.

Ative os scanners do GitHub e conheça os limites deles

O secret scanning verifica o histórico completo de todas as branches, além de issues, pull requests, discussions e wikis. Ele é gratuito e automático em repositórios públicos; em repos privados e internos de uma organização, exige o GitHub Secret Protection (documentação do GitHub). Quando o formato de chave de um parceiro é detectado, o GitHub notifica esse provedor, que pode revogar a chave sem nenhum alerta no seu repositório.

O push protection é a camada que teria barrado muitos desses arquivos antes de se tornarem públicos. Ele bloqueia um push que contenha um segredo detectado. Segundo a documentação do GitHub, a configuração no nível do usuário vem ativada por padrão para pushes em repositórios públicos no GitHub.com, enquanto a configuração no nível do repositório vem desativada por padrão e precisa que um admin do repo, um dono da org ou um gerente de segurança a ative (documentação do GitHub). Ele verifica padrões de provedores, padrões genéricos como chaves privadas e strings de conexão, seus padrões personalizados e uma categoria detectada por IA para segredos não estruturados, como senhas, em prévia pública. Essa última categoria parece mirar a lacuna que a Apiiro encontrou. Pushes pela API REST não têm essa proteção; pushes pela linha de comando, commits pela interface web e uploads de arquivos têm.

Conheça também a válvula de escape. Por padrão, qualquer pessoa com acesso de escrita pode contornar um bloqueio escolhendo um motivo, incluindo "I'll fix it later", o que abre um alerta e envia e-mail aos donos. Se seus agentes commitam em seu nome, configure o delegated bypass para que só pessoas indicadas possam liberar um segredo.

Configurações de permissão de agentes para mudar hoje

Três hábitos teriam mantido a senha fora do arquivo. Aprove padrões, nunca comandos literais com credenciais. Coloque os segredos em variáveis de ambiente, para que o comando carregue um nome, não um valor. E negue ao agente o acesso aos arquivos que guardam segredos logo de início. A documentação de configurações da Anthropic mostra o formato:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

O comando que seu agente deve executar é parecido com psql "$DATABASE_URL", de modo que a regra de aprovação armazene o nome de uma variável e mais nada. Carregue a variável a partir de um gerenciador de segredos ou do perfil do seu shell, não de um arquivo que o agente consiga ler.

Dois detalhes da documentação importam para equipes: as regras allow no .claude/settings.json commitado só valem depois que cada colega confia na pasta, enquanto as regras deny e ask se aplicam imediatamente, e os modos auto e bypassPermissions não entram em vigor a partir das configurações de projeto ou locais. Organizações podem travar as regras allow com allowManagedPermissionRulesOnly. O integrante da equipe do Claude Code citado acima diz que o modo auto torna as regras de permissão desnecessárias. Ainda assim, manteríamos as regras deny para .env: duas linhas, aplicadas no instante em que o arquivo é commitado.

Em outras ferramentas, os nomes das configurações mudam, mas a pergunta é a mesma: onde a ferramenta guarda aprovações, histórico ou transcrições, e esse lugar fica dentro de um repo? Pela documentação, a Apiiro concluiu que o Claude Code é o único dos 16 agentes de código que ela comparou com confirmação de que salva por padrão o comando aprovado completo em um arquivo do projeto. Os outros quinze ainda podem vazar por transcrições, chaves coladas e arquivos de memória. Nossa comparação de agentes de código para terminal e o artigo Cursor vs Copilot vs Windsurf mostram o que cada um armazena.

O controle mais forte não depende de um prompt. Rode os agentes em um container ou sandbox só com as credenciais de que aquela tarefa precisa, com escopos limitados e vida curta. Explicamos a mecânica em Como conter um agente de IA.

O usuário é dono da rotação, o fornecedor é dono do padrão

Digitar uma senha em um comando é erro do usuário, e o usuário é dono da rotação. Mas uma ferramenta que guarda o comando completo em um arquivo do projeto e depois depende de um exclude no seu diretório home para mantê-lo privado tem uma proteção que só funciona em um notebook.

Padrões são política, e aqui o padrão decidiu o resultado. Um Claude Code que removesse segredos antes de salvar uma regra, ou que gravasse a linha de ignore no .gitignore do próprio repo, teria fechado o buraco na origem. A Anthropic diz que está analisando isso (gostaríamos de uma data). Um relatório de bug fechado por um bot de inatividade não passa confiança, e os dados de commit não batem com "manually created".

O Grok Build é o pior caso na história dos links de compartilhamento, porque o usuário não fez nada de errado. Um link que qualquer pessoa pode encontrar por DNS passivo não é privado, seja lá o que o menu de compartilhamento dê a entender. E o envio anterior contradisse uma frase de marketing que dizia o oposto. Não colocaríamos uma lista de clientes, um mapa de territórios de vendas ou uma credencial de produção no Grok Build até o problema dos links ser corrigido e uma auditoria externa confirmar a exclusão. Se isso mudar, nossa opinião também muda.

Trate as pastas de agentes como arquivos .env e reserve uma tarde para a configuração acima. Você pode comparar as próprias ferramentas em nosso ranking de assistentes de código com IA e o lado de segurança do ecossistema no ranking de ferramentas de cibersegurança com IA.

Um checklist para a equipe toda

Marque o que é verdade hoje e a pontuação mostra por onde começar. Os itens de dois pontos são os que faríamos antes do almoço.

Perguntas frequentes

É seguro commitar o .claude/settings.local.json?

Não. Ele guarda suas aprovações pessoais e pode conter credenciais. A documentação da Anthropic diz que o Claude Code mantém o arquivo fora do git quando o cria, por meio de um exclude global, e que uma cópia feita à mão precisa de uma linha de ignore sua. Adicione-o ao .gitignore de cada repo e pare de rastreá-lo com git rm --cached se ele chegou a ser commitado.

Preciso trocar as chaves se meu repo é privado?

Sim, se o arquivo chegou a conter uma credencial. Repos privados são clonados em notebooks e runners de CI, forkados para outras contas e às vezes viram públicos. O secret scanning do GitHub para repos privados de organizações exige um plano pago, então o seu pode não ter tido nenhuma verificação automática.

Apagar o arquivo do meu repo remove o segredo?

Ele remove o segredo do último commit e de mais nada. Histórico, forks e caches guardam a versão antiga, e a Apiiro encontrou 734 segredos que aparecem apenas em versões mais antigas do arquivo. Troque a credencial primeiro e só reescreva o histórico se quiser um repo mais organizado.

GitHub Copilot, Cursor e Codex têm o mesmo problema?

A Apiiro confirmou esse comportamento, o de salvar por padrão o comando aprovado completo em um arquivo do projeto, apenas para o Claude Code entre os 16 agentes que comparou. Isso não livra os outros. Qualquer agente que grave transcrições ou memória no seu diretório de trabalho precisa das mesmas regras de ignore.