GitHub ships a purpose-built model that catches the tokenless secrets regex misses
GitHub rolled out a fine-tuned secret-detection model that reads surrounding code to flag likely credentials, including passwords with no recognizable token format — exactly what regex-based secret scanning lets through. If you already pay for GHAS or GHSP, the switch is free and automatic; the AI push-protection and review checks will consume AI Credits you need to budget for.
October 7, 2026. GitHub announced a fine-tuned secret-detection model, purpose-built for the task, rolling out across secret scanning alerts, push protection and Copilot security reviews. Its defining trait fits in one sentence: it reads the surrounding code to identify likely credentials — including passwords with no recognizable token format — without generating code or prose. Why it matters: for years, secret detection has rested on regex patterns, and any password that did not look like a known token slipped through. That is exactly the gap this model closes.
A dedicated model instead of a general-purpose LLM
GitHub’s choice is a statement of method, not a technical detail. Rather than wiring a generic large language model to the problem, the team fine-tuned a classifier dedicated to secret detection. The difference is concrete: an LLM generates text and reasons in broad strokes, which makes it expensive and chatty for a binary task — “is this a secret or not.” A dedicated model just classifies, without producing code or prose, which makes it faster, cheaper and more reliable on false positives.
The clearest benefit concerns unstructured secrets. Classical pattern detection recognizes a token — an AWS key AKIA…, a GitHub access token ghp_… — because it follows a predictable shape. But a database password, a hard-coded secret that looks like an arbitrary string, has no recognizable format. The new model reads the context — the variable the value is assigned to, the line around it — to decide it is probably a credential. This is the move from syntactic detection to semantic detection.
A three-tier rollout
The release proceeds in tiers, with different availability status depending on the surface.
The first tier is already live: customers with AI-detected password alerts are automatically switched to the new model at no additional cost for GHAS or GHSP holders. In other words, if you had already enabled AI detection of passwords, you get the improved model without lifting a finger.
The second tier, AI detection in push protection, is in private preview. The check runs at push time, before a secret enters repository history — the moment it is still recoverable without rewriting history. An administrator must enable it, and it is limited to GitHub Enterprise Cloud or GitHub Teams organizations with GHSP or GHAS.
The third tier, secret checks in the Copilot /security-review command, arrives soon in private preview. The command reviews active changes before a commit, push, or review request, and returns prioritized findings with remediation suggestions. The new secret checks will be off by default: running /security-review does not enable them; you must opt in explicitly where your plan and policies allow.
AI Credits billing worth decoding before you enable
This is where the decision becomes a budget trade-off. GitHub cleanly separates two things: AI-detected secret scanning alerts remain included in GHAS and GHSP, at no extra cost. But the new opt-in checks — AI push protection and the /security-review command — will consume AI Credits, billed under a dedicated SKU, Secret Protection AI Credits.
Two points deserve a security lead’s attention. First, a push protection check can consume credits even if it does not block the push: the cost is tied to running the check, not to its outcome. Second, consumption is attributed to the organization that owns the repository, not to the pushing user’s account — except for user-namespace repositories under enterprise-managed users, where it falls to the user.
GitHub is honest enough to announce the billing model before broad enablement, leaving time to review costs. The operational advice is simple: before enabling, open Billing and licensing, choose Budgets and alerts, create a SKU-level budget on Secret Protection AI Credits, and turn on Stop usage when budget limit is reached where available. A budget alert alone does not stop consumption.
A response to the age of coding agents
The timing is not accidental. The proliferation of coding agents — Copilot, but also third-party agents that generate and push code — mechanically multiplies the volume of code produced, and therefore the volume of secrets potentially hard-coded. An agent assembling a database connection string from an example can copy a password where a human would have used a secrets manager.
That is the coherence of GitHub’s model: semantic detection fills the hole left by patterns, and push protection moves it as early as possible in the cycle, before the secret even exists in history. For a security lead overseeing a fleet of agents, this is one more lever beyond code scanning, and it plugs into a flow — the push — that agents already trigger without human supervision.
The hidden cost of false positives
Secret detection is only as good as its precision, and that is where a dedicated model delivers its least visible but most profitable difference. Pattern detection has a structural flaw: to widen coverage, it multiplies rules, and every extra rule adds noise. A value that looks like a token — a hexadecimal string in a unit test, an example identifier — triggers an alert that pulls in a developer for nothing.
Alert fatigue is the real risk. When secret scanning produces too many false positives, the team ends up closing alerts without reading them, and that is exactly the behavior that lets a real secret drown in the noise. A trained classifier reads the context — the password = variable, the db.connect( line just above — and decides with calibrated confidence, cutting noise without sacrificing recall.
This is also what makes push protection viable. A check that runs on every push cannot afford to interrupt a developer over a false positive: at best it becomes a nuisance, at worst it gets disabled. The dedicated model, fast and lean, is calibrated for that execution point, where a general-purpose LLM would be too slow and too costly to run systematically.
The model also plugs into a broader shift-left direction. Where classical secret scanning only fires on the server after a push, the push-protection tier stops the secret before it lands in history, and the /security-review command stops it before the developer even commits. Each step moves detection earlier in the cycle, and earlier is always cheaper to fix.
Verdict
If you already pay for GHAS or GHSP, verify that the automatic switch of AI alerts is effective on your repositories — it is a free gain, and confirming activation is all it takes. If you want AI push protection or /security-review checks, do not enable them without budgeting AI Credits and setting a stop cap: a check that runs on every push from several hundred developers can get expensive, even when it blocks nothing. If you are on GHES, the model arrives in public preview in version 3.23 — plan the upgrade if you want it without waiting. The underlying message is the same as for all secret detection: catch it early, because a secret that enters history is, for all practical purposes, already compromised.