On October 13, 2026, GitHub extended secret scanning to two new key types: Anthropic API keys, now blocked by default under push protection, and Salesforce Marketing Cloud OAuth2 tokens, covered through a new partnership. A Cloudsmith API key detector joins the list of automatic detectors as well. For teams handling language-model API keys inside their repositories, the change alters what actually happens at the moment of a git push.
What changes at push time
Until now, an Anthropic key exposed in a public repository was typically caught after the fact, then forwarded to the partner for revocation. With this update, Anthropic service and user API keys are now part of push protection by default: a commit that contains one is blocked before it ever reaches GitHub, on any repository with secret scanning enabled, including free public repositories.
$ git push origin main
remote: error: GH013: Repository rule violations found
remote:
remote: — Push cannot contain secrets —
remote:
remote: Anthropic API Key
remote: locations:
remote: - commit: 7e4f21a
remote: path: config/settings.py:14
remote:
remote: (?) To push, remove the secret from your commit(s),
remote: or allow the push at:
remote: https://github.com/OWNER/REPO/security/secret-scanning/unblock/...
Three detectors, two different treatments
The update doesn’t treat every new partner the same way: only Anthropic keys move to default blocking, while Salesforce and Cloudsmith are, for now, covered by detection only.
| Provider | Detected secret | Push protection by default |
|---|---|---|
| Anthropic | Service API key, user API key | Yes (new) |
| Salesforce | Marketing Cloud OAuth2 token | Detection only |
| Cloudsmith | API key | Detection only |
For public repositories, a mechanism already existed before this update: GitHub has been a secret-scanning partner with Anthropic since 2024, forwarding exposed keys found in public repos so the provider can revoke them. What’s new on October 13 is the preventive block at the source, before a key ever becomes visible in public history at all.
The blind spot that remains: history already published
Push protection acts on new commits, not retroactively on Git history already pushed. An Anthropic key that has been sitting in a repository for months, even a private one, isn’t automatically neutralized by this update: it still depends on existing detection and, for GitHub Advanced Security accounts, on private-repository blocking.
As of October 13, 2026, a commit containing an Anthropic API key is blocked before it ever reaches GitHub, on any repository with secret scanning enabled.
A key already exposed in a repository’s history, even an old one, stays valid until it’s manually revoked. Blocking at push time doesn’t replace an audit of existing history or the rotation of already-committed keys, a habit similar to what’s recommended for any minimal security baseline.
Key takeaways
Extending secret scanning to Anthropic keys closes a real exposure window for teams wiring Claude API calls into their code, by blocking the leak at push time rather than after the fact. This isn’t the first extension of its kind: GitHub had already widened detection to Lovable and Supabase keys in early October, rolling out partner coverage in waves rather than in a single overhaul. The catch is that protection only covers new pushes: keys already sitting in Git history still need a manual review and rotation.
This is the kind of update I’d recommend checking on your own repositories rather than assuming it applies: default push protection only kicks in where secret scanning is active, and not every account has turned it on the same way depending on how old the repository is. A quick audit of the security configuration, on projects calling a language-model API, takes less time than an emergency key rotation on a Sunday night. — Simon Janvier
Primary source: GitHub Changelog, “Secret scanning blocks Anthropic keys by default, adds Salesforce,” October 13, 2026.
