GitHub AI Scan for Pull Requests: What Agencies Must Still Review
GitHub AI Scan can surface security findings in pull requests that change languages or frameworks CodeQL does not cover. But it is an advisory signal, not a merge gate, a full-repository audit, or proof that an AI-built application is safe. Agencies should enable it where eligible, triage every finding in context, and keep separate handoff evidence for the gaps it cannot cover.
GitHub made AI Scan for pull requests generally available on October 15, 2026. The practical opportunity is useful: PHP, Shell/Bash, Terraform configuration, Dockerfiles, JSP and Blazor changes can receive findings without adding a separate build configuration. The practical trap is treating a green pull request as a complete security review.
What GitHub AI Scan does
According to GitHub's general-availability announcement, AI Scan complements CodeQL for selected languages and frameworks that CodeQL does not currently cover. When code scanning and the repository's effective AI Scan setting are enabled, it runs on qualifying pull requests and shows labeled findings on the Conversation and Files changed tabs.
GitHub's AI Scan documentation says the engine can flag categories such as injection, weak cryptography, broken access control, sensitive-data exposure, security misconfiguration, authentication failures, unsafe data handling, server-side request forgery and supply-chain risk. Most findings include remediation guidance, and some include a Copilot Autofix suggestion.
That gives a reviewer another useful signal close to the change. It does not transfer responsibility for deciding whether the issue is real, whether the proposed fix preserves the application's behavior, or whether the surrounding system is secure.
The limitations that belong in every handoff
The important limits are explicit in GitHub's documentation:
- Findings are advisory. They do not fail the code scanning check and cannot be required by a ruleset to block a merge.
- AI Scan analyzes pull requests only. It does not create a full-repository backlog in the repository's security view.
- It does not run on pull requests from forks or pull requests created by Dependabot.
- Findings may include false positives, and supported languages and detection categories can change.
- A hard AI-credit budget can prevent new findings until the budget changes or the next billing cycle starts.
These limits change how an agency should describe the control. "AI Scan enabled" is accurate only as a configuration statement. "Every pull request is scanned" may be false because eligibility, source, language coverage, settings and available credits all matter. "Merges are blocked on AI findings" is false under the current product behavior.
Also avoid combining the tools into one green status. CodeQL and AI Scan can run independently and return at different times. A CodeQL analysis failure does not mean AI Scan failed, and an AI Scan finding does not change CodeQL's check result.
Decide whether a repository is eligible
Start with ownership and visibility, because availability differs:
| Repository | AI Scan availability |
|---|---|
| Organization-owned, public | Available without an active-committer license |
| Organization-owned, private or internal | Requires GitHub Code Security or GitHub Advanced Security |
| Personal account, public | Available |
| Personal account, private | Not available |
A GitHub Copilot license is not required. Managed-user personal namespaces are excluded even when code scanning is enabled.
For an organization, an enterprise owner may first need to allow the feature. Organization owners or security managers then enable it for eligible repositories where code scanning is enabled; repository administrators can opt out but cannot opt in when the organization setting is off. For a public repository under a personal account, an administrator controls the repository toggle directly.
Before enabling organization-wide coverage, identify the billing account, review included AI credits and set an intentional budget. GitHub reports AI Scan under the Code Security AI Credits SKU. Treat the budget as part of operational availability, not only finance administration.
Triage an AI finding without rubber-stamping it
Use the finding to start a review, not finish one.
- Confirm the changed path is reachable. Identify the input, trust boundary and execution path. A dangerous-looking string operation in a test fixture is different from one processing a public request.
- Reproduce the risky behavior safely. Prefer a local or isolated test with synthetic data. Do not probe a client's production application or third-party target without authorization.
- Read the full diff and nearby controls. Check validation, authorization, error handling, logging and deployment configuration. The annotated line may not contain the complete control flow.
- Review a suggested fix as untrusted code. Confirm it addresses the cause, preserves expected behavior and adds a focused regression test. An autofix proposal is not approval to merge.
- Record the outcome. Mark the finding fixed, false positive, accepted risk or deferred only with an owner and concise reason. Keep the pull request or issue reference so the client can revisit it.
GitHub's pull-request triage guide explains where annotations and alert details appear. It also notes that resolving an alert conversation can be required through normal branch protection. That is a workflow control around the discussion; it does not turn the AI Scan finding itself into a ruleset-enforced code scanning failure.
If the code was generated or heavily rewritten by an agent, review the surrounding behavior with the same care. Our guide to security-reviewing code you did not write covers trust boundaries, data flow and dependency checks that remain outside a single finding.
Keep a separate merge and handoff checklist
Because AI Scan cannot block a merge directly, use a small human-owned checklist in the pull request template or client handoff record:
- Coverage: Which changed languages and frameworks were eligible for AI Scan and CodeQL?
- Execution: Did the expected analyses actually run for this pull request, or was it a fork, Dependabot change, unsupported path or budget-limited run?
- Findings: What was found, who reviewed it, and what disposition was recorded?
- Required controls: Which tests, approvals and branch protections can actually prevent the merge?
- Out-of-scope review: What full-repository, dependency, secret, configuration, authorization and runtime checks were performed separately?
- Ownership: Who maintains settings, budgets, exceptions and follow-up issues after the agency leaves?
For a client acceptance test, open a non-production pull request in an eligible repository and confirm the expected analysis appears. Record the repository, pull request, revision, time, effective setting and redacted result. Do not create intentionally exploitable production code just to trigger a finding, and do not report the absence of a finding as proof of safety.
This distinction matters for launch reviews. A pull-request tool sees a change, not the entire deployed system. Use the pre-launch security checks for AI-built apps for the broader evidence set, and keep Supabase RLS verification separate from source-scanning status.
Frequently asked questions
Can GitHub AI Scan block a pull request merge?
No. GitHub says AI Scan findings are advisory, do not fail the code scanning check and cannot currently be enforced as ruleset merge requirements. You can still require normal reviews or resolved conversations as separate repository controls.
Does AI Scan replace CodeQL?
No. It complements CodeQL for selected languages and frameworks that CodeQL does not currently cover. The analyses can run independently, and AI Scan findings appear only in pull requests rather than as a full-repository backlog.
Does a clean AI Scan mean the application is secure?
No. A clean result means no finding was reported for that qualifying pull-request analysis. It does not cover skipped pull requests, unsupported code, historical code, deployed configuration, authorization behavior, dependencies, secrets or runtime exposure.
The useful posture is neither to ignore AI Scan nor to overstate it. Turn it on where it fits, make its advisory findings visible to reviewers, and hand the client an honest record of what ran, what was decided and what still needs another control.
Prepared with AI assistance and checked against the linked GitHub primary documentation on October 21, 2026. No client repository or GitHub billing account was tested for this article. The review and handoff steps are editorial recommendations, not a security guarantee.