Permissão persistente também é dado sensível: a lição do Claude Code

A Apiiro encontrou 1.122 cópias públicas de .claude/settings.local.json com pelo menos um segredo, segundo reportagem do The Hacker News.[1] O caminho de exposição passa pela autorização persistente: quando uma regra guarda um comando exato contendo credenciais, esses valores também ficam no arquivo em texto puro.[1] A conveniência merece ser tratada como uma decisão de armazenamento, não apenas como um clique para reduzir interrupções.

O que muda para quem desenvolve

Segundo a documentação citada na matéria, o Claude Code adiciona o arquivo às exclusões globais do Git na primeira gravação em um repositório.[1] Isso não remove arquivos já rastreados nem transporta a proteção para outra máquina como faria uma regra no .gitignore do projeto.[1] Minha leitura: uma proteção dependente do ambiente do autor não deve ser confundida com uma propriedade do repositório.

O levantamento também encontrou segredos no histórico e em forks; somando configurações compartilhadas e registros de conversas, chegou a 2.539 segredos em 1.994 repositórios.[1] Isso amplia o perímetro de revisão. Não basta olhar o último commit nem procurar apenas arquivos tradicionalmente associados a credenciais.

Como aplicar

Comece pelo desenho dos comandos. Prefira referências a um mecanismo de entrega de segredos, sem materializar valores em linhas que possam virar permissões, documentação ou histórico. Revise as regras persistidas como revisaria um arquivo de configuração de produção.

Para um experimento seguro, use um repositório descartável e um marcador fictício que não autentique em serviço algum. Observe o que é salvo ao persistir uma autorização, verifique se o arquivo aparece como rastreado e confira o comportamento em uma cópia limpa do projeto. O objetivo é entender a persistência, não simular um vazamento com uma chave real.

Se houver exposição real, a recomendação da reportagem é rotacionar antes de limpar arquivos e histórico.[1] Organize a resposta em três entregas: invalidar o acesso, interromper novas distribuições e localizar cópias remanescentes. Cada uma precisa de evidência própria.

Cuidados e limites

A Apiiro não validou sistematicamente se todas as credenciais permaneciam ativas; uma empresa notificada confirmou que sua chave estivera válida.[1] Portanto, contagem de segredos não equivale a contagem de invasões.

Também não troque uma permissão exata por um padrão amplo apenas para retirar o segredo. Isso pode resolver a persistência do valor e piorar o alcance da autorização. A meta é manter o comando restrito e a credencial fora da configuração, sem transformar silêncio do agente em sinal de segurança.

Fonte

[1] Fonte: The Hacker News