Vazamentos de Segredos do Claude Code: Apiiro Encontra Credenciais em 1.122 Arquivos Públicos no GitHub

Os vazamentos de segredos do Claude Code colocaram as aprovações salvas da Anthropic sob escrutínio depois que a Apiiro relatou ter encontrado credenciais em 1.122 arquivos públicos de configurações no GitHub. Sua pesquisa de 5 de novembro descreve um recurso que memoriza comandos contendo segredos. A publicação exige outra etapa: fazer commit e enviar o arquivo resultante.

A tensão está entre um atalho útil e o registro sensível que ele cria. Desenvolvedores aprovam uma operação para concluir o trabalho, enquanto o software preserva informações que merecem proteção separada. Uma decisão sobre execução se torna uma decisão sobre armazenamento, muitas vezes sem que o usuário trate essas escolhas como distintas.

A Anthropic reconheceu a preocupação, ao mesmo tempo em que enfatizou que o arquivo de configurações deve permanecer local. O Cursor oferece uma comparação útil porque sua documentação também aborda a execução autônoma e seus riscos. Entre esses produtos, a questão é como os sistemas de permissões preservam a conveniência sem criar outro lugar em que credenciais se acumulam.

O Que a Descoberta sobre Vazamentos de Segredos do Claude Code Realmente Mede

A pesquisa sobre exposição de credenciais da Apiiro examinou 104.185 cópias públicas de .claude/settings.local.json. Ela identificou 1.379 segredos distintos nos 1.122 arquivos sinalizados. Os pesquisadores não testaram essas credenciais, portanto a contagem não estabelece acesso funcional nem invasões bem-sucedidas.

A manchete mede arquivos expostos, e não contas comprometidas. Essa distinção é importante para a resposta a incidentes, decisões de compra e qualquer alegação sobre a gravidade da descoberta. A presença de uma credencial estabelece um motivo para investigar, enquanto sua validade e permissões determinam as consequências imediatas.

O fluxo de trabalho subjacente é familiar. Um assistente de programação propõe uma operação, o desenvolvedor a revisa, e uma aprovação persistente reduz futuras interrupções. A consequência inesperada aparece quando a aprovação salva retém informações que o desenvolvedor considerava temporárias.

Pense em uma verificação de banco de dados de staging como cenário ilustrativo. O desenvolvedor precisa que o assistente investigue uma conexão com falha e aprova um comando contendo informações de autenticação. Concluir essa verificação não exige que a credencial se torne um artefato duradouro do projeto.

Ainda assim, um registro de aprovação pode preservar precisamente as informações de que a operação precisava. Seu propósito parece administrativo, o que torna fácil separá-lo mentalmente de senhas e tokens de acesso. Essa separação se torna perigosa quando revisores presumem que a configuração contém preferências, e não dados operacionais sensíveis.

O repositório público acrescenta outro limite. Informações antes disponíveis na máquina de um desenvolvedor passam a estar disponíveis para qualquer pessoa que possa ler o projeto. Portanto, o recurso de aprovação e o fluxo de publicação exigem escrutínio separado.

Seria exagerar as evidências dizer que selecionar a opção envia senhas automaticamente ao GitHub. A sequência relatada envolve persistência local seguida de publicação por meio do controle de versão, o sistema que registra e compartilha alterações do projeto. Cada etapa cria uma oportunidade de prevenção.

Também seria minimizar o problema descrevê-lo apenas como um commit descuidado. O comportamento do produto determina qual material sensível existe para alguém fazer commit. Um fluxo de publicação mais seguro ajuda, mas evitar cópias desnecessárias de credenciais aborda uma parte anterior do problema.

A mudança relevante está no que as equipes precisam considerar durante a revisão. As configurações de agentes merecem atenção ao lado do código da aplicação e da configuração de implantação. Um arquivo pode influenciar a segurança pelas informações que preserva, mesmo quando não contém nenhum programa executável.

Isso amplia o significado de uma alteração sensível. Revisores precisam considerar o que um arquivo revela, além do que ele faz a aplicação executar. Registros de permissões estão diretamente nessa interseção.

Um Arquivo de Configurações Local É uma Promessa com Condições

A documentação de configurações locais da Anthropic afirma que aprovações persistentes de Bash se tornam regras de permissão em .claude/settings.local.json. Bash é um interpretador de comandos usado para executar programas. O Claude Code adiciona uma exclusão à configuração global de Git ignore do desenvolvedor quando grava o arquivo pela primeira vez sob as condições documentadas.

