Security

GitHub AI Scan for Pull Requests: What It Cannot Gate

GitHub AI Scan covers pull-request changes beyond CodeQL, but its findings cannot block merges. Use it as review evidence, not a security gate.

WealthLab

— 5 min read
Share
Pull request security review diagram separating advisory AI findings from blocking merge checks

Quick answer: GitHub made AI Scan for pull requests generally available on October 15, 2026. It can flag possible vulnerabilities in changed PHP, Shell/Bash, Terraform HCL, Dockerfiles, JSP, Blazor, and other areas that CodeQL does not currently cover. But it is an advisory reviewer, not a merge gate: its findings do not fail the code-scanning check and cannot be required by rulesets. Keep blocking linters, policy checks, secret scanning, tests, and human review in place.

This is a source-based operator analysis. WealthLab reviewed GitHub's dated announcement and current product documentation, then compared the stated behavior with independent technical coverage. We did not enable AI Scan, submit a pull request, measure detection quality, or reproduce a vulnerability. Nothing below should be read as a benchmark or a claim that the scanner found every eligible issue.

What reached general availability

GitHub's October 15 announcement says AI Scan complements CodeQL by analyzing pull-request changes in languages and frameworks CodeQL does not currently cover. GitHub names PHP, Shell/Bash, Terraform configuration in HCL, Dockerfiles, JavaServer Pages, and Blazor for C# as examples. Findings appear on the pull request's Conversation and Files changed tabs with an AI indicator. They can include a risk explanation and, for many findings, a suggested remediation.

The scan runs when code scanning is enabled, the repository's effective AI Scan setting is enabled, and the pull request contains qualifying changes. GitHub says it triggers when a pull request is created and after each new commit, without requiring CodeQL default setup, a build system, or a successful CodeQL run.

The limit that changes the operating model

An AI Scan finding cannot block a merge. GitHub's announcement and documentation state that findings are advisory: they do not fail the code-scanning check and cannot yet be used as ruleset requirements. A green required check therefore does not prove that reviewers resolved every AI-labelled finding.

For an operator, the safe interpretation is simple: AI Scan adds review evidence. It does not replace an enforceable control. Assign a reviewer to inspect its findings, record whether each finding was fixed, accepted, or rejected as a false positive, and keep deterministic checks responsible for the actual merge decision.

Coverage gaps to plan around

  • Pull-request changes only: GitHub says full-repository scans are not supported. Existing files on the default branch do not gain a baseline review merely because the feature is enabled.
  • No fork pull requests: contributions opened from forks are excluded. This is material for open-source projects that receive outside contributions through forks.
  • No Dependabot pull requests: GitHub excludes pull requests created by Dependabot.
  • No backlog alert: AI Scan findings exist on pull requests and do not appear as persistent backlog alerts in the repository security view.
  • Possible false positives: GitHub explicitly warns that AI-based findings can be inaccurate and provides feedback controls.
  • Changing scope: supported languages and detection categories can evolve. Confirm the current documentation rather than treating this article as a permanent compatibility matrix.

Why self-hosters should care

Infrastructure repositories often mix application code with Dockerfiles, shell deployment scripts, Terraform, CI workflows, and configuration. Those files can create high-impact failures through broad network exposure, unpinned dependencies, unsafe interpolation, leaked credentials, or excessive permissions. GitHub's documented detection categories include injection, broken access control, sensitive-data exposure, security misconfiguration, authentication failures, server-side request forgery, and supply-chain risks.

That makes AI Scan potentially useful as another set of eyes on agent-written or human-written infrastructure changes. It does not prove a Docker image is trustworthy, a Terraform plan is safe, a secret was never exposed, or a deployment is recoverable. Runtime configuration, effective cloud policy, image provenance, and post-deployment behavior remain outside a pull-request-only finding.

A practical merge-control design

  1. Keep deterministic gates. Require tests, formatting and lint checks, infrastructure policy-as-code, dependency and secret scanning, and the relevant CodeQL checks where supported.
  2. Make AI findings a named review step. Add a pull-request checklist item that asks the reviewer to inspect the Conversation and Files changed tabs for AI-labelled findings.
  3. Do not infer a clean scan from silence. Confirm that the pull request was eligible and the effective repository or organization setting was enabled before interpreting an absence of findings.
  4. Cover excluded pull requests. Apply the same blocking checks to fork and Dependabot changes, since AI Scan does not run on those pull requests.
  5. Build a baseline separately. Scan the default branch with tools designed for repository-wide analysis. AI Scan's pull-request scope does not audit unchanged legacy code.
  6. Review suggested fixes as code. A generated remediation is a proposal. Test it, review security side effects, and confirm that it addresses the root condition instead of only suppressing a symptom.
  7. Track accepted risk. Record why a finding was dismissed or deferred, who accepted it, and when it should be reviewed again.

Fit and non-fit cases

Good fit: organizations using pull requests for PHP or infrastructure changes that want an additional advisory signal without introducing a separate build step for this scanner.

Partial fit: open-source projects with mostly fork-based contributions. The feature can still review eligible maintainer branches, but the documented fork exclusion leaves a major part of the contribution path uncovered.

Not sufficient by itself: regulated merge approval, a full repository security baseline, supply-chain provenance, production policy validation, dynamic application testing, incident investigation, or any workflow that requires a machine-enforced stop.

Enablement and cost checks

GitHub says AI Scan is available for public repositories owned by organizations or personal accounts without requiring a Copilot license. Private and internal organization-owned repositories require GitHub Code Security or GitHub Advanced Security. Usage consumes Code Security AI Credits. Availability, entitlement, and billing controls can change, so administrators should verify the current plan, organization policy, effective repository setting, and budget before rollout.

Roll out to a small representative repository first. Check eligible and excluded pull-request paths, document who reviews findings, verify that existing required checks still enforce the intended gate, and define a rollback path that disables the feature without removing established controls.

Evidence boundary and sources

Sources checked October 22, 2026:

No hands-on scan or detection benchmark was performed. Product scope, pricing, eligibility, and supported technologies may change after publication; verify current GitHub documentation and effective account settings before adoption.

This analysis is non-commercial and contains no affiliate links.

Read more