GitHub Now Blocks Anthropic Key Pushes by Default, But Private Repos Remain Uncovered

When your coding agent finishes a task, stages all changes with git add -A, and pushes, there might be a .env file with an Anthropic API key tucked into the commit. GitHub's secret scanning can now recognize more of these keys and block them right at the push stage.

According to GitHub's official changelog, secret scanning has added two new Anthropic key detection types: anthropic_user_api_key and anthropic_service_api_key, and push protection blocks both of these key types by default. In repositories with secret scanning enabled, commits containing these keys are automatically blocked, including free public repositories.

This is a genuine improvement. But it's narrower than it sounds—private repositories under default settings still won't trigger a block.

What exactly changed in this update

The same changelog bundles three things together:

• Two new Anthropic detectors, anthropic_user_api_key and anthropic_service_api_key, plus a Cloudsmith API key detector.
• Salesforce joined as a secret scanning partner to detect Marketing Cloud OAuth2 tokens. Partner keys found in public repositories are sent to the issuer, who revokes or rotates them.
• Both new Anthropic key types were added to the default push protection blocklist.

The entry also states that as long as secret scanning is enabled, both public and private repositories will receive the corresponding alerts.

Anthropic isn't new to this program. GitHub announced Anthropic as a secret scanning partner back in August 2024, and its supported key patterns table also lists anthropic_api_key, anthropic_admin_api_key, and anthropic_session_id. When keys do land in public repositories, Anthropic's key security documentation states: "Anthropic automatically disables exposed API keys" and emails the affected users.

Why these two key types

The naming of these two detectors matches how Anthropic now creates keys. Its API key documentation requires you to choose a type at creation: personal keys "run as you and stop working if you leave the organization," while service account keys are designed for "workloads such as CI pipelines, production services, or agents." The documentation sums it up in one line: "Use personal keys for your own development, and service account keys for anything shared."

The older workspace key is described as a "legacy key with no owner" that continues to work even after its creator leaves.

GitHub's patterns table calls the two detectors "Anthropic User API Key" and "Anthropic Service Account API Key." Mapping "user" to what Anthropic calls a personal key is the original author's inference—neither party has stated this explicitly.

This distinction matters especially for agents: agents usually perform tasks on behalf of a shared role, and using a service account key allows independent revocation without affecting personal keys.

Workspace keys were a key form in Anthropic's early console, used before the personal-versus-service-account dichotomy launched. What makes them unusual is that they weren't bound to a specific member account: the key remains valid after its creator leaves, and there's no clear owner. This means that once a key is exposed, it's hard to assign responsibility for who should rotate it, and permission governance is also fuzzier. Anthropic classifies it as a legacy type and pushes users to migrate to the new personal/service account model, essentially turning "ownerless keys" into "owned keys" so that revocation and auditing have clear responsibility boundaries.

What blocking actually does, and who can let it through

According to GitHub's push protection documentation, it covers these scenarios: command-line pushes, commits created in the GitHub UI, file uploads, REST API requests, and GitHub MCP server interactions for public repositories only. That last point is worth noting—if your agent writes to GitHub through the GitHub MCP server rather than git, that path is also subject to the protection scope.

Blocking isn't an iron wall. The documentation states that by default, "anyone with write access to a repository can bypass push protection by specifying a bypass reason." Once repository-level push protection is enabled, the reason you choose determines the alert's fate:

• "Used in tests"—the alert closes as "used in tests."
• "False positive"—closes as "false positive."
• "Fix later"—the alert stays open.

In this mode, every bypass is written to the audit log and emails owners, security managers, and repository administrators watching the repository. But with only the user-facing default push protection, the documentation says it "does not generate an alert when you bypass push protection" unless push protection is also enabled at the repository level. In other words, on a public repository with default settings, a bypass might leave no alert for anyone to review.

Your agent typically pushes with your git credentials, so the person who can let a blocked key through is you, or anything using those credentials. In scenarios where repository-level push protection is on, read the bypass reason carefully before closing an alert from an agent branch.

