GitHub push protection now blocks Anthropic user and service account API keys by default

What GitHub changed on October 13

A GitHub changelog entry dated October 13, 2026 adds two new Anthropic secret types to secret scanning: anthropic_user_api_key and anthropic_service_api_key. According to the entry, cited in a dev.to analysis by Gabriel Anhaia, both types are now part of the set that push protection blocks by default, so commits containing them are stopped automatically in any repository where secret scanning is enabled — including free public repositories — and detections surface as alerts wherever scanning is switched on.

The same entry bundles in a Cloudsmith API key detector and adds Salesforce as a secret scanning partner for Marketing Cloud API OAuth2 tokens, meaning partner secrets found in public repositories are forwarded to the issuer for revocation or rotation. Anthropic is not new to the program: GitHub named it a partner on August 20, 2024, and the supported patterns table already listed anthropic_api_key, anthropic_admin_api_key and anthropic_session_id. Anthropic's key safety documentation says keys exposed in public repositories are deactivated automatically and the affected user is notified by email.

Why these two key types

The new detectors track how Anthropic now structures key creation. Its API documentation asks you to pick a type when creating a key: a personal key acts as its owner and stops working when that person leaves an organization, while a service account key is intended for shared workloads such as CI pipelines, production services and agents. The guidance is essentially personal keys for individual development, service account keys for anything shared. A third, older workspace key is described as a legacy key without an owner that keeps working after its creator departs. As the dev.to post notes, equating GitHub's "user" detector with Anthropic's "personal" key is an interpretation; neither company states the mapping outright.

What a block covers, and how it can be bypassed

GitHub's push protection documentation, referenced in the dev.to piece, says the check applies to command-line pushes, commits made through the GitHub web UI, file uploads, REST API requests and — for public repositories only — interactions via the GitHub MCP server. That last case matters for coding agents that write to GitHub over MCP rather than plain git.

A block is not final. Anyone with write access can push past it by choosing a bypass reason, and the choice has consequences: marking a secret as used in tests or as a false positive closes the alert, while deferring the fix leaves it open. Where repository-level push protection is enabled, every bypass is recorded in the audit log and emailed to owners, security managers and repository admins. With only the default user-level protection, a bypass generates no alert at all — so on a public repository with default settings, an agent operating with a developer's credentials can wave a blocked key through with nothing left for review. And since push protection intervenes at push time, the key remains in local history regardless.

The private repository gap

The protection comes in two forms with different reach. Push protection for users is on by default and, per the documentation, applies to public repositories. Push protection for repositories requires GitHub Secret Protection and stays off until an admin, owner or security manager enables it. The practical consequence: a private repository on default settings gets no block for these Anthropic key types — or any others. The October 13 change lengthens the default blocklist; it does not switch protection on anywhere it was previously off.

Practical steps

• Enable organization- or repository-level push protection wherever GitHub Secret Protection is available; it stays off until someone does.
• Issue service account keys to agents and CI, so a leaked automation key can be revoked without touching a person's key, and personal keys die naturally when their owner leaves.
• Keep .env files out of the tree and audit existing history. Anthropic keys start with sk-ant-, which makes a git log grep a usable first pass. If a real key was ever pushed, rotate it in the Claude Console first — rewriting history cannot recall a key someone already copied.

Why it matters

AI credentials have become routine working material: agents hold API keys, push with developer credentials, and increasingly write to GitHub over MCP rather than git. This change closes two more gaps in the default safety net for exactly that workflow — but the net still has known holes, including private repositories on default settings, unlogged bypasses on public ones, and everything outside git such as shell history. Teams running agents against Anthropic APIs should treat the block as a backstop, not a policy.