GitHub code scanning can now place AI-powered security detections directly on pull requests. GitHub announced the feature in public preview on July 14, 2026, positioning it as additional coverage for languages and frameworks that CodeQL does not currently analyze with built-in queries. The practical value is earlier visibility inside the pull-request workflow, but the new signal needs a deliberate review process.
GitHub documents the availability, prerequisites, labels, billing model, and non-blocking behavior described below. This article provides an inferred defensive workflow for reviewers. CodeRiskTools did not independently test GitHub’s hosted AI detection engine, measure its accuracy, or compare its coverage with CodeQL. An AI-labelled finding is evidence to investigate, not proof that a change is vulnerable; a clean result is not proof that a change is secure.
What GitHub announced and what it did not promise
According to GitHub’s release note, AI security detections run when a pull request is opened or updated. Results appear as the detection engine returns them, without waiting for every analysis source to complete. AI-generated alerts carry an AI label so reviewers can distinguish them from CodeQL results. GitHub says the feature can extend scanning to languages and frameworks outside CodeQL’s current built-in coverage.
The preview has important boundaries. The findings are informational and do not block a merge. The feature runs on github.com for eligible GitHub Code Security customers, requires CodeQL default setup on the repository, must be allowed by enterprise policy and enabled at organization level, and consumes AI credits when detections run. GitHub also states that a Copilot license is required during the preview. Verify current plan and policy details in your own account because preview terms can change.
| Signal or prerequisite | Documented meaning | Reviewer action |
|---|---|---|
| AI label | The alert came from GitHub’s AI detection engine rather than a CodeQL result. | Preserve the label and evaluate the evidence instead of assuming CodeQL semantics. |
| Informational result | The finding does not automatically block the pull request. | Add an explicit branch rule or human decision gate if unresolved findings should stop a merge. |
| CodeQL default setup | It is required even though CodeQL is not performing the AI analysis. | Confirm default setup is enabled and completed on the relevant repository. |
| AI credits | Credits are consumed when detections run during the preview. | Monitor usage and define who may enable the feature across repositories. |
Preflight: verify that the detection lane is actually active
Before relying on the signal, record the repository, organization, enterprise, pull-request head SHA, and time of the check. Confirm the enterprise policy allows AI security detections, organization-level enablement is active, CodeQL default setup is enabled, and the user or organization meets the preview’s licensing requirements. If any prerequisite is missing, mark the result not measured rather than “no findings.”
Also confirm the pull request was opened or updated after enablement. Because results can arrive independently, a reviewer should not infer that an early empty panel is the final result. Record which analysis sources completed, which remain in progress, and which failed. That distinction prevents a scanner timeout, disabled policy, or exhausted entitlement from being misreported as a clean scan.
A seven-step triage workflow for an AI-labelled finding
- Pin the exact change. Record the pull-request URL and head SHA. Re-check after every force-push or update so the finding and fix refer to the same code.
- Identify the engine. Confirm the AI label and do not describe the alert as a CodeQL result. Preserve its severity, confidence, location, message, and any trace shown.
- Read the surrounding diff. Inspect the complete function, callers, configuration, data sources, authorization checks, and changed dependencies. A single highlighted line rarely establishes exploitability.
- Map attacker control and impact. Determine who can influence the input, which trust boundary it crosses, and what data or action becomes reachable. Include stored input, webhooks, generated files, and tenant configuration.
- Reproduce safely. Build a minimal negative test with synthetic data. Do not place real credentials, customer records, or production payloads in prompts, comments, screenshots, or tickets.
- Repair the boundary. Prefer server-side authorization, strict parsing, safe APIs, output encoding, path containment, and least privilege over wording-only mitigations. Review the repair as a new change.
- Re-run and decide. Update the pull request, wait for the relevant analysis lanes, run targeted tests, and have an accountable reviewer choose fix, documented dismissal, or block.
How to handle disagreement between AI and CodeQL results
Different results are not automatically contradictory. GitHub presents AI detections as broader coverage for some languages and frameworks, while CodeQL applies defined queries and data-flow models to supported code. If an AI alert appears where CodeQL is silent, first check whether CodeQL supports the language, extracted the files, and includes a relevant query. Then evaluate the AI alert on its own evidence.
If CodeQL reports a path and the AI engine does not, keep the CodeQL finding in scope. If both report similar issues, do not count two alerts as two vulnerabilities until you reconcile location, source, sink, and root cause. Deduplicate by the underlying security boundary, but retain both engine records so future audits can reproduce the decision.
Dismissal requires evidence, not a confidence shortcut
GitHub’s responsible-use guidance for security and quality AI features describes limitations such as false positives and missed vulnerabilities. A high-confidence label still needs review, while a lower-confidence alert should not be dismissed solely because of the score. A defensible dismissal identifies a concrete barrier: a closed allowlist, framework-enforced encoding, unreachable path, immutable trusted source, or authorization check that is both present and tested.
Link the dismissal to the exact commit and a regression test. Avoid explanations such as “AI noise,” “internal only,” or “scanner says safe.” Internal inputs can still be attacker-influenced, and a generic label gives the next reviewer no way to validate the conclusion.
Pull-request evidence checklist
- Repository, pull-request number, and reviewed head SHA are recorded.
- Enterprise policy, organization enablement, CodeQL default setup, and licensing prerequisites were checked.
- Every analysis lane is classified as completed, in progress, failed, disabled, or not applicable.
- AI-labelled and CodeQL alerts are attributed to the correct engine.
- The reviewer inspected relevant code beyond the highlighted line.
- Attacker control, trust boundary, impact, and existing mitigations are documented.
- A synthetic negative test covers the suspected path without exposing sensitive data.
- The repair or dismissal refers to the current commit and concrete evidence.
- Secret scanning, dependency review, tests, and human approval remain separate gates.
- The final merge decision names an accountable reviewer and any residual risk.
FAQ
Do AI security detections block a pull request?
No. GitHub’s July 14 release note says these preview findings are informational and will not block merges. Teams that require resolution must implement an explicit policy or review gate and verify its behavior.
Are these alerts generated by CodeQL?
No. GitHub says its AI detection engine performs the analysis, although CodeQL default setup is a prerequisite. The AI label is intended to distinguish these findings from CodeQL results.
Does a clean result cover unsupported languages completely?
No. The vendor describes broader coverage, not complete coverage or a security guarantee. Record which files and analysis lanes were evaluated, then keep tests, dependency checks, secret scanning, and manual review in the merge decision.
Should teams enable the preview everywhere immediately?
That is a governance decision. Review repository sensitivity, preview status, data-handling policy, expected signal, Copilot licensing, AI-credit usage, and the team’s capacity to triage findings before broad enablement.
Official sources and a practical next step
- GitHub Changelog: AI security detections on pull requests — vendor documentation for preview behavior, prerequisites, labels, availability, and billing.
- GitHub Docs: responsible use of security and quality AI features — vendor documentation for intended use, limitations, and human oversight.
- GitHub Docs: resolving code scanning alerts — official workflow guidance for fixing and dismissing code-scanning alerts.
For adjacent controls, use the CodeRiskTools guides to design CI gates for AI-generated code, scan changes for exposed secrets, and review AI-generated code before merge. The single comparison hub explains scope differences without turning them into security guarantees.
Turn the workflow into a repeatable gate
The retired 5-Point AI Code Review Checklist is no longer available through a public checkout; existing buyers retain access.
