How to Block Anthropic API Keys With GitHub Secret Scanning

GitHub now rejects pushes that contain Anthropic keys, and a few commands prove it is switched on for your repos. By the end you will have checked GitHub secret scanning for Anthropic keys, seen what a blocked push does, reviewed alerts from the terminal, and have a plan for the day a key slips through.

On October 13, GitHub added detectors for anthropic_service_api_key and anthropic_user_api_key. Per the GitHub changelog, both are push-protected by default wherever secret scanning is enabled, free public repositories included. Push protection is the part that refuses the push before the key lands in the repo.

1. Check that GitHub secret scanning is on for Anthropic keys

The changelog promises a block wherever secret scanning is on. The push protection docs describe two layers: user-level protection, on by default on GitHub.com for public repositories, and repository-level protection, off by default and tied to GitHub Secret Protection. A leaked key costs real money, so read the setting back instead of trusting a default.

gh api repos/<owner>/<repo> \
  --jq '.security_and_analysis | {secret_scanning, secret_scanning_push_protection}'

Reading this block needs admin rights on the repo. Both fields should say enabled; if not, flip them:

gh api -X PATCH repos/<owner>/<repo> --input - <<'EOF'
{
  "security_and_analysis": {
    "secret_scanning": { "status": "enabled" },
    "secret_scanning_push_protection": { "status": "enabled" }
  }
}
EOF

Public repos get secret scanning free. Private and internal org repos need GitHub Secret Protection on Team or Enterprise Cloud, per About secret scanning.

Turn it on for the whole organization

Create a code security configuration, then attach it. Omitted fields default to disabled, so set both.

gh auth refresh -s write:org

gh api -X POST orgs/<your-org>/code-security/configurations \
  -f name='secret-scanning-baseline' \
  -f description='Secret scanning and push protection on' \
  -f secret_scanning=enabled \
  -f secret_scanning_push_protection=enabled \
  --jq .id

gh api -X POST orgs/<your-org>/code-security/configurations/<configuration_id>/attach \
  -f scope=all_without_configurations

The first call prints the configuration ID. all_without_configurations skips repos that already have a configuration. You need org admin or security manager rights, plus the write:org scope on a classic token (REST docs).

2. See what a blocked push looks like

Don't test with a real key. I found no documented test token for these detectors, and a made-up string in the wrong format matches nothing, so a clean test push proves little. Trust step 1 and learn the failure mode instead.

A blocked push ends in a GH013 error listing where the secret lives. This sample is abridged, with placeholders, and the exact wording varies:

remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: - Push cannot contain secrets
remote:   locations:
remote:     - commit: <short-sha>
remote:       path: <file>:<line>

The developer must remove the key and push again. Per the command line docs, amend if it is in the latest commit, or rebase from the earliest commit listed:

# key is in the latest commit: delete it from the file, then
git commit --amend --all
git push

# key is in an earlier commit: use the earliest SHA from the error
git rebase -i <earliest-sha>~1   # change "pick" to "edit" for that commit
# delete the key from the file, then
git add .
git commit --amend
git rebase --continue
git push

By default anyone with write access can bypass the block by giving a reason: used in tests, false positive, or fix later. Every bypass is audit-logged. For an Anthropic key, don't bypass; revoke.

3. Review Anthropic key alerts with the gh CLI

List open alerts for these two types with the secret value hidden:

gh api 'repos/<owner>/<repo>/secret-scanning/alerts?state=open&secret_type=anthropic_service_api_key,anthropic_user_api_key&hide_secret=true' \
  --jq '.[] | {number, secret_type, state, push_protection_bypassed, html_url}'

hide_secret defaults to false, so the raw key can land in your terminal or CI logs. Always set it to true. For the whole org, use orgs/<your-org>/secret-scanning/alerts. You need the repo or security_events scope (alerts API).

4. Revoke a leaked Anthropic key and close the alert

Revoke first, tidy later.

1. Delete the key. In the Claude Console, open API keys, use the three-dot menu and choose Delete API Key, as Anthropic's guidance describes.
2. Don't wait for the partner program. For public repos GitHub forwards the key to Anthropic, which deactivates it and emails the owner. Private repo hits only raise an alert for you.
3. Replace it through your secrets manager and check usage for anything unfamiliar.
4. Close the alert as revoked:

gh api -X PATCH repos/<owner>/<repo>/secret-scanning/alerts/<alert_number> \
  -f state=resolved \
  -f resolution=revoked \
  -f resolution_comment='Deleted in Claude Console, replaced in secrets manager'

Comments can't be edited once set. Scrubbing history is optional after revocation; GitHub's advice is to rotate first.

Gotchas

• No validity check. The supported patterns table shows validity checks for anthropic_api_key and anthropic_admin_api_key, not for service or user keys, so an alert can't say whether the key is live. Assume it is.
• Cloudsmith is detected, not blocked. cloudsmith_api_key shipped alongside, but the changelog lists push protection only for the Anthropic types.
• Salesforce is a new partner. Marketing Cloud OAuth2 tokens (salesforce_marketing_cloud_api_oauth2_token) in public repos are forwarded to Salesforce.
• Old keys may surface. Secret scanning reads the full history of all branches, so repos where it was off can raise old alerts.

For anyone running AI in production, a key stopped at git push is an incident that never has to be opened.