Editorial illustration of code being checked by a context-aware AI security model before a repository push

GitHub announced a purpose-built AI model for leaked-secret detection on October 7, 2026, extending context-aware credential detection across secret-scanning alerts, push protection, and planned GitHub Copilot security-review checks. The important distinction is that this is not a general-purpose chatbot asked to inspect code. GitHub says the model is a fine-tuned classifier designed to examine candidate secrets in their surrounding code context and identify likely credentials, including password-like values that do not follow a familiar token format.

The announcement matters because exposed credentials are not always neat strings that match a provider’s known pattern. A password embedded in a database URL, a value inside a configuration file, or an unstructured credential in a deployment manifest may not resemble a recognizable API-key prefix. Context can help a detector decide whether a suspicious value is plausibly a secret rather than an ordinary example, placeholder, or piece of test data.

However, the update is not one universal feature that every GitHub user automatically receives. Existing AI-detected secret alerts are being moved to the new model for eligible Secret Protection customers, while AI detection in push protection and the new Copilot security-review checks have separate preview, policy, eligibility, and AI-credit conditions. Teams should understand those differences before enabling new checks or budgeting for them.

What GitHub announced

In its official changelog announcement, GitHub described a fine-tuned model that reads surrounding code to identify likely credentials, including passwords without a recognizable token format. The company says the model classifies candidate secrets; it does not generate code or prose.

GitHub has connected the model to three distinct workflows:

  • AI-detected secret alerts: eligible customers using AI-detected password alerts are automatically upgraded to the new model. GitHub says these alert scans remain included with GitHub Secret Protection (GHSP) and GitHub Advanced Security (GHAS), with no additional charge.
  • AI detection in push protection: a private-preview capability intended to identify unstructured credentials as a developer pushes code, giving the developer an opportunity to remove the secret before it enters repository history.
  • Copilot security review: GitHub plans to add checks from the secret classifier to the /security-review command in supported Copilot CLI and Copilot app sessions. The announcement described these checks as coming soon in private preview, rather than generally available to everyone.

These distinctions are important. The first item is an upgrade to an existing paid security capability; the other two are opt-in checks with their own access and billing rules. A team should not assume that purchasing Copilot automatically enables AI push protection, or that a Secret Protection license automatically includes every Copilot security-review check.

Why context-aware secret detection is different

Traditional secret scanning often relies on recognizable patterns, provider-specific formats, entropy checks, validation, and other detection techniques. Those methods remain useful: a well-defined token format can be detected efficiently and sometimes verified with the credential issuer. But not every credential is issued as a long, uniquely formatted token.

Consider a configuration snippet containing a database connection string. The sensitive part may be an ordinary-looking password rather than a token with a known prefix. The surrounding key name, file type, syntax, and nearby configuration can provide clues that the value is a credential. The same value in a tutorial might be a harmless placeholder such as change-me, so context also helps avoid flagging every string that merely resembles a password.

A classifier trained for this task can weigh these signals together. That does not make it infallible. A context-aware model can still miss secrets, flag benign values, or behave differently across languages and repository conventions. Its role is to add another detection capability to a larger security workflow, not to replace credential hygiene, deterministic detectors, or incident response.

GitHub’s related engineering article, “Secret protection must scale with software”, explains the operational motivation. More code is being produced and pushed, including code created with AI agents, so the amount of material that security systems must inspect is increasing. Detection has to balance precision, latency, throughput, and cost: a check that interrupts developers too often loses trust, while a check that is too slow or expensive cannot be applied broadly.

Where the model is available now

The October 7 announcement describes different rollout states rather than a single global release.

Existing AI-detected alerts

Customers who already use AI-detected password alerts are automatically upgraded to the new model. GitHub says these scans remain included with their existing GHSP or GHAS purchase at no additional charge. This is the clearest currently described rollout in the announcement.

That does not mean every repository on GitHub has the same coverage. Organizations still need the relevant security product and configuration, and product entitlements differ by plan. Administrators should check their organization’s current Secret Protection settings and GitHub documentation rather than infer coverage from the presence of a repository or a Copilot subscription.

AI secret detection in push protection

