GitHub trained AI to catch leaked passwords before the commit

THE SIGNAL IN ONE SENTENCE

The easiest secret to clean up is the one that never reaches repository history. The second easiest is imaginary. That is the problem GitHub is trying to solve with a new model for leaked credentials. Catch more real passwords before they enter a repository, without making every harmless placeholder look like a five-alarm incident. GitHub announced on October 7 that it has moved existing AI-detected Password alerts to a purpose-built, context-aware classifier. Unlike a detector that looks only for a known token prefix or a regular-expression pattern, the model reads the code around a suspicious value. That context can help it identify an ordinary-looking password inside a database connection string, Kubernetes Secret manifest or Dockerfile while leaving a placeholder such as changeme alone. The company says the classifier is based on ModernBERT, evaluates candidate batches in under two milliseconds and does not generate code or prose. GitHub also says it is more precise than its previous LLM-based pipelines and could more than double the number of secrets prevented by push protection. Those are GitHub's claims. The launch materials do not publish the model's precision, recall, false-positive rate, evaluation set, training-data description or performance by language and repository type. Under two milliseconds describes the classifier step for candidate batches, not necessarily the delay a developer will experience across the complete push workflow. The rollout also has three different states, which are easy to blur together. First, organizations that already use AI-detected Password alerts have automatically moved to the new model. Those scans happen after code reaches GitHub and remain included with GitHub Secret Protection or GitHub Advanced Security at no additional charge. Second, AI detection inside push protection is available in private preview. This is the preventative version. It checks for unstructured credentials at push time, before the value enters repository history. GitHub says it requires GitHub Secret Protection or GitHub Advanced Security coverage on eligible GitHub Team or Enterprise Cloud repositories, and an administrator must enable it subject to organizational policy. Third, GitHub plans to add the same classifier to the Copilot CLI and Copilot app security-review command in another private preview. That command can run before a commit, push or pull-request review. The secret checks will be off by default and require a separate opt-in. They will not require a Secret Protection license, but they will consume AI Credits in addition to the command's existing usage. So the headline is directionally right and operationally complicated. GitHub has trained a model intended to catch a class of password that deterministic scanners often miss. The new model is already powering post-push alerts. The two places where it can stop a leak earlier, at push time or during a Copilot review before a commit, are not generally available yet. That distinction matters because detection and prevention are different products. An alert after a credential enters history can still be valuable. It can tell a security team what was exposed and where. But removing the string from the latest file is not enough. Someone may need to revoke the credential, issue a replacement, inspect access logs, identify systems that used it, update dependent services and decide whether the exposure became an incident. Git history, forks, caches, clones, build logs and copied artifacts can preserve the old value. A block before the push avoids much of that work. GitHub says its public scanning reported an average of 26 credential matches per second during the second quarter of 2026, including repeat observations. It also says conventional push protection currently stops about 30 percent of newly detected secrets before they enter history. The remaining 70 percent are found after the credential is already exposed. Those figures come from GitHub and describe its platform activity, not an independent audit. Still, they make the practical point. Remediation is a human queue. If software production accelerates while credential cleanup remains manual, the gap becomes somebody's very bad Tuesday. Context-aware detection can narrow that gap because passwords are messy. A cloud token may begin with a stable prefix that a deterministic pattern can recognize. An internal password can be any string someone decided was memorable enough at 4:47 on a Friday. The same characters might be dangerous in a production database URL and harmless in a fixture, tutorial or local example. A classifier can inspect variable names, file types, syntax and nearby values to estimate whether the string is a real credential. That flexibility is the benefit. It is also the source of uncertainty. A false negative lets a real secret through. A false positive interrupts a developer, creates an override habit and makes the next warning less credible. A slow check turns a security control into a reason to avoid the normal path. An expensive check quietly changes from protection into a budget argument. GitHub itself describes precision, latency, throughput and cost as coupled constraints. Teams should evaluate the feature as a decision system, not as a magic password sniffer. Start with a representative test set that belongs to the organization. Include real credential formats after replacing live values, generated canaries, connection strings, configuration files, infrastructure manifests, documentation, test fixtures and common placeholders. Measure recall on dangerous cases and precision on harmless ones. Break the results down by language, repository type and development workflow. An average can hide the exact corner where a production credential likes to live. Measure the interruption too. Record how long the check adds to a push, how often it blocks, how often developers bypass or retry, which reasons they give and how many findings lead to rotation. A detector can look accurate in a laboratory while teaching an engineering team to click past it in production. Do not make a bypass the end of the record. If a developer says the value is a test credential, the system should preserve that reason without storing the full secret. Security staff should be able to review repeated bypasses, tune exclusions and identify teams that need safer patterns. A time-limited exception is better than a permanent hole. High-consequence repositories can require delegated approval rather than allowing the pusher to grade their own homework. Billing deserves the same visibility as detection. GitHub says the existing post-push AI alert scans remain included with paid Secret Protection products. The opt-in push-protection checks and planned Copilot security-review checks will consume AI Credits. A push check can consume credits even when it does not block anything. For most organization-owned repositories, that usage is attributed to the organization rather than a particular user's allocation. Administrators will be able to control access and budgets, and GitHub notes that budget alerts alone do not stop usage unless a stop-usage control is configured where available. That creates a governance trap for agents. An agent can generate many small changes, push often and rerun reviews after fixes. Each pass may be sensible on its own while the total usage becomes difficult to predict. The agent should not enable a billable feature, change a policy or raise a budget because a repository instruction suggested it. GitHub explicitly says agents should not do that without authorization. Define the rule before the agent starts. Which repositories require the check? Which users or workflows can invoke it? What is the maximum retry count? When does the agent stop and ask a person? Who owns the bill? What happens when a budget limit stops the check? Does the push fail closed, continue with a warning or move into a manual queue? The answer should depend on consequence. A public sample project and a production identity service do not need identical gates. The detector also must not become an excuse to pass sensitive values around. Logs, alerts and model inputs should redact candidate secrets. Review interfaces should reveal only what a responder needs to locate and rotate the value. Retention should be short and access narrow. Testing should use synthetic or already-revoked credentials. A security feature that copies the entire secret into chat, telemetry and screenshots has built a small distribution system for the thing it was supposed to contain. Response remains the last line of the workflow. When a real credential is found, remove it from active code, revoke or rotate it, update dependent systems, search for reuse, inspect relevant access logs and document the incident. Rewriting Git history may reduce later discovery, but it does not make an exposed credential trustworthy again. The rotation is the fix. History cleanup is housekeeping. GitHub's new model is an interesting shift from recognizing what a credential looks like to reasoning about where it appears. That can bring protection to the awkward passwords and internal strings that do not arrive wearing a provider-issued uniform. It does not eliminate the old controls. Use environment variables or a secrets manager. Keep credentials out of examples and fixtures. Limit their scope and lifetime. Rotate them automatically. Run deterministic scanning alongside contextual checks. Make repositories, agents and people operate with the least privilege they need. The best security control is boring enough that developers keep it on and clear enough that they know what to do when it speaks. GitHub may have built a faster bouncer for the repository door. Teams still need to decide who gets stopped, who can wave someone through, how much each inspection costs and what happens when the password is already inside.