A platform team reading that GitHub now blocks Anthropic keys “by default” faces a consequential question: does that include its private repositories? GitHub’s October 13 announcement adds credential detection, but the operational answer depends on repository visibility, product eligibility, and whether the relevant protection is enabled.
Two named Anthropic patterns reach the push boundary
In its October 13 changelog, GitHub names anthropic_service_api_key and anthropic_user_api_key as new detectors. GitHub says both are included in push protection by default for repositories with secret scanning enabled, including free public repositories.
The same update adds a Cloudsmith API key detector and identifies Salesforce as a new secret-scanning partner. Those additions provide context, but the immediate Anthropic question is narrower: adding a supported pattern does not establish that every repository has blocking switched on.
“Default” changes with repository visibility
GitHub’s supported-pattern documentation says public repositories receive automatic, free secret scanning. Organization-owned private and internal repositories require GitHub Secret Protection enabled on GitHub Team or GitHub Enterprise Cloud.
There is also a separate enablement distinction. The push-protection documentation says repository-level protection requires Secret Protection and is disabled by default. Designated administrative or security roles can enable it. User-level push protection, meanwhile, is enabled by default on GitHub.com and blocks pushes to public repositories.
Read together, these sources support a conditional interpretation of the announcement. The new detector’s default inclusion describes pattern coverage; it does not demonstrate universal private-repository enforcement. A team therefore needs to distinguish access to the feature from the state of its repository control.
A block can catch more than a command-line push
GitHub documents checks across command-line pushes, UI commits, file uploads, REST API requests, and GitHub MCP interactions in public repositories. The preventive boundary consequently extends beyond a developer’s terminal, according to its control documentation.
Repository-level protection also permits users with write access to bypass a block by supplying a reason. GitHub says bypasses generate alerts and audit-log events. For operators, that makes exception handling a practical part of enforcement: the control can interrupt a push while still allowing a documented decision to proceed.
Historical scanning helps, but pattern scope still matters
GitHub’s secret-scanning documentation describes scanning Git history across branches and periodically rescanning repositories when new secret types are added. It also lists issue and pull request text, Discussions, wikis, and secret gists as scanning surfaces. Detected credential leaks produce repository alerts, and GitHub advises rotation.
The reviewed material gives no specific completion time for rescanning. Nor does the announcement establish coverage of every Anthropic credential format. GitHub’s pattern reference limits push protection to recent token versions it can identify confidently and notes that provider formats can change.
The default can stop a push only where protection is in scope
Private-repository coverage still depends on the plan and switch
An editorial verification sequence follows from those distinctions: map intended repositories by visibility, confirm eligible plans and Secret Protection status for organization-owned private repositories, check repository-level push protection, and establish who reviews bypasses and alerts.
These are recommended checks, not findings about any organization. The supplied sources do not reveal actual repository settings, detection accuracy, false-positive rates, or rollout completeness. The useful takeaway is conditional: two more supported patterns strengthen the documented control where its prerequisites and settings put it into operation.