GitHub AI Scan for Pull Requests: Coverage, Limits and AI Credit Costs

A pull request can introduce a security vulnerability in a file that a repository's existing scanner does not understand. GitHub's AI Scan for pull requests became generally available on October 15, 2026, adding an AI-based detection layer for changes written in languages and frameworks outside CodeQL's current coverage. The feature can flag risks and suggest fixes while developers review a change, but it has a critical limitation: its findings cannot block a merge. Here is how the feature works, which repositories can use it, and what teams should check before enabling it across their projects.

AI Scan fills gaps that CodeQL does not cover

CodeQL is GitHub's code analysis engine, which examines source code using queries designed to identify security vulnerabilities and other problems. It provides structured, high-precision analysis for supported languages, but not every technology used in a modern application is covered. GitHub's AI Scan adds another detection method for pull request changes in areas such as PHP, Shell and Bash, Terraform configuration, Dockerfiles, JavaServer Pages (JSP) and Blazor applications written in C#.

The distinction matters for teams maintaining mixed technology stacks. A repository might use a supported language for its main application while relying on shell scripts for deployment, infrastructure configuration for cloud resources and Dockerfiles for packaging. CodeQL may not provide equivalent coverage for every part of that system, leaving some changes outside its normal analysis path. AI Scan is intended to help examine those gaps, rather than replace CodeQL or make every file equally well covered.

Findings appear during pull request review

When code scanning and the repository's effective AI Scan setting are enabled, GitHub runs AI Scan on eligible pull requests and subsequent commits. Results appear on the pull request's Conversation and Files changed tabs, alongside other code-scanning information, with an AI indicator distinguishing these findings from CodeQL alerts. A finding can explain the suspected security risk and include a suggested autofix, giving the developer a starting point for investigating the problem.

This placement is useful because the developer can inspect a potential vulnerability while the proposed change is still under review. Consider a pull request that changes a shell deployment script or modifies a Dockerfile: the scan may flag a risky operation before the change reaches the default branch. The developer must still inspect the affected lines, understand the surrounding application and test any proposed correction. An AI-generated explanation or fix is evidence to investigate, not proof that a vulnerability exists or that the suggested change is safe.

AI Scan findings cannot currently enforce merge protection

The most consequential limitation is the difference between identifying a risk and enforcing a security policy. GitHub states that AI Scan findings are advisory: they do not fail the code-scanning check and cannot be used to block pull request merges through ruleset requirements. Teams therefore cannot treat the feature as a mandatory security gate in the same way they might configure required checks for other supported analyses.

This affects how organizations should introduce the feature. AI Scan can help reviewers discover issues that would otherwise be overlooked, but a team that needs to prevent unapproved code from merging still needs an enforceable review and testing process. Existing required checks, code review rules and supported security controls should remain in place. Until GitHub provides stronger enforcement for these findings, treating AI Scan as an additional reviewer is more accurate than treating it as an automatic approval or rejection system.

Repository eligibility depends on ownership and visibility

General availability does not mean that every repository can run AI Scan under identical conditions. GitHub documents availability for public repositories owned by personal accounts or organizations, while private and internal organization-owned repositories require GitHub Code Security or GitHub Advanced Security. Private repositories owned by personal accounts are not eligible under the documented availability rules, and repositories in a managed user account's personal namespace are also excluded.

AI Scan does not run on pull requests created from forks or on pull requests created by Dependabot, GitHub's automated dependency-update service. These exclusions mean that an organization should not assume every incoming contribution receives the same scan. Fork-based contribution workflows, in particular, need other appropriate review and security checks because a scan that does not run cannot provide a finding for reviewers to evaluate.

A GitHub Copilot subscription is not required to use AI Scan. That is a useful distinction for teams that want AI-assisted security detection without buying a Copilot license for every developer. However, the absence of a Copilot requirement does not make the feature cost-free: AI Scan uses a separate Code Security AI Credits billing category, including for eligible public repositories.

AI credits make rollout planning part of security configuration

GitHub bills AI Scan usage through Code Security AI Credits rather than treating every scan as included in ordinary repository access. If the billing account has eligible credits included through a Copilot entitlement, AI Scan can use those first; after the allowance is exhausted, additional usage may be metered under the applicable billing arrangement. If the account has no included credits, usage is metered from the outset, subject to the configured budget and billing terms.

Organizations should review their credit allowance and set suitable budgets before enabling AI Scan broadly. A hard budget that leaves no credits available can stop the feature from producing findings until the budget is raised or a new billing cycle begins. This creates an operational consideration: a security team should know whether scanning has stopped because a repository is ineligible, a setting is disabled or the available credit budget has been exhausted. Monitoring usage alongside scan activity helps distinguish those cases instead of assuming that an absence of findings means the code is safe.

Enable the feature in stages and measure its usefulness

For an organization evaluating AI Scan, the sensible first step is to identify repositories that use languages or configuration files not adequately covered by the existing analysis setup. Confirm that code scanning is enabled, review the effective AI Scan setting at the organization and repository levels, and check repository eligibility and billing before expanding the rollout. GitHub also provides organization and enterprise security reporting for AI Scan activity, including generated findings, resolved findings, remediation rates and the frequency with which developers apply suggested fixes.

Those metrics can help teams understand whether the feature is finding useful issues and whether developers are acting on them, but they do not independently establish detection accuracy. A high number of findings could indicate useful coverage or an investigation burden; a high remediation rate does not prove that every finding was a true positive. Security teams should review representative findings, record false positives, validate fixes with tests and compare the results with their existing scanners before deciding how broadly to deploy the feature.

Keep existing scanners and human review in the workflow

AI Scan is most useful when a project has meaningful security coverage gaps and developers can investigate findings during pull request review. It is less suitable as the sole control for repositories that require mandatory merge blocking, comprehensive coverage of every language or guaranteed analysis of fork-based contributions. Its advisory nature, eligibility restrictions and credit-based billing all need to be considered alongside the potential benefit of catching additional issues.

Before switching it on across an enterprise, choose a small group of eligible repositories and review actual results over a defined evaluation period. Check whether the findings identify risks that existing tools missed, whether suggested fixes survive testing and whether credit consumption fits the team's budget. That evidence will show whether AI Scan improves the review process for the code the organization actually maintains, rather than simply adding another security dashboard to monitor.