A documentação identifica separadamente .claude/settings.json como configuração compartilhada do projeto que as equipes podem incluir em commits. Arquivos locais criados manualmente exigem sua própria exclusão. Essas distinções deixam claro o limite pretendido, mas também atribuem importância à forma como o arquivo foi criado.

Chamar um arquivo de local não impõe, por si só, privacidade. Seu nome comunica uma intenção às pessoas, enquanto os controles do repositório determinam se ele acompanha o projeto. São proteções relacionadas, com condições de falha diferentes.

Uma exclusão global pertence ao ambiente de um desenvolvedor. Uma exclusão no nível do projeto pertence ao fluxo de trabalho do repositório. Essa diferença importa sempre que equipes esperam que uma convenção de segurança sobreviva a mudanças de máquinas, colaboradores ou ambientes de desenvolvimento.

Considere uma transferência de projeto como exemplo analítico. O autor original sabe quais arquivos contêm estado pessoal e quais pertencem ao controle de versão. Um novo colaborador vê a estrutura de diretórios sem necessariamente herdar esse entendimento.

O problema se torna organizacional quando cada colaborador precisa reconstruir a mesma distinção. Uma regra que depende de conhecimento pessoal exige atenção repetida. Uma regra representada em uma política compartilhada do projeto é mais fácil de inspecionar e discutir.

Nenhuma das abordagens elimina a necessidade de revisar o que entra em um commit. Uma exclusão é uma convenção preventiva, enquanto a alteração submetida a commit é a decisão efetiva de publicação. As equipes devem avaliar ambas, em vez de presumir que a presença de qualquer uma garante a outra.

A terminologia também merece atenção. Configurações normalmente sugerem preferências inofensivas, como opções de exibição ou comportamento do editor. Um arquivo de permissões pode carregar um registro muito mais sensível porque seu conteúdo tem origem em operações reais.

Essa incompatibilidade pressiona o design do produto. Se o software preserva argumentos de comandos, deve ajudar os usuários a entender essa persistência antes que tratem o arquivo como uma configuração comum. O aviso relevante deve ficar próximo da decisão que cria o registro.

Há uma restrição legítima de usabilidade aqui. Exigir que os usuários inspecionem cada detalhe de implementação tornaria o assistente mais difícil de usar e incentivaria aprovações superficiais. O desafio de design é apresentar a consequência importante sem sobrecarregar a própria operação.

Para compradores empresariais, isso se torna uma questão concreta de avaliação. Os administradores conseguem explicar quais arquivos de agentes são seguros para compartilhar, quais permanecem pessoais e quais podem conter dados sensíveis? As respostas de um produto devem estar alinhadas aos controles de repositório que os funcionários realmente usam.

A explicação das permissões do Claude Code por meio da documentação fornece o modelo pretendido. O teste prático é se esse modelo permanece compreensível durante a colaboração cotidiana. A documentação estabelece expectativas; o comportamento observável determina se as equipes conseguem segui-las de forma confiável.

O Atalho Troca Solicitações Repetidas por Dados Persistentes

A conveniência das aprovações persistentes é fácil de entender. Desenvolvedores querem que um assistente continue o trabalho rotineiro sem interromper cada etapa. Um sistema que solicita repetidamente a mesma decisão incentiva os usuários a buscar uma autorização mais ampla ou duradoura.

A principal troca está entre menos interrupções e as informações retidas para torná-las possíveis. A permissão de execução e o armazenamento de credenciais merecem decisões separadas, mesmo quando a interface as apresenta juntas.

Uma forma útil de avaliar o design é separar capacidade de dados. Capacidade descreve o que o agente pode fazer, como executar uma operação de desenvolvimento aprovada. Dados incluem os argumentos específicos e o material de autenticação fornecido durante uma execução.

Preservar a capacidade não exige necessariamente preservar todos os dados. No entanto, remover argumentos pode alterar o significado de uma regra. Uma aprovação mais ampla pode autorizar operações que o usuário nunca pretendeu permitir, criando um problema de segurança diferente.

É por isso que simplesmente excluir texto suspeito de comandos salvos é uma especificação de design incompleta. O produto deve preservar o escopo pretendido pelo usuário, evitando ao mesmo tempo retenção desnecessária. O comportamento resultante também precisa continuar compreensível quando uma operação solicitar permissão novamente mais tarde.

Referências a credenciais oferecem outra direção de design. Um comando pode se referir a um valor fornecido separadamente, em vez de incorporar o valor diretamente. Isso reduz a necessidade de um registro de aprovação conter a própria credencial.

