GitHub Starts Blocking Committed Anthropic Keys by Default

GitHub's secret scanning now detects Anthropic API keys, and both new detectors are in push protection by default. A push that contains one is refused before the commit reaches the repository, in any repository with secret scanning enabled, including free public repositories. The changelog entry is dated 13 October 2026.

The push fails rather than the alert arriving later

Secret scanning does two different jobs. Detection raises an alert after a secret is already in the repository, which leaves you with a credential to rotate and a history to clean. Push protection stops the commit at the point where you try to send it. The two Anthropic detectors, anthropic_service_api_key and anthropic_user_api_key, are in the second category, so there is nothing to triage afterwards because the key never lands.

Because the change is to the default, there is nothing to switch on. A repository that already has secret scanning and push protection enabled picks up the two new detectors without a settings change, and so does a public repository on a free account. The block arrives with the platform, which is convenient and also means it will show up in the middle of someone's afternoon rather than during a planned hardening sprint.

Only two of the three new detectors block anything

It is easy to read this entry as "GitHub now blocks leaked credentials from three more providers". It does not. Anthropic's two key types are in push protection defaults. Cloudsmith's cloudsmith_api_key is detected and produces an alert. Salesforce's token type is a partner secret, which means a public repository finding is reported to Salesforce for revocation. Three providers, three levels of intervention, and the level decides what happens to a developer at the moment of a push: nothing, an alert afterwards, or a refused push.

That distinction is worth carrying into planning. Push protection is not a general safety net for credentials. It covers the detector types GitHub has added to it, and the list grows in entries like this one rather than all at once.

GitHub's documentation draws the general line between the two mechanisms: partner secrets are reported to the issuer when they appear in public repositories, while user secrets raise alerts in public or private repositories. Blocking is a separate setting, and it is the one that changed here.

What a developer has to do differently

If an Anthropic key sits in a tracked file, even a file you plan to clean up in the next commit, the push fails. Deleting the line in a follow-up commit does not fix it, because the secret is already in the history you sent. The change has to happen before the commit lands: keep the key in a file that is ignored, inject it from the environment, and if the string has already been pushed to a public repository, rotate the key rather than trusting a history rewrite to have reached every fork. A blocked push costs a few minutes. A key that spent a week in a public fork costs a rotation and an incident note.

If the detector fires on a string that is not a live credential, GitHub's documentation covers the bypass route, so a false positive does not force you to rewrite history.

The workflow that trips this most often is the local one. Keys generated by a setup script, a notebook, or a coding agent land in a file that is one git add . away from being committed. A pre-commit hook or a local scan catches the same string before the push and gives the developer a chance to fix the file rather than rewrite the commit. The server-side block is the last line, not the first one.

Where keys leak from in practice

The usual sources are .env files added to the repository before the ignore rule existed, agent and editor configuration directories, notebook checkpoints, and documentation examples where a real key was pasted in place of a placeholder. The detection is about the key itself rather than the filename it sits in, so moving the file does not help.

Two of those sources have become more common as coding agents write configuration. An agent asked to wire up a provider will write a key into whatever file it thinks the tool reads, and the file it picks may be inside the working tree. The developer sees a working tool and not a credential in version control, because the write succeeded either way. That is the moment this detector is designed to interrupt.

What to check this week

• Confirm secret scanning is enabled on the repositories where a key could plausibly end up. The changelog says the block covers repositories with secret scanning on, including free public repositories, so a private repository without that feature will not stop anything.
• Look through the history for keys that are already committed:

git log --all -p -S ANTHROPIC_API_KEY -- . | head -50

Anything that search turns up has to be rotated, whether or not the push that carried it was blocked at the time. Rotating a key is cheap. Discovering later that it was valid in a public repository is not.

The longer answer is to reduce how much a leaked key is worth. Keys that expire in hours rather than months turn a bad commit into an inconvenience, and they are the reason the blocking default matters less for teams that already issue short-lived credentials. If your keys are long lived, the same reasoning applies in the other direction: the cost of a mistake is set by how long the credential stays valid, not by how quickly GitHub notices it.