O Claude Code, assistente de programação com inteligência artificial desenvolvido pela Anthropic, está no centro de uma investigação de segurança que revelou o vazamento de senhas, tokens de acesso e outras credenciais em repositórios públicos do GitHub. O problema envolve o armazenamento de permissões concedidas pelos desenvolvedores à ferramenta, que pode registrar comandos completos do terminal, incluindo informações confidenciais utilizadas durante operações automatizadas.
A investigação conduzida pela empresa de segurança Apiiro identificou 1.122 arquivos contendo segredos reais entre 104.185 arquivos públicos analisados. Ao todo, foram encontrados 1.379 segredos distintos, incluindo senhas de bancos de dados, credenciais SSH, chaves de serviços em nuvem e tokens de acesso a plataformas de desenvolvimento. Entre os casos mais preocupantes estavam credenciais administrativas de bancos de dados utilizados em aplicações médicas e ambientes de produção.
O episódio chama a atenção para um problema que vai além de uma configuração inadequada do Git. O mecanismo criado para facilitar a interação com assistentes de programação pode transformar comandos temporariamente autorizados em registros permanentes de informações sensíveis. Isso demonstra como ferramentas de codificação com IA precisam ser tratadas como componentes da infraestrutura de desenvolvimento, com políticas próprias de segurança, auditoria e proteção de dados.
Como o Claude Code salva credenciais em texto simples
O principal elemento envolvido na exposição é o arquivo .claude/settings.local.json, utilizado pelo Claude Code para armazenar configurações e permissões específicas de um projeto. Entre essas configurações estão as autorizações concedidas para executar comandos no terminal sem solicitar aprovação repetidamente.
O problema aparece quando o desenvolvedor utiliza a opção “Sim, e não pergunte novamente” durante uma solicitação de autorização. Em vez de guardar somente uma indicação genérica de que determinado tipo de operação está autorizado, o Claude Code registra uma regra de permissão que pode preservar o conteúdo do comando aprovado.
Imagine um desenvolvedor que solicita à IA a execução de uma consulta em um banco de dados de produção. Para realizar a operação, o comando pode conter informações como endereço do servidor, nome de usuário e senha.
Se o desenvolvedor aprovar esse comando permanentemente, o assistente poderá registrar uma regra contendo os mesmos parâmetros em .claude/settings.local.json. Dessa maneira, uma credencial que deveria permanecer restrita ao ambiente de execução passa a existir em um arquivo de configuração legível e persistente.
O arquivo não representa necessariamente um problema quando permanece exclusivamente na máquina do desenvolvedor. Entretanto, sua inclusão em um repositório compartilhado transforma uma configuração local em uma possível fonte de vazamento de credenciais.
A diferença entre o Git global e o Git local
Um dos aspectos mais importantes da descoberta da Apiiro está na maneira como o Claude Code tenta evitar que esse arquivo seja enviado ao GitHub.
A ferramenta adiciona uma regra ao arquivo global de exclusões do Git do usuário, normalmente configurado por meio de core.excludesFile. Essa proteção funciona em condições específicas, impedindo que o arquivo seja rastreado automaticamente em determinados repositórios daquela máquina.
Entretanto, existe uma diferença fundamental entre uma exclusão global e uma regra presente no .gitignore do próprio projeto.
A configuração global pertence ao ambiente local do desenvolvedor. Portanto, ela não acompanha o repositório quando o projeto é clonado em outro computador, transferido para outro integrante da equipe ou disponibilizado publicamente.
Também existe o risco de o diretório se transformar em um repositório Git depois que o arquivo de configuração já foi criado. Nesse cenário, a proteção global pode não impedir a inclusão do arquivo em determinadas operações.
A ausência de uma regra compartilhada no .gitignore significa que outros desenvolvedores podem acabar rastreando e enviando o arquivo sem perceber a presença de informações confidenciais.
Commits e propagação das credenciais em forks
A investigação também encontrou evidências de participação do próprio agente nos processos de alteração dos arquivos expostos.
Em 539 dos 1.105 repositórios com segredos rastreados, os pesquisadores identificaram commits coassinados pelo Claude que modificaram o arquivo de permissões.
Isso não significa que o assistente tenha publicado autonomamente todas essas credenciais. O dado demonstra, porém, que o agente participou de alterações que acabaram integradas ao histórico dos projetos.
Outro problema está na persistência das informações no histórico do Git. Excluir .claude/settings.local.json do diretório atual não elimina automaticamente versões anteriores armazenadas nos commits.
A situação fica ainda mais complicada quando existem forks. A Apiiro identificou 211 forks de 74 repositórios que também continham as credenciais encontradas nos projetos originais.
Assim, mesmo depois de remover um arquivo ou excluir um branch, as informações podem continuar disponíveis em cópias independentes do projeto.
O que a investigação da Apiiro encontrou no GitHub
Os números revelados pela investigação ajudam a dimensionar a gravidade do problema.
A empresa examinou 104.185 cópias públicas de .claude/settings.local.json, distribuídas por 103.617 repositórios. Desse conjunto, 1.122 arquivos continham pelo menos um segredo considerado real pelos pesquisadores.
Os arquivos reuniam 1.379 credenciais distintas, divididas entre chaves de provedores conhecidos e senhas ou tokens associados a servidores públicos.
Entre os principais achados estavam:
- 379 senhas de bancos de dados, incluindo credenciais relacionadas a ambientes de produção.
- 122 chaves Supabase Service Role, capazes de conceder privilégios elevados aos projetos correspondentes.
- 43 credenciais SSH para servidores acessíveis publicamente.
- 42 tokens de GitHub, GitLab e npm, potencialmente úteis para acessar repositórios e publicar pacotes.
- 23 chaves AWS, relacionadas ao acesso a serviços da infraestrutura em nuvem.
A pesquisa também identificou credenciais pertencentes a 63 organizações. Entre os exemplos estavam uma chave administrativa de uma plataforma de banco de dados em nuvem, uma senha de produção do Azure PostgreSQL, um token de produção do Square e a senha de proprietário de um banco PostgreSQL utilizado por uma aplicação de prontuários médicos.
A exposição não estava limitada aos arquivos atualmente presentes nos repositórios. A análise do histórico Git encontrou outros 734 segredos em versões anteriores de arquivos distribuídos por 509 repositórios.
Além disso, os pesquisadores encontraram informações confidenciais em arquivos compartilhados de configuração do Claude, históricos de conversas com agentes de programação e documentos de transferência de tarefas.
Por que Gitleaks e TruffleHog não identificaram tudo
Outro resultado preocupante envolve as ferramentas tradicionais de identificação de segredos.
Soluções como Gitleaks e TruffleHog são amplamente utilizadas para procurar chaves de API, tokens conhecidos e outros padrões de credenciais em repositórios.
Entretanto, essas ferramentas podem apresentar limitações quando encontram senhas incorporadas diretamente em comandos de terminal.
Uma chave AWS, por exemplo, possui formatos relativamente reconhecíveis. Uma senha arbitrária escrita como parâmetro de um comando PostgreSQL pode não apresentar nenhuma assinatura que permita sua identificação automática.
Segundo os dados divulgados na investigação, 215 arquivos com segredos não foram identificados por nenhuma das duas ferramentas.
Isso demonstra que a utilização isolada de scanners tradicionais não oferece garantia de que um repositório esteja completamente livre de informações confidenciais.
Também é importante observar que a identificação de uma credencial não comprova, por si só, que ela continua válida ou que foi utilizada por terceiros. A pesquisa identificou exposições plausíveis, mas não realizou testes de autenticação dessas credenciais. Uma organização afetada confirmou que uma das chaves expostas ainda estava ativa.
Como proteger projetos e rotacionar credenciais expostas
Desenvolvedores e equipes de segurança precisam tratar qualquer ocorrência desse tipo como um possível incidente de exposição de informações confidenciais.
A primeira medida não deve ser simplesmente excluir o arquivo comprometido. É necessário invalidar as credenciais que podem ter sido publicadas.
1. Identifique e rotacione as credenciais
Comece procurando o arquivo .claude/settings.local.json em todos os repositórios utilizados pela equipe.
Examine também o histórico de commits e outros arquivos de configuração relacionados a agentes de programação.
Se encontrar senhas, tokens ou chaves privadas, providencie imediatamente sua revogação e substituição. Essa etapa precisa acontecer antes da limpeza do histórico Git, pois remover um arquivo não invalida uma credencial que já foi exposta.
Priorize credenciais administrativas, acessos a bancos de dados de produção, chaves de infraestrutura em nuvem e tokens com permissões de escrita.
2. Corrija o arquivo .gitignore
Adicione uma regra explícita ao .gitignore localizado na raiz do projeto:
.claude/settings.local.jsonPara projetos que precisam proteger outros arquivos locais de agentes, considere também regras específicas para históricos, transcrições e configurações que possam conter informações confidenciais.
A equipe deve revisar cuidadosamente essas regras para não excluir arquivos de configuração compartilhados que sejam necessários ao funcionamento do projeto.
3. Remova o arquivo do índice do Git
Se o arquivo já estiver sendo rastreado, adicionar uma regra ao .gitignore não será suficiente.
Utilize o seguinte comando:
git rm --cached .claude/settings.local.jsonA opção --cached remove o arquivo do índice do Git, preservando sua cópia no computador do desenvolvedor.
Depois, registre a alteração:
git add .gitignore
git commit -m "Remove configuracao local do Claude Code do Git"Essa operação impede que o arquivo continue sendo acompanhado nos próximos commits, mas não elimina as versões anteriores do histórico.
Caso existam credenciais em commits antigos, será necessário avaliar a reescrita do histórico, coordenar a operação com os colaboradores e verificar também os forks e outras cópias existentes.
4. Utilize variáveis de ambiente e gerenciadores de segredos
Uma prática mais segura consiste em evitar a inclusão de senhas diretamente nos comandos enviados aos assistentes de programação.
Sempre que possível, utilize variáveis de ambiente, arquivos de configuração protegidos e gerenciadores de segredos, como AWS Secrets Manager, HashiCorp Vault ou soluções equivalentes.
Por exemplo, em vez de inserir uma senha diretamente em um comando SQL, utilize uma variável previamente configurada no ambiente de execução.
psql "$DATABASE_URL"A variável deve ser fornecida por um mecanismo seguro, sem ser registrada em arquivos compartilhados ou incluída em comandos armazenados pelo agente.
Também é recomendável revisar as permissões concedidas ao Claude Code, evitando autorizações permanentes desnecessárias para operações que envolvam credenciais, produção ou infraestrutura administrativa.
5. Implemente auditorias contínuas
Configure verificações automatizadas com Gitleaks ou TruffleHog nos processos de integração contínua (CI/CD).
Essas ferramentas devem analisar tanto os novos commits quanto os arquivos já existentes nos repositórios. Complementarmente, estabeleça revisões específicas para configurações de agentes de IA, históricos de conversas e arquivos temporários.
A prevenção também depende de políticas claras: nenhum segredo deve ser considerado seguro apenas porque está armazenado em um diretório de configuração local.
O impacto do descuido com diretórios de agentes no desenvolvimento
O caso envolvendo o Claude Code demonstra que a adoção de inteligência artificial no desenvolvimento de software cria novas superfícies de exposição que precisam ser consideradas pelas equipes de tecnologia.
Ferramentas como Claude Code, Cursor e GitHub Copilot podem interagir com arquivos, executar comandos e armazenar informações relacionadas ao contexto de desenvolvimento. Essa capacidade aumenta a produtividade, mas também exige atenção especial aos dados que circulam durante as operações automatizadas.
O problema não está simplesmente em utilizar assistentes de programação. A questão é permitir que comandos contendo informações confidenciais sejam armazenados sem uma política adequada de proteção e auditoria.
Para administradores Linux, engenheiros DevOps e profissionais de segurança, a principal lição é que diretórios de agentes precisam fazer parte das rotinas de higienização dos repositórios Git.
Credenciais expostas devem ser revogadas, arquivos sensíveis precisam ser excluídos do rastreamento e o histórico dos projetos deve ser auditado. Essas medidas são essenciais para evitar que uma autorização aparentemente inofensiva se transforme em uma porta de entrada para ambientes corporativos.
