GitHub Push Protection Preview Blocks Secrets Without Predefined Formats, Off by Default and Billed in AI Credits

GitHub announced on October 28, 2026 that push protection can now block secrets that have no predefined format, in a public preview. A purpose-built classifier, developed with Microsoft Applied Sciences, looks at how a possible secret is used in the surrounding code. Until now, push protection depended on predefined patterns to recognize each secret type. The new check runs alongside those pattern detectors, is off by default, and uses billable AI credits.

The older approach has a clear gap. A pattern detector recognizes a token because it has a known shape, such as a fixed prefix from a service provider. A password, an internal key or a token from a small vendor may have no such shape. The new classifier instead reads context: how the string is assigned, passed or used nearby in the code. GitHub says this lets it block secrets without a known and recognizable format. The page does not describe the model, its training data or its false-positive behavior in detail.

When the classifier runs, it covers new pushes, commits made in the GitHub web interface and file uploads. If it detects a secret, GitHub rejects the change and reports where the secret is. To resolve a block, the developer removes the secret from every commit in the push and tries again. Existing bypass and delegated bypass workflows still apply. GitHub also states a rule for automation: agents must get authorization before bypassing or working around a block. That line matters as coding agents push code, and it makes the human approval step explicit.

GitHub reports early results with a careful wording. It says the classifier more than doubled the number of pushes where push protection caught a secret. That counts pushes, not distinct secrets; the page does not disclose the comparison condition or observation period. GitHub also reports a user-reported precision rate that rivals issuer-defined detectors from its secret scanning partners. The page gives no sample size, absolute counts or false-positive rate, so these claims are GitHub's own and cannot be checked from the page.

Enablement has three prerequisites. A repository needs both AI-detected secrets and push protection already turned on. The feature is available to organizations that have GitHub Secret Protection or GitHub Advanced Security on github.com. Administrators then turn on Block AI-detected secrets. A repository admin does this in repository settings, under Advanced Security, Secret Protection, AI-detected secrets. Organization and enterprise admins create or edit a custom security configuration with three settings enabled: AI-detected secrets, push protection and Block AI-detected secrets. The REST API fields are secret_scanning_generic_secrets, secret_scanning_push_protection and secret_scanning_generic_secrets_push_protection. The configuration is then applied to the repositories to protect.

Cost needs attention. AI detection in push protection consumes AI credits, and billing begins once an organization opts in to the preview and enables the feature. By contrast, AI-detected secret alerts from scanning after a push remain included with Secret Protection and Advanced Security at no additional charge. The preview is limited to github.com, so teams on other deployments should not expect it yet. A sensible trial is a few repositories, with a record of blocked pushes and false alarms, before the cost and developer friction of a wider rollout.