GitHub bloqueia por padrão pushes com chaves da Anthropic e adiciona Salesforce ao secret scanning

A partir de hoje, o secret scanning do GitHub detecta chaves da Anthropic, Salesforce e Cloudsmith, e os tokens da Anthropic já entram bloqueados por padrão no push protection. Veja o que isso muda em repositórios públicos e privados.

Nota da redação: este artigo descreve, na seção sobre falsos positivos, um fluxo de bypass com justificativa para commits legítimos bloqueados pelo push protection. Essa descrição não consta no changelog oficial do GitHub usado como fonte principal da matéria e não pôde ser verificada de forma independente. O restante dos fatos (data do anúncio, tipos de segredo cobertos, escopo do push protection, parceria com a Salesforce e encaminhamento automático de credenciais) está confirmado na fonte oficial.

A partir de hoje, o secret scanning do GitHub detecta chaves da Anthropic, Salesforce e Cloudsmith, e os tokens da Anthropic já entram bloqueados por padrão no push protection. Veja o que isso muda em repositórios públicos e privados.

O GitHub atualizou, em 13 de outubro de 2026, a lista de detectores do secret scanning para cobrir três novos provedores: Anthropic, Salesforce e Cloudsmith. A mudança que importa de verdade para quem escreve backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → não é só a detecção em si, mas o fato de que os tokens da Anthropic já nascem incluídos no push protection por padrão, segundo o changelog oficial do GitHub.

Isso significa uma coisa prática: se o seu repositório tem secret scanning habilitado, incluindo repositórios públicos gratuitos, um git push contendo uma dessas chaves é barrado antes mesmo de chegar ao histórico remoto. Não é mais alerta depois do fato. É bloqueio no momento do push.

O que entrou na lista

Três provedores novos, com tipos de segredo específicos sendo reconhecidos automaticamente:

• Anthropic: anthropic_service_api_key e anthropic_user_api_key
• Cloudsmith: cloudsmith_api_key
• Salesforce: salesforce_marketing_cloud_api_oauth2_token

Dos três, só os padrões da Anthropic entram diretamente na lista de detectores cobertos pelo push protection por padrão. Os outros geram alerta de secret scanning, mas não entram na lista de detectores cobertos pelo push protection por padrão, segundo o changelog.

Secret scanning e push protection não são a mesma coisa

Vale separar os dois mecanismos, porque a confusão é comum. O secret scanning varre o conteúdo do repositório (incluindo histórico) e cria um alerta quando encontra um padrão reconhecido de segredo. Já o push protection age antes: ele intercepta o git push no momento em que o commit chega ao GitHub e recusa a operação se detectar um dos padrões cobertos.

A Salesforce agora é parceira do programa de secret scanning partnership, o que tem uma implicação extra em repositórios públicos: quando um salesforce_marketing_cloud_api_oauth2_token aparece num repo público, o GitHub encaminha automaticamente o segredo para a Salesforce revogar ou rotacionar a credencial. Esse encaminhamento automático não se aplica a chaves de usuário, que só geram alerta.

Por que isso pesa mais pra quem integra IA no backend

Chave de API da Anthropic (Claude) é hoje um segredo tão comum em serviços de backend quanto chave de banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → ou token de fila. Times que integraram agentes, pipelines de RAG↳RAG6 conteúdosTécnica RAG com a biblioteca Langchain: tutorial para aplicar agoraData · jun 2024Como avaliar LLMs, RAG e Agentes de IA: Teoria e prática.AI · abr 2026RAG Não É Memória: O Problema Real dos Agentes de IAAI · mai 2026Ver tudo em AI → ou qualquer chamada direta ao modelo da Anthropic costumam ter esse valor espalhado em .env, scripts de deploy, configuração de CI e, inevitavelmente, algum commit acidental.

Até esta mudança, um vazamento desses só virava alerta depois que o código já estava no repositório remoto, exigindo rotação manual com o relógio correndo contra quem já tivesse clonado. Com o push protection cobrindo anthropic_service_api_key e anthropic_user_api_key por padrão, o commit sequer entra no histórico remoto se o padrão for reconhecido antes.

Na prática, para um projeto Rails ou Node que chama a API da Anthropic, isso reduz um vetor de incidente clássico: dev copia a chave de produção para testar localmente, esquece de tirar do config/credentials.yml ou do .env versionado, e dá push sem revisar o diff.

O que o bloqueio automático NÃO resolve

Esse é o ponto em que vale frear o otimismo. O push protection age sobre commits novos, não sobre o que já está no histórico do repositório. Se uma chave da Anthropic já foi commitada antes de hoje, ela continua lá, exposta, até alguém reescrever o histórico ou rotacionar a credencial manualmente.

Em resumo: o recurso previne o próximo vazamento, não corrige um vazamento passado. Times que suspeitam de exposição anterior precisam auditar o histórico e rotacionar chaves ativamente, independente dessa mudança.

Outro limite importante é o escopo de cobertura por tipo de repositório:

O trade-off do bloqueio automático: falso positivo existe

Todo detector de padrão tem risco de falso positivo, e chave de API costuma ter formato previsível o suficiente para disparar mesmo em valores de teste ou fixtures de desenvolvimento. Quando o push protection bloqueia um commit legítimo, o fluxo padrão do GitHub permite que quem tem permissão registre uma justificativa e faça bypass pontual.

Isso cria uma decisão de processo para o time: permitir bypass liberal degrada o valor do controle, porque vira hábito clicar em "permitir" sem checar. Times maduros tratam todo bypass como evento auditável, revisado depois, não como obstáculo a remover.

Checklist prático para quem mantém pipeline

Antes de assumir que está protegido, vale checar:

1. Secret scanning está habilitado no repositório (ou na organização, via política padrão)?
2. Push protection está ativo, não só o scanning passivo?
3. Para repositório privado, secret scanning e push protection estão habilitados nas configurações do repositório ou da organização?
4. Chaves da Anthropic, Salesforce Marketing Cloud ou Cloudsmith já commitadas antes de hoje foram auditadas e rotacionadas?
5. O time sabe o fluxo de bypass e quem revisa essas exceções depois?

Essa lista de parceiros do secret scanning vem crescendo rápido: entradas recentes do mesmo changelog já incluíam Lovable e Supabase em outubro. A tendência é clara, cada provedor de API relevante no ecossistema de IA e SaaS tende a virar detector suportado, então vale tratar isso como processo contínuo de revisão, não como item que se resolve uma vez e esquece.

Fonte: GitHub Changelog