GitHub has added default push protection for two Anthropic API key types, automatically blocking commits containing them in repositories with secret scanning enabled, including free public repositories. The October 13, 2026 update also adds Cloudsmith API key detection and Salesforce as a secret scanning partner for Marketing Cloud API OAuth2 tokens, according to GitHub’s changelog.
For developers, the central distinction is how GitHub responds to each secret type. The announcement covers detection, alerts, partner reporting and blocking at push time. It explicitly names the two new Anthropic detectors for default push protection; teams should not infer identical blocking behavior for every credential added in the release.
Which secret types are covered?
GitHub lists the following additions across its detector and partner updates:
| Provider | Exact secret type | Announced coverage |
|---|---|---|
| Anthropic | <code>anthropic_service_api_key</code> | Detection and default push protection |
| Anthropic | <code>anthropic_user_api_key</code> | Detection and default push protection |
| Cloudsmith | <code>cloudsmith_api_key</code> | Detection |
| Salesforce | <code>salesforce_marketing_cloud_api_oauth2_token</code> | New secret scanning partner coverage |
The identifiers matter because the announcement describes specific secret types. It does not establish that every Anthropic credential format receives the same treatment, nor does it announce default push protection for the Salesforce and Cloudsmith types listed here.
What default blocking means for Anthropic keys
GitHub says both new Anthropic types are included in push protection by default. With secret scanning enabled, a commit containing either type is automatically blocked when pushed. Free public repositories are expressly included in that scope.
That makes the repository’s secret scanning status a relevant prerequisite when assessing coverage. The announcement’s default-blocking statement applies to repositories with that feature enabled; it should not be read as an unconditional guarantee for every repository.
The practical value is an intervention at the point of pushing code. An alert tells a team that a secret has been found, while a push block interrupts the attempt to send a commit containing the credential. Neither event, by itself, establishes that the credential has been revoked.
How Salesforce reporting and secret alerts differ
Salesforce’s addition concerns the secret scanning partnership program. GitHub says that when a provider’s secret is found in a public repository, it forwards the secret to the relevant partner so the provider can revoke or rotate it. The Salesforce type named in this update is the Marketing Cloud API OAuth2 token.
The public-repository condition is important: that is the scope GitHub describes for automatic partner reporting. Separately, GitHub says user secrets generate secret scanning alerts when found in public or private repositories. Partner notification and a repository alert therefore describe different responses, with different documented scopes.
Forwarding a secret also does not confirm that the provider has completed revocation or rotation. GitHub describes the opportunity for the partner to act, rather than a guaranteed remediation outcome or response time.
What a blocked push leaves to investigate
A blocked push addresses one route by which a credential could reach a remote repository. It does not establish whether copies exist elsewhere. In its analysis of the update, OpenTools recommends removing the credential from the change, using an approved secret store, rotating or revoking the credential, and reviewing earlier commits and development artifacts for other copies.
For teams using Anthropic keys, the useful operational distinction is between confirming that a push was blocked and confirming that the credential has been dealt with. The release supplies a specific preventive control for two additional key types. Credential remediation still requires a separate check.