As referências ainda exigem cuidado. Um programa pode imprimir um valor resolvido, uma mensagem de erro pode revelá-lo, ou outro artefato pode preservar a saída. Evitar uma senha literal em um registro reduz a exposição sem estabelecer proteção completa.

É aqui que a história se torna relevante além de um botão específico. O software de agentes produz registros para apoiar continuidade, depuração e colaboração. Cada registro deve ter uma finalidade, um público e uma política de retenção definidos, proporcionais ao seu conteúdo.

A aparente memória do assistente pode obscurecer essas questões. Os usuários vivenciam uma conversa que dá continuidade ao trabalho, enquanto a implementação pode criar arquivos com regras de compartilhamento diferentes. As equipes de produto precisam tornar visíveis os limites consequentes.

A documentação de segurança do agente em segundo plano do Cursor fornece uma comparação útil. Ela descreve máquinas virtuais isoladas, acesso à internet e execução automática de terminal. Também alerta que instruções maliciosas podem levar ao roubo de dados por meio de injeção de prompt, em que conteúdo não confiável redireciona o comportamento de um agente.

Essa comparação não estabelece que o Cursor compartilha o comportamento de armazenamento de aprovações relatado para o Claude Code. Ela mostra que designs concorrentes distribuem a responsabilidade de forma diferente entre execução, isolamento e revisão do usuário. Os compradores devem comparar esses mecanismos separadamente, em vez de selecionar um produto apenas pelo seu modo de aprovação.

O isolamento restringe o ambiente em que uma operação é executada. A aprovação decide se uma operação prossegue. O tratamento de credenciais determina quais dados sensíveis entram no ambiente e quais registros permanecem depois.

Esses controles se reforçam quando seus limites são explícitos. Eles se tornam confusos quando uma decisão bem-sucedida em uma camada é tratada como evidência de que todas as outras camadas são seguras. Uma operação autorizada ainda pode deixar um registro inadequado.

Os riscos de segurança do Claude Code, portanto, merecem avaliação no nível do fluxo de trabalho. A questão útil é quais informações uma tarefa aprovada cria, onde essas informações persistem e quem pode recuperá-las mais tarde.

A Anthropic Reconhece a Lacuna, mas o Modo Automático Não É um Certificado de Correção

Boris Cherny, da equipe do Claude Code, abordou o relato na discussão sobre segurança de permissões. Ele disse que o Claude Code historicamente não contava com limpeza de segredos e recomendou o modo automático e a varredura de segredos no repositório. Também descreveu possíveis salvaguardas para prototipagem, incluindo detecção básica de segredos.

Um leitor questionou se o modo automático ainda poderia chegar ao caminho de aprovação problemático. Cherny reconheceu essa observação. Seus comentários estabelecem uma resposta ativa, mas não demonstram que uma correção abrangente já foi lançada.

Uma salvaguarda proposta precisa ser verificada em relação à falha que deve evitar. Reduzir aprovações manuais e impedir a persistência de credenciais são objetivos relacionados, com critérios de aceitação diferentes. A evidência de um não deve substituir a evidência sobre o outro.

A visão cética é direta. Se uma operação sensível ainda cria um registro de aprovação contendo uma credencial, mudar o modo de execução padrão mantém esse caminho relevante. Uma resposta precisa abordar o artefato resultante, bem como a frequência dos prompts.

Há também um argumento razoável por trás da ênfase da Anthropic em menos interrupções de permissão. Prompts repetidos podem consumir atenção sem gerar uma revisão cuidadosa. Melhorar essa experiência vale a pena, desde que a melhoria não se transforme em uma alegação geral de segurança.

A discordância diz respeito, em parte, a onde a aplicação de regras deve estar. Alguns usuários querem restrições fixas que se mantenham independentemente da interpretação de um agente. Outros preferem uma avaliação automática que possa distinguir atividades rotineiras de operações sensíveis.

Essas abordagens respondem a uma pergunta diferente daquela sobre se os registros salvos contêm senhas. Um limite rígido de execução pode coexistir com retenção excessiva de dados. Um revisor automático pode reduzir interrupções e ainda precisar de regras explícitas sobre o que é gravado no disco.

A avaliação empresarial deve manter essas questões separadas. Um comprador pode valorizar a execução automática de tarefas e ainda exigir um comportamento de armazenamento previsível. O produto deve demonstrar ambos com resultados observáveis, em vez de pedir aos clientes que deduzam um a partir do outro.

