GitHub made AI Scan for pull requests generally available on October 15, 2026. The AI-based scanner runs during pull-request review and is intended to complement CodeQL by looking for vulnerabilities in changes across languages and frameworks that CodeQL does not currently cover.
For QA and automation teams, this is a useful new signal in the PR feedback loop—not a release gate. GitHub says its findings are advisory, do not fail the code-scanning check, and cannot be required by rulesets for merge blocking.
What GitHub AI Scan adds to pull-request testing
According to GitHub, AI Scan can surface issues in pull-request changes for coverage areas including PHP, Shell/Bash, Terraform HCL, Dockerfiles, JSP for Java, and Blazor for C#. Results appear next to CodeQL findings on the pull request’s Conversation and Files changed tabs, marked with an AI indicator. Findings may include a risk explanation and a suggested autofix.
This matters when a QA team owns tests, infrastructure configuration, or test-environment Dockerfiles alongside application code. It can expose a risky change while reviewers still have the exact diff and test evidence in front of them.
Why this matters for QA engineers
- Expand the review oracle: Add AI Scan findings to your PR triage routine, especially for IaC and test-support scripts that sit outside your established CodeQL coverage.
- Keep a human verification step: Treat the finding and suggested autofix as a hypothesis. Reproduce the risk where safe, inspect the changed path, and run focused regression tests before accepting a remediation.
- Measure false positives separately: Log accepted, rejected, and duplicate findings for a short pilot. That gives the team evidence about signal quality instead of assuming every AI finding is actionable.
QA adoption checklist for GitHub AI Scan for pull requests
- Confirm code scanning and the repository’s effective AI Scan setting are enabled.
- Choose a representative repository with relevant change types, such as Dockerfiles, shell test helpers, Terraform, or PHP.
- Open a controlled pull request with a safe, known review scenario; do not introduce exploitable production code just to test the tool.
- Check that findings appear in both expected PR views and are clearly distinguishable from CodeQL alerts.
- For each alert, validate the explanation against the diff, existing tests, and the target environment.
- Run the normal functional, regression, and security checks after applying any suggested autofix.
- Document the outcome: valid, false positive, duplicate, or not applicable. Use those results to tune reviewer guidance.
Important limits to test around
Do not silently treat AI Scan as universal coverage. GitHub states that it does not run on pull requests from forks or on Dependabot-created pull requests. It also cannot block a merge through a ruleset requirement. Build your QA process around those boundaries: preserve existing CodeQL, dependency, secret-scanning, and test gates, and give a reviewer ownership of AI Scan triage.
Availability also differs by repository type. GitHub lists AI Scan for public repositories owned by organizations or personal accounts; private and internal organization repositories require GitHub Code Security or GitHub Advanced Security. It consumes Code Security AI Credits, so a pilot should include billing visibility and an agreed usage budget.
Bottom line
GitHub AI Scan for pull requests is best adopted as another review signal, not as permission to relax existing security or QA gates. Start with a small, measurable pilot; verify real findings in the PR context; and make the tool’s fork, Dependabot, merge-blocking, and billing limits explicit in your release checklist.