GitHub changed secret scanning twice this summer. On 15 July 2026 it added detectors, expanded default push protection and added a webhook field. On 7 October 2026 it announced a purpose-built model for leaked secret detection, with AI checks in push protection that consume GitHub AI Credits. If you manage an organization, both affect how you set this up.
This guide gives the setup order, then the details of each change.
What's affected
From the 15 July changelog:
- New secret types: APIclub (
apiclub_api_key) and Resend (resend_api_key). Resend is now a secret scanning partner, so exposed Resend secrets in public repositories are forwarded to it. - Push protection now blocks VolcEngine keys (
volcengine_ark_api_key) by default on repositories with secret scanning enabled, including free public ones. - The
secret_scanning_alertwebhook gains asecret_categoryfield with the valuesdefaultorgeneric. Generic covers generic patterns and AI-detected secrets.
From the 7 October changelog:
- A fine-tuned model reads the code around a match to flag likely credentials, including passwords with no recognizable format. Customers who had AI-detected Password alerts were moved to it automatically.
- AI-detected secret alerts stay included in GitHub Secret Protection and GitHub Advanced Security at no extra charge.
- AI secret detection inside push protection is in private preview, and its checks consume AI Credits once billing starts. Usage bills to the repository's owning organization, even when the check does not block a push.
- On GitHub Enterprise Server, only AI-detected alerts are coming (3.23). There is no push protection or security review command there.
How to check if you're exposed
Two checks, in order.
- Is push protection actually on everywhere? In the organization, go to Settings, then Advanced Security, then Configurations. Look at which configuration each repository uses and whether "Push protection" is set to Enabled.
- Do your integrations handle the new field? If a webhook consumer or SIEM parses
secret_scanning_alertevents, check how it treats asecret_categoryofgeneric. Generic findings need a human judgment call and should not page someone at night.
What to do now
- Create or edit a custom security configuration. Under Secret scanning, set Push protection to Enabled.
- Set "Bypass privileges" to Specific actors and pick a short list. Secret teams cannot be added at the org level. Use the Exempt option only with caution, since GitHub warns it can lead to leaked secrets.
- Click Save configuration, then apply it to your repositories. If an org or enterprise configures delegated bypass, repository-level settings are disabled, which is what you want.
- Create a custom organization role with the permission "Review and manage secret scanning bypass requests" and give it to two or three people. Bypass list members can push without approval. Role holders review requests.
- Decide about the AI preview before it bills. Admins can disable the capabilities by policy and set a budget under Billing and licensing, then Budgets and alerts. GitHub notes that budget alerts alone do not stop usage, so enable "Stop usage when budget limit is reached" if you want a hard cap. If you already use the private preview, it will consume AI Credits once billing takes effect.
- Send bypass alerts somewhere a human reads. Push protection generates an alert each time a contributor bypasses the block.
- Make revocation part of the playbook. A blocked push is cheap. A bypassed one needs the credential rotated.
Why it matters
Push protection works because it runs before the secret is public. A scanner that runs after the push gives you an alert about a credential that is already in history and possibly already copied. Our post on why push protection does not clean your git history covers what remains after a bypass.
Generic and AI-detected findings change the economics. They catch passwords that no provider pattern would, but they also create judgment calls. Treat secret_category: generic as a triage queue, not an incident feed, and keep provider-specific findings on the fast path.
Try it yourself
Open a test repository in your organization, push a branch with a fake key in a well-known provider format, and watch the block. Then request a bypass as a user without the review permission and confirm that the request reaches the role you created. Time how long it takes. That time is your real bypass policy.
Click through it at your own pace, or open it full screen.
Quick check
Who can push a commit containing a secret without approval?
Members of the bypass list: specific roles or teams at repository level, or specific actors at organization level. Everyone else must request a bypass.
Does a budget alert stop AI Credit usage?
No. GitHub says to enable "Stop usage when budget limit is reached" for a hard cap.