Um exercício de verificação confiável usaria credenciais artificiais em um projeto controlado. Ele inspecionaria o registro de aprovação e outros artefatos resultantes após a operação. Também examinaria o comportamento quando um arquivo local sensível já estiver sendo rastreado.

Essas são condições de avaliação propostas, e não alegações sobre testes concluídos pela Anthropic. Elas descrevem a evidência necessária para distinguir uma resposta promissora de uma melhoria comprovada. Resultados publicados permitiriam que os clientes julgassem o alcance de qualquer mudança.

Os vazamentos de segredos do Claude Code também expõem um desafio de comunicação. Aconselhar os usuários a ativarem outro controle é útil, mas deixa em aberto qual responsabilidade o próprio produto assumirá. Notas de lançamento claras devem explicar tanto a nova proteção quanto as condições restantes.

A conclusão mais justa é limitada e prática. A Anthropic reconhece a preocupação, usuários levantaram casos extremos relevantes, e a eficácia das mudanças propostas exige observação. Nem a minimização do problema nem uma declaração de remediação completa se encaixam nas evidências disponíveis.

As equipes de segurança herdam um tipo diferente de revisão de repositório

Para as equipes de segurança, a pressão imediata está relacionada à visibilidade. Revisões de aplicações frequentemente se concentram no código executado em produção. Configurações geradas por agentes podem criar exposição antes que a própria aplicação mude de comportamento.

A revisão precisa acompanhar informações sensíveis por todo o fluxo de desenvolvimento. Um arquivo de configuração merece escrutínio com base em seu conteúdo e destino. Sua finalidade administrativa não torna inofensivas as informações que contém.

A proteção contra envio do GitHub bloqueia detecções de segredos compatíveis antes da publicação. Sua documentação distingue padrões específicos de provedores, genéricos, personalizados e detectados por IA, com requisitos de configuração variáveis. Portanto, as equipes precisam verificar a cobertura que habilitaram, em vez de presumir que toda credencial será detectada.

A presença de um scanner e a cobertura demonstrada por um scanner são formas diferentes de evidência. Um token reconhecível de serviço e uma senha comum incorporada a um comando apresentam desafios de detecção diferentes. Testes com exemplos artificiais podem revelar se o sistema configurado reconhece os padrões que a equipe realmente utiliza.

Isso muda a conversa entre desenvolvedores e profissionais de segurança. O desenvolvedor precisa de um fluxo de trabalho que continue funcionando. A equipe de segurança precisa de evidências de que valores sensíveis não entram silenciosamente em material destinado ao compartilhamento.

O objetivo compartilhado deve ser um limite repetível. O estado pessoal do agente deve ter um destino explícito, a configuração compartilhada deve ter um padrão claro de revisão, e credenciais detectadas devem chegar a alguém capaz de revogá-las.

Uma resposta a incidentes também deve separar contenção de limpeza. As orientações do GitHub sobre remoção de dados sensíveis priorizam revogar ou rotacionar credenciais expostas. Elas explicam que a remoção histórica exige coordenação e que cópias podem permanecer em clones, forks e outras referências.

Essa ordem reflete a diferença entre uma credencial e o documento que a contém. Editar um documento altera o que os leitores veem naquele local. A revogação altera se a credencial continua autorizando o acesso.

Para uma equipe sob pressão, uma limpeza visível pode parecer a conclusão porque o arquivo infrator desaparece da visualização mais recente. O resultado de segurança relevante é se o valor exposto mantém autoridade. A limpeza histórica e a revisão de acesso tratam de consequências adicionais.

A responsabilidade se torna mais difícil quando a pessoa que descobre o registro não consegue identificar seu proprietário. Um desenvolvedor pode reconhecer o nome de um projeto sem saber qual sistema emitiu um token. Uma propriedade clara encurta o caminho entre a detecção e a contenção eficaz.

As equipes também precisam de uma forma de preservar a lição sem preservar o segredo. Uma nota de incidente pode descrever o fluxo de trabalho afetado, o serviço responsável e a mudança preventiva. Ela deve evitar copiar valores sensíveis apenas para tornar a explicação concreta.

Essa distinção também se aplica a uma base de conhecimento pesquisável. Conhecimento de engenharia útil inclui procedimentos aprovados e explicações sobre falhas passadas. As credenciais pertencem a sistemas projetados para gerenciar acesso, e não a material geral de referência.