AI-based push protection was announced as a private preview. The feature is intended to assess unstructured credentials at push time, before a newly introduced secret becomes part of repository history. GitHub says it is intended for customers on GitHub Enterprise Cloud or GitHub Team with purchased GHSP or GHAS coverage, subject to administrative enablement and organizational or enterprise policies.

The announcement also says that opt-in checks will consume GitHub AI Credits. Billing is planned to begin when an organization opts into the public preview and enables the feature; GitHub’s notice said the credit usage would be introduced in the coming weeks. Because preview status and billing details can change, administrators should consult the live GitHub changelog notice before enabling it.

Copilot security-review checks

GitHub also plans to incorporate the classifier into the /security-review command for supported Copilot CLI and Copilot app sessions. The command reviews active changes for security vulnerabilities and provides prioritized findings and remediation suggestions. The new secret-classifier checks are an addition to that workflow, not a replacement for the existing review.

At announcement time, GitHub described the classifier checks as coming soon in private preview. They are off by default; running /security-review does not itself enable them. Access depends on the supported Copilot plan, platform, invitations, and administrator policies. The new checks are expected to consume AI Credits in addition to the existing review usage. Organizations should not treat the announcement as proof that the feature is already enabled on their account.

GitHub Enterprise Server and platform boundaries

GitHub said the model would bring AI-detected alerts to GitHub Enterprise Server 3.23 in public preview, included with an enterprise’s existing GHSP and GHAS purchase. This is a separate rollout path from GitHub.com and Enterprise Cloud.

The announcement explicitly distinguishes the features: AI push protection is not part of that Enterprise Server release, and the Copilot security-review command is not part of that Server release. In other words, availability of AI-detected alerts on a self-hosted server should not be interpreted as availability of every new model-powered workflow.

For Enterprise Cloud with data residency on ghe.com, GitHub listed Copilot Business and Enterprise as supported plans for the security-review command, while AI push protection was described as planned with paid GHSP/GHAS coverage. Individual Copilot plans—including Pro, Pro+, Max, Free, and Student—were listed as eligible for the security-review checks subject to access controls and credit consumption. Copilot Business and Enterprise eligibility remains subject to supported platforms, invitations, and administrator policies.

These details can change during previews. Before planning a rollout, verify the current product documentation and your organization’s own policy controls. Product names can also be confusing: GitHub Enterprise, GitHub Enterprise Cloud, GitHub Enterprise Server, GitHub Team, GHSP, GHAS, and Copilot Enterprise refer to different plan, platform, or security-product concepts.

What the AI-credit notice means

GitHub separated the cost treatment of existing alert scans from the new opt-in checks. Existing AI-detected secret alerts remain included with GHSP and GHAS at no additional charge. The new push-protection checks and Copilot security-review classifier checks are expected to consume AI Credits when enabled under the applicable preview and billing conditions.

For push protection, GitHub says credit usage is billed to the organization that owns the repository, with an exception for certain user-namespace repositories belonging to enterprise-managed users, where usage is attributed to the pusher and applies to that user’s allocated credits. For Copilot security-review checks, the active Copilot plan’s billing account receives the usage, reported under GHSP in AI usage insights. Administrators should consult the current billing documentation for the final accounting rules that apply to their plan.

A useful operational point is that a check may consume credits even if it does not block a push. Credit consumption is not necessarily equivalent to a successful block. GitHub says administrators will be able to disable capabilities through organization or enterprise policy and set budgets for AI Credit usage. Opting in does not override those controls.

GitHub also warns that budget alerts alone do not stop usage. Where available, administrators who require a hard cap should configure the option to stop usage when the budget limit is reached. Before enabling a preview, review the credit price, eligible billing account, budget owner, alert thresholds, and stop-usage controls. If a team is already using AI push protection in private preview, it should check the notice’s billing transition and disable the feature beforehand if it does not want credit usage to begin.

What development teams should do

The model is most useful when it becomes one layer in a repeatable credential-protection process. Teams can take several practical steps without waiting for every preview to become generally available.

First, keep existing secret scanning and push protection configured. A new classifier should be treated as an additional signal, not a reason to remove established detectors, provider-specific checks, or preventive controls. Confirm which repositories are covered, which secret types are enabled, and which teams receive alerts.

