What happened
On October 28, 2026, GitHub announced a public preview called “push protection beyond predefined secret patterns.” The feature extends GitHub push protection, which previously relied on predefined patterns to identify particular secret types. GitHub says its new purpose-built classifier evaluates how a potential secret is used in the surrounding code, allowing it to identify and block values without a known, recognizable format.
GitHub developed the classifier with Microsoft Applied Sciences. The company describes the new capability as context-aware detection in the push path: rather than waiting for a scan after code has entered the repository, it can stop a new push before the change becomes part of repository history. Once enabled, it runs alongside the existing pattern-based detectors. Its coverage includes new pushes, commits made in the GitHub UI, and file uploads.
A detection causes GitHub to reject the change and report the location of the suspected secret. GitHub says that, in early results, the classifier more than doubled the number of pushes in which push protection caught a secret. It also says the user-reported precision rate rivaled that of issuer-defined detectors provided by its secret-scanning partners. These are GitHub’s reported early results, not a published independent evaluation. A developer resolving a block must remove the secret from every commit in the push and then try again.
The control is off by default. A repository must already have both AI-detected secret scans and push protection enabled before an administrator can enable blocking for AI-detected secrets. Repository administrators can do so under Settings, Advanced Security, Secret Protection, AI-detected secrets, then Block AI-detected secrets. Organization and enterprise administrators can configure it through security configurations. GitHub lists three relevant configuration settings: secret_scanning_generic_secrets for AI-detected secrets, secret_scanning_push_protection for push protection, and secret_scanning_generic_secrets_push_protection for blocking AI-detected secrets. The latter must be enabled alongside the other required controls.
The preview is available to organizations using GitHub Secret Protection or GitHub Advanced Security on github.com. It consumes AI credits once an organization opts into the public preview and enables the feature. GitHub distinguishes that paid AI-detection use in the push path from its post-push AI-detected secret alerts, which remain included with GitHub Secret Protection and GitHub Advanced Security at no additional charge. Existing bypass and delegated-bypass workflows remain in place, but GitHub says agents must obtain authorization before bypassing or working around a block.
What the archive adds
This is a new fact on a known story. Earlier coverage described GitHub bringing its fine-tuned secret-detection model to push protection and Copilot security review, including preview timing and AI Credits billing: GitHub brings its fine-tuned secret-detection model to push protection and Copilot /security-review. This announcement supplies the operational details: default-off status, required controls, enforcement surfaces, and the remediation path after a block.
Trend signal
This supports the pattern that agent security moves to runtime boundaries. The relevant boundary here is not an instruction telling a developer or agent not to expose a credential; it is the repository’s controlled write path, which can reject a change before it is recorded. Authorization requirements around bypasses make that boundary more explicit.
Why now
The timing is explained only by the product rollout: GitHub has made the capability a public preview and limits it to organizations with GitHub Secret Protection or GitHub Advanced Security on github.com. The source does not provide a broader account of why it was released on this date or when general availability might follow.
Connections to other events
GitHub has also put code scanning for AI applications into public preview, covering agent-specific risks including indirect prompt injection, sensitive-data disclosure, and excessive agency: GitHub code scanning for AI applications enters public preview. The two releases address different points in the development flow: the new control blocks likely secrets on entry, while the AI-application scanner examines application risks.
Why it matters
Generated code increases the volume and speed of repository changes, but credentials can arrive through ordinary developer work, copied configuration, generated examples, or automated changes. A detector limited to recognizable token formats leaves a gap when the value is a password, an internal credential, or another unstructured secret. GitHub’s preview attempts to close part of that gap by using code context at the point where a change is submitted.
For a security team, this is not merely another alert source. It is an enforcement decision: a suspicious change can fail before it becomes repository history, where removal is harder and exposure may spread through clones, logs, and downstream automation. Teams must nevertheless decide whether the claimed additional coverage is worth AI-credit use and potential friction from false positives. The appropriate rollout is likely scoped: enable it on selected repositories, measure blocks and bypasses, and confirm that delegated-bypass governance works for both people and automated agents.
What happens next
- Organizations with the required GitHub security products will trial the control on selected repositories before wider enablement. (3 months, 70%). Watch for: GitHub guidance or product updates on staged rollout and measurement.
- GitHub will publish more operational evidence about precision, credit consumption, or availability as the preview matures. (6 months, 60%). Watch for: changelog updates, documentation changes, or a general-availability announcement.
Limits and uncertainty
GitHub does not disclose the classifier’s training data, decision thresholds, false-positive rate, or the number and composition of the early-result repositories. “More than doubled” describes GitHub’s early results without a baseline count, a test period, or an independent comparison. The source also does not state AI-credit pricing, per-repository consumption, supported deployment variants beyond github.com, or a date for general availability. It establishes that bypass workflows remain, but not how often they are used or whether authorization enforcement is technically verified in every agent workflow. Teams should therefore treat the feature as a preview control to evaluate, not as proof that generic secret exposure is solved.
Skill to build now
Audit one protected repository’s secret-handling path this week. Confirm whether AI-detected secrets and push protection are already enabled, identify the repository or organization administrator who can alter the security configuration, and document who may approve a bypass for a human or an automated agent. Then run a limited preview rollout with a clear review of blocked changes, removals, and bypass requests. That exercise tests the operational process GitHub’s feature depends on rather than assuming a detector alone will prevent exposure.
Reader takeaway
GitHub’s preview moves generic-secret detection from a post-push signal toward a pre-history enforcement point. It can catch values that do not match known token formats, but it is default-off, requires existing GitHub security controls, uses AI credits, and still needs deliberate governance for exceptions and agent actions.
Open question
Will the classifier retain its reported precision when organizations enable it across varied repositories, and will its additional blocked pushes justify the AI-credit cost and review workload?