GitHub blocks pushes with Anthropic keys by default and adds Salesforce to secret scanning

As of today, GitHub's secret scanning detects keys from Anthropic, Salesforce, and Cloudsmith, and Anthropic tokens are now blocked by default in push protection. See what this changes in public and private repositories.

Editor's note: this article describes, in the section about false positives, a bypass flow with justification for legitimate commits blocked by push protection. This description does not appear in the official GitHub changelog used as the main source for this report and could not be independently verified. The remaining facts (announcement date, types of secrets covered, push protection scope, the Salesforce partnership, and automatic credential forwarding) are confirmed in the official source.

As of today, GitHub's secret scanning detects keys from Anthropic, Salesforce, and Cloudsmith, and Anthropic tokens are now blocked by default in push protection. See what this changes in public and private repositories.

On October 13, 2026, GitHub updated its secret scanning detector list to cover three new providers: Anthropic, Salesforce, and Cloudsmith. The change that really matters for backend developers isn't just the detection itself, but the fact that Anthropic tokens now come included in push protection by default, according to GitHub's official changelog.

This means something practical: if your repository has secret scanning enabled, including free public repositories, a git push containing one of these keys is blocked before it even reaches the remote history. It's no longer an alert after the fact. It's a block at the moment of the push.

What was added to the list

Three new providers, with specific secret types being recognized automatically:

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

Of the three, only Anthropic's patterns are directly included in the list of detectors covered by push protection by default. The others generate secret scanning alerts, but are not included in the list of detectors covered by push protection by default, according to the changelog.

Secret scanning and push protection are not the same thing

It's worth separating the two mechanisms, because the confusion is common. Secret scanning scans the repository's content (including history) and creates an alert when it finds a recognized secret pattern. Push protection, on the other hand, acts beforehand: it intercepts the git push at the moment the commit reaches GitHub and refuses the operation if it detects one of the covered patterns.

Salesforce is now a partner in the secret scanning partnership program, which has an extra implication for public repositories: when a salesforce_marketing_cloud_api_oauth2_token appears in a public repo, GitHub automatically forwards the secret to Salesforce to revoke or rotate the credential. This automatic forwarding does not apply to user keys, which only generate an alert.

Why this matters more for those integrating AI on the backend

An Anthropic (Claude) API key is now a secret as common in backend services as a database key or queue token. Teams that have integrated agents, RAG pipelines, or any direct call to Anthropic's model often have this value scattered across .env files, deployment scripts, CI configuration, and, inevitably, some accidental commit.

Until this change, a leak like this only became an alert after the code was already in the remote repository, requiring manual rotation with the clock running against anyone who had already cloned it. With push protection covering anthropic_service_api_key and anthropic_user_api_key by default, the commit doesn't even enter the remote history if the pattern is recognized beforehand.

In practice, for a Rails or Node project that calls the Anthropic API, this reduces a classic incident vector: a developer copies the production key to test locally, forgets to remove it from config/credentials.yml or a versioned .env file, and pushes without reviewing the diff.

What automatic blocking does NOT solve

This is the point where it's worth tempering optimism. Push protection acts on new commits, not on what's already in the repository's history. If an Anthropic key was already committed before today, it remains there, exposed, until someone rewrites the history or manually rotates the credential.

In short: the feature prevents the next leak, it doesn't fix a past leak. Teams that suspect previous exposure need to audit the history and actively rotate keys, regardless of this change.

Another important limit is the coverage scope by repository type:

The trade-off of automatic blocking: false positives exist

Every pattern detector carries a risk of false positives, and API keys tend to have a format predictable enough to trigger even on test values or development fixtures. When push protection blocks a legitimate commit, GitHub's standard flow allows someone with permission to record a justification and perform a one-off bypass.

This creates a process decision for the team: allowing liberal bypassing degrades the value of the control, because clicking "allow" without checking becomes a habit. Mature teams treat every bypass as an auditable event, reviewed later, not as an obstacle to be removed.

A practical checklist for whoever maintains the pipeline

Before assuming you're protected, it's worth checking:

1. Is secret scanning enabled in the repository (or in the organization, via default policy)?
2. Is push protection active, not just passive scanning?
3. For private repositories, are secret scanning and push protection enabled in the repository's or organization's settings?
4. Have Anthropic, Salesforce Marketing Cloud, or Cloudsmith keys already committed before today been audited and rotated?
5. Does the team know the bypass flow and who reviews these exceptions afterward?

This list of secret scanning partners is growing fast: recent entries in the same changelog already included Lovable and Supabase in October. The trend is clear, every relevant API provider in the AI and SaaS ecosystem tends to become a supported detector, so it's worth treating this as an ongoing review process, not as something you fix once and forget.