GitHub now blocks Anthropic API keys at push by default

GitHub [announced on October 13](https://github.blog/changelog/2026‑10‑13‑secret‑scanning‑blocks‑anthropic‑keys‑by‑default‑adds‑salesforce/) that Secret Scanning now detects `anthropic_service_api_key` and `anthropic_user_api_key`. Both detectors are included in push protection by default. For repositories with Secret Scanning enabled, including free public repositories, a commit containing one of those patterns is blocked before it reaches the remote repository. The control targets the push path; it does not prove a secret was never copied into a local file, terminal history, build log or another service. A blocked push should be treated as evidence that a credential entered source control, even if the commit never became public.

The release also adds a `cloudsmith_api_key` detector and a Salesforce Marketing Cloud OAuth2 token pattern. Salesforce is now a GitHub secret‑scanning partner. GitHub says partner secrets found in public repositories are reported to the issuer so the provider can revoke or rotate them. User‑secret patterns generate alerts in public or private repositories. The [supported‑patterns reference](https://docs.github.com/en/code‑security/reference/secret‑security/supported‑secret‑scanning‑patterns) identifies which patterns receive partner checking, push protection or validity checks. Do not assume every new detector has the same downstream response. A pattern match, a push block, an alert, partner notification and verified revocation are separate events.

When push protection stops an Anthropic key, remove it from the change and move the value into the team's approved secret store. Then rotate or revoke the exposed credential according to the provider's controls. Editing the file alone leaves the original key valid. Check earlier commits, open pull requests, forks, CI artifacts and local developer logs for the same value. If the key reached a shared remote or build system, treat the exposure window as beginning at the earliest confirmed copy rather than at the alert time. Document the credential owner, affected environment, rotation time and any usage review. Keep unknown use as unknown unless provider logs establish it.

Push protection can allow a user to bypass a block in supported circumstances, but a bypass does not turn the detected string into a safe secret. Use it only when the value is demonstrably a test fixture, false positive or revoked credential and the repository policy permits the exception. Prefer changing fixtures so they cannot resemble live credentials. That reduces alert fatigue and prevents copied examples from becoming a pathway for real keys. GitHub's [Secret Scanning overview](https://docs.github.com/en/code‑security/concepts/secret‑security/secret‑scanning) explains that availability varies by repository visibility, organization settings and GitHub Advanced Security coverage. Verify the actual repository policy instead of assuming the default applies everywhere.

A safe rollout test should use a documented non‑secret test value, never a live Anthropic, Cloudsmith or Salesforce credential. Confirm the commit is blocked, the alert names the expected pattern and the event reaches the security team through its normal workflow. Then confirm developers know the recovery path: remove the value, rotate if real, examine exposure and retry the clean commit. The useful outcome is a closed incident with a verified replacement credential, not merely a red banner in the IDE. This update reduces one common path for leaking AI‑provider credentials, while key lifecycle and incident response remain the repository owner's responsibility. Follow [GitHub's OpenTools organization page](https://opentools.ai/organizations/github) for material security changes. *Image: Real screenshot of GitHub's official October 13 Secret Scanning release page. OpenTools captured the source page for this report; no generative alteration or artificial upscaling was used.*