One more thing: blocking means the key already exists in a local commit. Push protection only stops it from reaching GitHub; it doesn't remove it from your branch.

The key type field in the schema determines what GitHub pattern matching targets. GitHub's secret scanning relies on regexes and validation rules provided by issuers, and each detector corresponds to a specific string structure. anthropic_user_api_key and anthropic_service_account_api_key can be distinguished because Anthropic encodes type information in the key prefix or internal structure, and GitHub only needs to match them separately. This also explains why the older anthropic_api_key, anthropic_admin_api_key, and anthropic_session_id can coexist—they correspond to key formats issued for different purposes at different times in Anthropic's history.

Where it isn't covered

The push protection documentation describes two types, and the repositories they cover differ:

• User-facing push protection: "enabled by default," "blocks you from pushing secrets to public repositories on GitHub." The documentation doesn't say it covers private repositories.
• Repository-facing push protection: "requires enabling GitHub Secret Protection" and is "disabled by default." An administrator, owner, or security manager must turn it on manually.

In other words, for a private repository where no one has enabled Secret Protection and repository-level push protection, there is no blocking described in the documentation. This update only made the default list longer; it didn't turn the feature on where it was already off.

Git isn't the only place keys sit in plaintext. If you've ever typed export ANTHROPIC_API_KEY=... in a terminal, it's sitting in your shell history. The original author mentions in the article that he is developing Hermes IDE, and version 2.3.2 no longer offers terminal suggestions for commands containing API keys, tokens, or passwords, but the shell's own history file remains unchanged, and cleaning it up is still on you. Hermes is not affiliated with GitHub or Anthropic.

Shell history files (like .bash_history, .zsh_history) record every interactively executed command under default settings, including assignment statements like export ANTHROPIC_API_KEY=sk-ant-.... Unlike .env, these history files usually live in the user's home directory and aren't noticed by git status or secret scanning. Cleanup varies by shell: you can run history -c to clear the current session, manually delete matching lines from the history file, or set HISTIGNORE or HISTCONTROL=ignorespace to avoid recording sensitive commands. A more thorough approach is to write keys into the shell's rc file to be read at startup, rather than manually exporting every time.

Three things you can do this week

1. Enable repository-level push protection wherever possible. If your organization has GitHub Secret Protection, enable push protection at the organization level. According to the documentation, it stays off until someone takes action.

2. Configure separate keys for agents and CI. Anthropic's documentation recommends using service account keys for "anything shared," and agents fall into that category. Separate keys mean a leaked agent key can be revoked independently without affecting your own key; personal keys stop working when the owner leaves the organization.

3. Keep .env out of the version tree, and check what's already in it.

# Stop tracking the file but keep it on disk
echo ".env" >> .gitignore
git rm --cached .env

# Count lines resembling Anthropic keys in history
git log --all -p | grep -c 'sk-ant-'

Anthropic's documentation says every key "starts with sk-ant-," which is exactly the pattern grep is looking for. If .env was never tracked, git rm --cached will error harmlessly. The count includes placeholders and deleted lines, so review the matches before acting. If a real key appears and the branch has ever been pushed, rotate it in the Claude Console. Rotate first—rewriting history can't recall a key someone else has already copied.

Treat GitHub's blocking as a safety net beneath those three steps, not a replacement for them.

One-line Summary

GitHub secret scanning adds default push blocking for Anthropic keys, but it only covers public repositories and can be bypassed.

Paragraph Summary

GitHub secret scanning added two new detectors, anthropic_user_api_key and anthropic_service_api_key, and added them to the default push protection blocklist, covering free public repositories too. This is a genuine improvement, but its scope is limited: private repositories under default settings won't trigger a block and require an administrator to manually enable GitHub Secret Protection and repository-level push protection. Bypass mechanisms also exist—anyone with write access can specify a reason to bypass, and no alert is generated when only default push protection is in place. Anthropic recommends that agents and CI use service account keys that can be revoked independently. The article also notes that blocking only stops GitHub; keys remain in local commits and shell history, and if leaked, keys should be rotated first.