GitHub now blocks Anthropic keys at push time

If your coding agent has ever committed an Anthropic API key, GitHub will now stop the push before it leaves your machine. And it may come looking for the ones that already got through.

In its October 13 changelog, GitHub announced that push protection now covers two Anthropic key patterns by default: anthropic_service_api_key and anthropic_user_api_key. Any commit containing either pattern is automatically blocked, as long as the repository has secret scanning enabled. That includes free public repositories, where scanning runs automatically at no charge.

Push protection is the bouncer at the door: it checks the commit before it is pushed and refuses it when a detected secret is present. The part people miss is what happens behind the door. GitHub's secret scanning does not only check incoming commits. It scans git history across all branches, and it periodically rescans repositories when new secret types are added. A new detector can flag a matching secret sitting in history from months ago. The protection is forward-looking for pushes and backward-looking for everything else.

That is the actual homework. You do not need to enable anything; the patterns are on by default where scanning applies. But if an Anthropic key was ever committed to a repository you own, assume it is now discoverable there. Rotate it. The same logic applies to anywhere else secrets hide: GitHub lists issue descriptions and comments, pull request titles and comments, Discussions, wikis, and secret gists among the places scanning checks.

Two scope notes. First, private repositories do not all get this for free. Organization-owned private or internal repos need GitHub Secret Protection on a Team or Enterprise Cloud plan; user-owned repos need Enterprise Cloud with managed users or Enterprise Server with Secret Protection. Public repos are the fully covered case. Second, the same changelog added two more patterns: Salesforce's Marketing Cloud OAuth2 token and the Cloudsmith API key, with Salesforce named as a secret-scanning partner. If you commit those, the same rules apply.

Agents commit constantly, and they commit at machine speed. A leaked key in an agent's push is not a hypothetical; it is the normal failure mode of giving a fast writer access to your repository. GitHub just made the default safer. The keys already in your history are still your problem.

What remains unknown: whether GitHub validates these patterns against live keys or matches on format alone, which affects how noisy the new detections will be. That detail was not in the changelog summary.

Related: context injection in the Copilot CLI shows the other side of agent security at GitHub, and the Claude Code campaign is what compromised agent tooling looks like in the wild.