GitHub secret scanning just got smarter. On October 7, 2026, GitHub announced a small AI model that can spot passwords and other secrets that have no fixed pattern. That matters because the old checks mostly looked for known token formats, and plenty of real leaks never matched one.

I coordinate delivery for web and mobile projects, and leaked keys are one of the most common security scares we deal with. So I read GitHub's announcement, its changelog and a fresh study from Truffle Security on leaked credentials. Here is what changed, what it costs and what agencies in India and the USA should do now.

GitHub release graphic showing a git push rejected by push protection because a generic secret was detected by AI — GitHub's release graphic for its purpose-built secret detection model. Image: GitHub.

What GitHub Announced on October 7

Erin Havens, who leads product for secret scanning at GitHub, laid out the plan in an essay titled Secret protection must scale with software. The centrepiece is a fine-tuned classifier built with Microsoft Applied Sciences. It is based on ModernBERT, and it does not write code or text. It only judges whether a value looks like a real secret.

Here is what is rolling out:

Better alerts, at no extra cost. Organizations already using AI secret detection were moved to the new model on October 7. These after-push alerts stay included with GitHub Secret Protection and GitHub Advanced Security.
AI checks at push time. The model can now block unstructured secrets before they reach your repository history. This is in private preview, with wider release planned later this month.
Self-hosted support. AI-detected alerts are coming to GitHub Enterprise Server 3.23 in public preview, including air-gapped setups.
Checks inside Copilot. The classifier is being added to the /security-review command in the Copilot CLI and Copilot app, so developers can catch secrets before they push.

GitHub says the model checks a batch of candidate secrets in under two milliseconds. It also says adding the model to push protection could more than double the number of secrets it can prevent.

Why GitHub Secret Scanning Needed an AI Upgrade

Classic secret scanning works well on tokens with a clear shape. An AWS key, a Slack token or a GitHub token has a known prefix, so a pattern can find it and block it with confidence.

The trouble is everything else. A database password inside a connection string can be any random word. A value in a Kubernetes Secret manifest or a Dockerfile has no label that says "this is a secret." Pattern rules either miss these or flag so many false alarms that developers start ignoring them.

The new model reads the code around a value. In GitHub's demo, it blocks a real password in a database URL, a Kubernetes Secret and a Dockerfile, while letting the placeholder "changeme" through. That context is what plain pattern matching lacks.

The Numbers Behind the Change

GitHub shared nine quarters of data. A few figures stand out:

One in three pull requests on GitHub now involves an AI agent. A year ago it was fewer than one in ten.
A new secret appears in public code about every two seconds, and that rate has doubled each year for three years.
Between Q2 2024 and Q2 2026, screened pushes grew 2.84 times, while pushes carrying credentials grew 2.59 times.
Push protection stops about 30% of newly detected secrets before they enter history. The other 70% are found after the leak has already happened.
Manual revocation takes about 40 days on average, and roughly one in five takes more than 90 days.

GitHub's point is worth repeating. Developers are not getting more careless. The share of blocked pushes that developers overrode actually fell from 6.63% to 3.93%. There is simply far more code, so the same leak rate produces far more leaks.

Terminal output showing GitHub push protection rejecting a push because a generic secret in config/production.env was detected by AI — In GitHub's demo, push protection rejects a push after the AI model flags a password inside a database connection string. Image: GitHub.

What It Costs and Who Gets It

This is the part agency owners should read twice. Some of the new checks are not free, and the billing is easy to miss.

Feature	Who can use it	Cost
AI-detected alerts after a push	GitHub Secret Protection or Advanced Security customers	Included, no extra charge
AI checks in push protection	GitHub Enterprise Cloud or GitHub Team with paid Secret Protection or Advanced Security	Uses AI Credits, billed to the org that owns the repo
Secret checks in Copilot /security-review	Copilot plans, including individual plans, no Secret Protection license needed	Uses AI Credits on top of normal review usage
AI-detected alerts on GitHub Enterprise Server 3.23	Server customers with Secret Protection or Advanced Security	Included, public preview

According to GitHub's changelog, a push check can use credits even when it does not block anything. An administrator must turn the feature on, and the new Copilot checks are off by default.

GitHub also warns that budget alerts alone do not stop spending. If you want a hard cap, you need to set "Stop usage when budget limit is reached" where it is available. You can create a budget under Billing and licensing, then Budgets and alerts, using the Secret Protection AI Credits SKU.

What Push Protection Still Cannot Do