Second, distinguish detection from prevention. Post-push alerting helps find a credential after it has appeared in a repository, but it cannot undo exposure by itself. Push protection can interrupt a push before the secret is committed, where the feature is available and enabled. Teams should know which control applies to their repository and what developers should do when a block is triggered.

Third, create a documented response for confirmed exposure. If a real credential is committed, remove the exposure where appropriate, but do not assume deleting the line from the latest commit makes the credential safe. Rotate or revoke the credential with its issuer, assess logs for misuse, review repository history and downstream copies, and follow the organization’s incident-response process. A detector is not a substitute for revocation.

Fourth, test the workflow with safe examples. Use deliberately fake credentials and placeholders in a controlled test repository. Do not test detection by committing a real production token. Evaluate whether developers understand findings, how false positives are handled, and whether the process makes it easy to fix the problem without teaching people to bypass the control.

Fifth, monitor preview costs and access. Assign an owner to AI-credit budgets and security settings. Confirm whether a feature is enabled by an administrator or policy, whether the organization has been invited to a preview, and which account will be billed. Make these details visible to engineering leads before a broad rollout.

Sixth, treat AI-generated code as code that still needs review. AI coding assistants can increase the volume of changes, but they do not remove the need to protect secrets, review permissions, validate dependencies, and inspect changes before merging. Teams using Copilot should combine security review with ordinary code review, automated tests, least-privilege credentials, and secure development practices.

Limitations and questions to keep in mind

GitHub’s announcement describes the purpose and rollout of the model, but it does not establish that the classifier will detect every leaked password or credential. No detector should be treated as complete coverage. Teams still need to avoid embedding credentials in source code, use secret managers and environment-based configuration, scope credentials to the minimum required permissions, and rotate credentials that may have been exposed.

The available information also does not justify assuming identical detection quality across every language, file type, or deployment pattern. If your organization has unusual configuration formats, generated files, or internal credential conventions, validate how the feature behaves using safe test data and review the vendor’s current documentation for supported cases.

Preview availability can be limited by invitation, product plan, platform, administrator policy, and rollout timing. Features described as “coming soon” should not be presented internally as available today. Similarly, a model upgrade to existing alerts does not imply that push-time prevention or Copilot security-review checks have been activated.

Finally, a context-aware classifier is not a general source-code vulnerability scanner. The announcement focuses on secret detection: likely credentials and password-like values. It should not be confused with every feature in GitHub code scanning, CodeQL, dependency security, or Copilot code review. Those tools address related but different risks and should be evaluated on their own capabilities.

How this fits into GitHub’s wider AI developer workflow

GitHub has been adding AI controls and security features to developer workflows, but each update has its own scope and availability. For example, our guide to GitHub Copilot’s JetBrains model controls and MCP settings covers how developers can manage model and tool behavior in an IDE. Our guide to creating a Google Gemini Gem illustrates a different category of customization: configuring an assistant for a repeatable task. These are not substitutes for secret protection, but they show why product-specific details matter when teams adopt AI tools.

Likewise, our explainer on how ChatGPT Search works, including sources and citations covers how to assess sourced answers. Security tooling requires a different standard: rather than trusting a fluent explanation, teams need to inspect the finding, confirm whether the value is a real credential, and follow the proper remediation process.

The broader lesson is not that AI makes security automatic. It is that specialized AI can add context-sensitive detection to existing controls when the feature is carefully scoped, tested, governed, and funded. The value comes from integrating that detection into the point where developers work, while preserving clear responsibility for access, budgets, remediation, and incident response.

Bottom line

GitHub’s October 7, 2026 announcement introduces a purpose-built model for detecting likely credentials in code context, including passwords that do not match familiar token patterns. Existing AI-detected alert scans for eligible GHSP and GHAS customers are moving to the model without an additional charge. AI secret detection in push protection was in private preview at announcement time, and the new Copilot /security-review checks were described as coming soon in private preview, with AI-credit implications for opt-in use.

For developers, the practical priority is to keep established secret-protection controls in place and understand which new features are actually available to their organization. For administrators, the priority is to verify eligibility, enablement, policy controls, and credit budgets before opting in. For everyone, the safest assumption remains that any credential committed to a repository may be exposed: prevent what you can, rotate what leaks, and use AI detection as one layer in a broader security program.

Official sources