GitHub AI Scan for Pull Requests: What It Finds, What It Misses, and How to Use It

GitHub can now show where AI Scan is enabled across an organization. That visibility improves governance—but enablement is not proof a repository is secure or an exact revision is ready to ship.

Codie Editorial · 2026-10-07

An organization can now open GitHub’s security overview and count how many repositories have AI Scan for pull requests turned on. That sounds like a small administrative improvement. In practice, it is the difference between believing a security tool has rolled out and being able to see where the rollout actually reached.

But there is a second question hiding behind the dashboard: what does “enabled” prove?

It proves that an eligible repository is configured to use the feature. It does not prove that every weakness has been found, that every file has been scanned, or that the revision about to ship has enough evidence to deserve production traffic.

What actually changed on October 6?

GitHub’s announcement is deliberately specific. In the Security overview Coverage page, the code-scanning summary shows how many repositories have AI Scan enabled and how many do not. Repository rows expose the effective state after policy and configuration rules are applied. Two filter expressions let administrators narrow a fleet to either set. The CSV export gains a dedicated Code Scanning AI Scan for pull requests column.

This is especially useful for companies with dozens or hundreds of repositories. A security leader no longer has to equate “we enabled it at the organization level” with “it is active for every repository that matters.” They can identify exceptions, assign owners, and track rollout.

One nuance matters: GitHub’s docs say a not enabled repository can also be ineligible. The coverage screen does not necessarily tell you *why* the feature is off. And an enabled state reflects effective enablement after enterprise policy, organization setting, prerequisites, and repository opt-outs—not a count of completed successful scans.

AI Scan, CodeQL, and Copilot review solve different problems

AI-powered security products are easy to group into one bucket until an engineer asks which gate is responsible for which failure. The labels all contain “AI” or “code,” but their evidentiary value is different.

These layers are complementary. The mistake is to use a positive result from one layer as a substitute for evidence another layer alone can provide.

The three-step rollout story: September 10, September 16, October 6

GitHub first made the rollout programmable. On September 10 it introduced REST APIs in public preview that let administrators manage AI Scan enablement for organizations and repositories. Organization-level settings can allow or disable the feature; repository settings do not override an organization-wide disablement.

On September 16 GitHub removed an earlier prerequisite: CodeQL default setup no longer needed to be configured before AI Scan could run. Code scanning and the AI Scan feature still needed to be enabled under applicable policies.

On October 6 the organization got the missing management view: a way to inspect its effective enabled/not-enabled status across the fleet and export it.

That progression matters. First an organization can configure the control, then apply it more broadly, then measure its deployment. None of those three steps is equivalent to measuring detection precision, recall, or security outcomes.

A security-coverage dashboard tells you where a control is present. Release assurance asks whether the specific change deserves to run.

What AI Scan still does not cover

GitHub’s documentation matters more than broad AI-security marketing because it defines the actual boundary. The documented limitations include:

• AI Scan operates on pull requests, not as a full-repository scanner.
• AI Scan findings cannot currently be used in rulesets as an enforceable merge requirement.
• It does not run for pull requests originating from forks or those created by Dependabot.
• Its availability depends on the relevant GitHub security entitlement and enablement policy; public-preview and environment restrictions must be checked before assuming a setting is usable.

These limits do not make AI Scan useless. They tell you where it should sit in the delivery pipeline. A useful automated finding can save a developer time, but a missing finding has to be interpreted in the context of the scanner’s actual scope.

How to audit adoption without confusing it with protection

1. Open the Security overview Coverage view. Confirm that you have the appropriate organization or enterprise visibility.
2. Filter for effective AI Scan status. Use code-scanning-ai-scan-pr-scan:not-enabled to build an exception list.
3. Distinguish deliberate opt-outs from ineligible repositories. The status alone may not explain the cause; check ownership, enterprise policy, and prerequisites.
4. Export the coverage CSV. Include owner, repository importance, and a review date in the operational follow-up.
5. Check actual pull-request workflows. Confirm the feature is producing the expected review signal on eligible changes rather than treating a setting as a completed scan.
6. Retain independent release gates. Keep CodeQL, testing, dependency/security checks and an accountable human decision where your risk model requires them.
7. Watch what happens after deployment. A safe review process still needs monitoring of production behavior.

Why the exact revision matters after the coverage metric turns green

Picture a small team shipping a payment-flow change. AI Scan is enabled. CodeQL runs. The pull request gets a Copilot review. Those are good controls. The team also needs to know which commit received those results, whether the fix changed the code again, and which version it actually released.

If evidence gets detached from the source revision, a dashboard can look reassuring while the shipped change remains ambiguous. A fix suggested after the initial scan should be reviewed as a new change. A passing test for commit A does not automatically cover commit B.

This is where Codie QC Guard has a different, complementary role. Its GitHub-connected advisory reviews are tied to a selected branch and exact source revision. Its nine guard areas—Business Logic, Architecture, Security, Performance, Compliance Controls, Quality, Testing, Deployment Readiness and Analysis Integrity—keep the question of evidence explicit. QC Guard does not replace GitHub AI Scan or CodeQL, and its advisory report is not a compliance certificate or an artifact-signing attestation.

QC Guard also keeps remediation and merge/deploy decisions under human control. Separately configured runtime monitoring can surface production errors, affected users, slow requests, Web Vitals and release context. Those capabilities answer different questions, so treat them as a sequence rather than a tool comparison contest.

The better question for engineering leaders

“How many repositories have AI Scan enabled?” is now easier to answer. Ask it. Use the export. Close avoidable coverage gaps.

Then ask the harder question: when a specific revision is about to merge, what independent evidence supports that decision, which caveats remain, and how will we know if the released version fails users?

A mature security process needs both answers. Only the second helps turn a configuration metric into an accountable release decision.

Frequently asked questions

Sources and references

• GitHub Changelog — AI Scan enablement status, October 6, 2026
• GitHub Docs — AI Scan for pull requests: behavior and limits
• GitHub Docs — Assessing adoption of security features
• GitHub Changelog — CodeQL default setup no longer required, September 16
• GitHub Changelog — AI Scan REST APIs, September 10
• Codie — QC Guard product documentation

Publishing note: Canonical URLs are suggestions until publication. Review official image usage guidance and localize visuals in the CMS.