Blocking new leaks is only half the job. A study published on September 29 by Truffle Security shows what happens to secrets that already slipped through.

Truffle scanned a snapshot of 224 million public GitHub repositories called The Stack v3, a dataset built to train AI models. When it tested the keys in July 2026, 543,699 unique credentials still worked. The median one had been public for 784 days. The oldest dated back to 2009.

Two findings from the Truffle Security research on leaked GitHub credentials should change how you plan:

Push protection works where it applies. For the token types it blocks by default, the leak rate fell about 53% after GitHub turned it on for public repos in February 2024.
Most live secrets are shapes it does not block by default. About 51.8% of the working credentials were connection strings, private keys or Google API keys. Truffle also found 31,374 live Gemini API keys.

That second point is exactly the gap GitHub's new model aims at. But even a perfect block at push time does nothing for a key committed two years ago.

Bar chart of leaked credentials still working in July 2026, from 88.3% of Postgres connection strings down to almost zero npm tokens — How many leaked credentials of each type still worked when Truffle Security tested them. Source: Truffle Security. Graphic: Debugged Pro.

Revocation Is the Real Fix

Look at the chart above. GitHub and npm tokens almost never survive, because those issuers kill leaked tokens automatically. Postgres and MySQL connection strings almost always survive, because nobody revokes them.

The lesson is simple. Detection without revocation leaves the door open. Once a secret lands in a commit, treat it as burned and rotate it, even if you delete the file a minute later.

What GitHub Secret Scanning Means for Agencies

Agencies carry more secrets than most companies. We hold database passwords, payment keys, cloud accounts and AI API keys for many clients at once. One leaked key can mean a breach, a surprise cloud bill or an awkward call with a client.

AI coding agents raise the stakes. When an agent writes a config file or a deployment script, a hardcoded password can ride along unnoticed. That is one reason we pushed for scoped, short-lived access in our guide to managing AI agent credentials.

A Common Scenario

Picture a busy sprint. A developer adds a staging database URL to a .env file to debug a client bug, and an AI assistant commits it along with the fix. The key is a plain password with no prefix, so older pattern checks let it through.

The new AI check is built to catch exactly that kind of push. Without it, the password sits in history until someone notices. Going by GitHub's own revocation numbers, that can mean weeks or months of exposure.

A GitHub Secret Scanning Checklist for This Week

You do not need a big security budget to act on this. Here is a practical order of work:

Turn on secret scanning and push protection everywhere. Check every client and internal repository, not just the main ones.
Scan your history. Push protection never covered anything committed before it was on. Use GitHub's alerts or an open-source scanner to search old commits and forks.
Rotate first, clean up second. Revoke and replace any exposed key before you rewrite history. Start with database connection strings and cloud service account keys.
Move secrets out of code. Use a secrets manager or your platform's encrypted variables. The OWASP Secrets Management Cheat Sheet covers storage, rotation and access in plain terms.
Prefer keys that expire. Short-lived tokens limit the damage when something leaks.
Set an AI Credits budget with a hard stop before your admins enable the new push checks.
Add secret checks to code review. Ask reviewers and AI review tools to look for hardcoded values. Our breakdown of AI code review benchmarks explains what these tools catch well and where they miss.

For Teams in India and the USA

Many Indian agencies run client work on US cloud accounts, and many US firms hand repositories to offshore partners. Both sides should agree in writing on who owns secret scanning, who gets the alerts and who rotates a leaked key.

If you hire an outside team, ask one direct question: "Is push protection on for our repos, and when did you last scan our history?" A good partner will answer without hesitation.

Key Takeaways

GitHub secret scanning now uses a purpose-built AI model that reads context to catch passwords with no fixed pattern.
After-push AI alerts stay included with Secret Protection, but the new push and Copilot checks use AI Credits.
Push protection only helps going forward. Over half a million old leaked keys on public GitHub still worked in July 2026.
Revocation is the step that ends the risk. Rotate any committed secret, even if you deleted it fast.
Set budgets and ownership before turning on credit-based checks across client repos.

How Debugged Pro Can Help

We set up secure Git workflows, secret management and CI pipelines for businesses in India and the USA. If you want a second pair of eyes on your repositories, our software development consulting team can audit your setup and help you clean up old leaks.

About the Author

Nitin Kumar is the Lead Project Coordinator at Debugged Pro. He manages AI, web and mobile projects for clients in India and the USA. He spends much of his week turning security and platform news into practical checklists for delivery teams.