GitHub Secret Scanning Adds AI and Marketing Key Detectors

Anthropic API keys are now on the short list of things GitHub will stop you from pushing. On 13 October 2026, GitHub added new GitHub secret scanning detectors for Anthropic, Cloudsmith and Salesforce Marketing Cloud. The two new Anthropic key types are blocked by push protection by default. If your team wires LLM calls into campaign tooling, check your settings this week.

What the new GitHub secret scanning detectors cover

The GitHub changelog lists four new secret types:

• Anthropic: anthropic_service_api_key and anthropic_user_api_key. Secret scanning raises alerts, and per the changelog, commits containing them are blocked automatically for repositories with secret scanning enabled, free public repositories included.
• Cloudsmith: cloudsmith_api_key. Alerts only. The supported patterns page shows no push protection for it.
• Salesforce: salesforce_marketing_cloud_api_oauth2_token. Salesforce joins as a new secret scanning partner. When this token shows up in a public repository, GitHub forwards it to Salesforce so they can revoke or rotate it.

The patterns page also lists Anthropic's admin, API key and session ID types, so Anthropic coverage is now broad.

Why marketing and AI teams should care

Marketing-tech repos collect credentials: send scripts, notebook experiments, exported automation configs, and now a quick Claude call to draft subject lines. These files get shared, forked and pasted into tickets more than backend code does.

A leaked LLM key is a spending problem. A leaked marketing platform token touches customer data and your ability to send as your brand. Push protection helps with new commits, but it won't catch what is already in your history.

Check that secret scanning and push protection are on

The default block only applies where secret scanning is enabled. Read the current state of a repository (you need admin rights on it, or be an org owner or security manager):

gh api repos/<owner>/<repo> --jq '.security_and_analysis'

If either status is disabled, switch both on through the repository update endpoint:

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

In the UI, the path is Settings, then Advanced Security, then Enable next to Push protection. Do the same at org level if you manage many repos.

Find leaked keys for the new secret types

List open alerts across your organization, filtered to the four new types. This needs org admin or security manager access:

gh api --paginate "/orgs/<your-org>/secret-scanning/alerts?state=open&secret_type=anthropic_service_api_key,anthropic_user_api_key,cloudsmith_api_key,salesforce_marketing_cloud_api_oauth2_token" --jq '.[] | [.repository.full_name, .number, .secret_type, .html_url] | @tsv'

An empty list is not a clean bill of health. The changelog doesn't say whether the new detectors rescan old content, and the Salesforce token is a partner pattern, so alerts may go to Salesforce rather than appear in your Security tab. If a key has ever touched a repo, treat it as exposed.

Rotate first, then move the key into a secrets manager

Order matters. Create a replacement in the provider's console, deploy it, then retire the old key. Deleting the commit does not un-leak a secret.

Then make the code read credentials at runtime. The Anthropic SDK picks up ANTHROPIC_API_KEY automatically, so nothing needs to live in the repo:

import os
import anthropic

# The SDK reads ANTHROPIC_API_KEY from the environment by default.
client = anthropic.Anthropic()

# Same rule for marketing credentials: inject at runtime, never commit.
sfmc_client_secret = os.environ["SFMC_CLIENT_SECRET"]

Populate those variables from your CI secret store or cloud secrets manager. Store the credentials that mint a Marketing Cloud token, rather than the token itself.

Gotchas

• Default blocking is narrow. The changelog names only the two Anthropic types as blocked by default. The patterns page marks Salesforce as supporting push protection, but the changelog doesn't list it as default, so verify it on a test repo.
• Cloudsmith has no push protection. You get alerts after the fact, so pre-commit hooks still matter for package registry keys.
• Bypasses create alerts. A contributor who overrides a block generates an alert, so someone has to watch for them.
• Version coverage is partial. For versioned tokens, push protection covers only the latest versions GitHub can identify with confidence. Legacy formats may slip through.
• No validity check for the new Anthropic types. The docs show none for service and user keys, so you can't triage by "still active". Assume live.

Secret scanning is a safety net, not a secrets strategy: in production, the goal is that no repo ever holds a key worth stealing.