Os riscos de segurança do Claude Code são mais fáceis de governar quando a resposta tem responsáveis nomeados. Desenvolvedores podem explicar a tarefa, equipes de plataforma podem aplicar convenções de repositório, e proprietários de serviços podem substituir credenciais de acesso. Profissionais de segurança não deveriam ter de reconstruir todas essas relações durante uma investigação.

A mudança organizacional prática é um perímetro de revisão mais amplo. As equipes precisam inspecionar o que o assistente deixa para trás juntamente com o que ele edita. Isso torna o estado persistente do agente parte da governança normal de engenharia.

O que demonstraria que o caminho de exposição está sendo fechado?

As próximas evidências úteis devem aparecer no comportamento do produto, nos controles do repositório e nos resultados de remediação. Esses sinais tratam de partes diferentes da sequência relatada. Juntos, podem mostrar se o caminho original de exposição se torna mais difícil de reproduzir.

O progresso deve ser medido pela persistência evitada e pela redução da autoridade das credenciais. A linguagem de anúncio, por si só, não pode estabelecer nenhum dos dois resultados. A evidência mais forte conectará uma salvaguarda específica a uma mudança observável.

Primeiro, observe um lançamento documentado do Claude Code que altere a forma como aprovações sensíveis são armazenadas. O detalhe decisivo é o que acontece quando um comando legítimo contém material de autenticação. Um lançamento deve explicar o registro resultante e as circunstâncias que ainda exigem intervenção do usuário.

A evidência de que segredos sintéticos não aparecem mais em aprovações salvas fortaleceria o argumento de uma melhoria significativa do produto. A evidência de que os mesmos valores permanecem em um caminho alternativo de permissão limitaria essa conclusão. Ambos os resultados são mais informativos do que uma declaração geral sobre automação mais segura.

O escopo dos testes importa tanto quanto o comportamento principal. Um projeto novo e um repositório com um arquivo de configurações existente rastreado representam condições iniciais diferentes. Uma explicação clara deve identificar quais condições a proteção cobre.

Segundo, observe controles de repositório que demonstrem cobertura da configuração do agente e de credenciais incorporadas em comandos. Isso inclui políticas claras de exclusão e detecção de segredos testada. O resultado significativo é se uma tentativa de publicação é interrompida ou encaminhada para uma revisão eficaz.

Um documento de política, sozinho, deixa a execução incerta. Um exercício controlado que mostre que credenciais artificiais disparam a resposta esperada fornece evidências mais fortes. Falhas repetidas enfraqueceriam a confiança na varredura como controle compensatório.

Esse sinal também importa para concorrentes. Fornecedores podem descrever ambientes de execução de maneiras diferentes e ainda precisar explicar seus artefatos retidos. Documentação clara sobre arquivos gerados, limites de compartilhamento e tratamento de credenciais tornaria as comparações mais úteis para compradores.

Terceiro, observe relatórios de remediação que distingam arquivos removidos de credenciais invalidadas. A aparência do repositório é fácil de observar, enquanto o acesso continuado exige informações do serviço responsável. Um acompanhamento confiável deve manter esses resultados separados.

Os resultados da Apiiro não foram reproduzidos de forma independente aqui, e sua coleta não deve ser tratada como uma amostra aleatória de todos os projetos Claude Code. A população relatada consiste em arquivos publicamente detectáveis. Isso limita as conclusões sobre a prevalência da exposição na base mais ampla de usuários.

Esses limites não eliminam a preocupação central de engenharia. Um recurso que preserva contexto operacional precisa de uma política clara para dados sensíveis. Os usuários devem poder compreender essa política sem reconstruir a implementação durante um prazo apertado.

Para equipes que avaliam vazamentos de segredos do Claude Code, comecem pelo registro de aprovação que seu fluxo de trabalho realmente cria. Usem credenciais sintéticas para examinar o que persiste e, em seguida, verifiquem quais controles impedem que esse material chegue a um repositório compartilhado. Atribuam responsabilidades antes que uma exposição real imponha a questão. Preservem as descobertas como procedimentos que colegas possam seguir sem reproduzir valores sensíveis. Quando credenciais genuínas aparecerem em material compartilhado, façam de sua autoridade restante a primeira pergunta para o proprietário do serviço responsável. Peçam aos fornecedores evidências que abordem armazenamento e execução. A próxima revisão mais útil é aquela que responde a uma pergunta concreta: após o término de uma tarefa aprovada, que informações sensíveis permanecem e quem pode acessá-las?