GitHub made AI Scan for pull requests generally available on October 15, 2026.
The feature runs alongside code scanning and can identify security problems in pull request changes, including areas that CodeQL does not currently cover such as PHP, Shell and Bash, Terraform configuration, Dockerfiles, JSP for Java, Blazor for C#, and others.
The important detail is how GitHub treats the result. AI Scan findings are advisory. They appear inside the pull request with an explanation of the possible security risk and can include a suggested fix, but they do not fail the code-scanning check and cannot block the pull request through ruleset requirements.
That makes the developer review process especially important. An AI-generated security finding gives the reviewer a code path worth investigating. The next step is understanding whether the finding represents a genuine vulnerability in the application and whether the proposed correction is appropriate for the codebase.
What GitHub AI Scan adds to a pull request
When AI Scan is enabled, it runs automatically on eligible pull requests and places its findings alongside CodeQL results in the Conversation and Files changed views.
GitHub marks these findings with an AI indicator so developers can distinguish them from CodeQL alerts. A finding can provide the code associated with the problem, an explanation of the security concern, and a suggested autofix when one is available.
This gives reviewers another source of security information while they are already reviewing a change. The feature is particularly relevant when the pull request contains code or configuration outside CodeQL's current coverage.
GitHub also makes an important limitation explicit: AI Scan does not run on pull requests from forks or pull requests opened by Dependabot.
Start by understanding the exact security claim
A finding is much easier to review when the concern is translated into a specific statement.
Instead of stopping at:
AI Scan says this is insecure.
Try to establish:
Which input can reach which sensitive operation, and under what conditions?
For example, a finding might suggest that user-controlled input reaches a shell command. The review should establish where that input originates, how it is transformed, whether validation exists earlier in the request path, and whether an attacker can actually influence the value that reaches the command.
The same approach works for infrastructure configuration, file access, injection risks, unsafe redirects, credential handling, and other findings.
The first job is understanding the path that creates the risk.
Check whether the code path is actually reachable
Static analysis and AI-assisted analysis work from the code available to them. The application has additional context around how that code is reached and used.
A suspicious function may exist while external input never reaches it. A route may be protected by an authorization check elsewhere. A configuration may only apply in a development environment. A value may already have been constrained before it reaches the highlighted line.
Those details determine how the finding should be evaluated.
A practical review can ask:
- Where does the relevant value originate?
- Can an external user influence it?
- What validation or authorization happens before this line?
- Which environment can execute this path?
- What would happen if the value were malicious?
The answer should come from the application flow rather than from the warning text alone.
Review the suggested fix as normal production code
GitHub AI Scan can provide an autofix suggestion. That can shorten the path from finding to remediation, especially when the problem is localised.
The suggested change still deserves a normal code review.
A security fix can close one path while changing application behaviour somewhere else. Escaping input can alter valid values. Tightening a permission can break a legitimate workflow. Replacing one API can change error handling or performance characteristics.
Review the proposed fix against the same questions used for any other production change:
- Does it address the reason the finding exists?
- Does it preserve intended behaviour?
- Does it introduce another path around the protection?
- Are related call sites affected?
- Is there already a shared validation or security utility that should be used instead?
The fix should fit the application and its existing behaviour.
Add a test that represents the failure
When the finding is valid, the strongest fix usually leaves behind a test that explains the expected behaviour.
Suppose the issue involves unsafe input reaching a command. A useful test might verify that a malicious value is rejected or encoded before execution.
If the issue involves authorization, the test can confirm that a user without the required permission cannot reach the protected operation.
If the finding concerns an infrastructure setting, the project may be able to add a configuration check to CI.
This gives the team something more durable than resolving the current alert. The same weakness is less likely to return silently in a later change.
A dismissed finding should still have a reason
Some AI findings will turn out to be false positives, unreachable paths, accepted risks, or concerns already controlled somewhere else.
That is normal for security tooling.
The useful part of dismissal is recording why.
A short reason such as:
Input is restricted to an internal enum before this function is called. Added a test covering the allowed values.
is much more useful than:
False positive.
The explanation helps the next reviewer understand the decision and makes future reassessment easier if the surrounding code changes.
AI Scan and agentic autofix are separate workflows
GitHub also made agentic autofix for code-scanning alerts generally available on October 15.
The two features serve different parts of the security workflow.
AI Scan works during pull request review and produces advisory findings.
Agentic autofix works on code-scanning alerts on the repository's default branch. A developer can assign an alert to Copilot, which explores related files, prepares a fix, reruns CodeQL, and opens a draft pull request for review.
GitHub currently states that alerts detected only on pull requests or other branches cannot be assigned to agentic autofix.
That creates two related workflows.
During a pull request
AI Scan can add another security signal while the change is being reviewed.
The developer verifies the finding, evaluates any suggested fix, tests the result, and then decides whether the change is ready.
For an existing default-branch alert
Agentic autofix can investigate the codebase, prepare a fix, validate it with CodeQL, and open a draft pull request that still goes through developer review.
Keeping the distinction clear prevents teams from assuming every AI Scan finding can simply be handed to an autonomous fixer.
A practical pull request review workflow
A team using AI Scan can keep the process simple.
1. Read the finding
Understand the security behaviour being claimed.
2. Trace the path
Identify where the data comes from and whether an attacker can reach the highlighted code.
3. Decide whether the risk applies
Use application context, permissions, validation, and environment behaviour.
4. Inspect the proposed fix
Treat it like any other code change.
5. Test the failure
Add or run a test that demonstrates the protection.
6. Resolve or dismiss with context
Leave enough explanation for the next person reviewing the code.
This keeps AI Scan in a useful role inside the review process while developers retain responsibility for understanding how the application behaves.
The review still matters
AI security tooling can increase the amount of information arriving during a pull request. The value comes from turning those findings into useful engineering decisions.
A useful finding points the reviewer toward a code path worth investigating. A useful fix survives application context and testing. A useful dismissal explains why the warning does not apply.
GitHub has deliberately made AI Scan findings advisory rather than merge-blocking. That fits a workflow where the final decision still depends on understanding the software, tracing the relevant behaviour, and verifying the change before it reaches production.
Sources
GitHub Changelog: AI Scan for pull requests generally available, October 15, 2026
https://github.blog/changelog/2026-10-15-ai-scan-for-pull-requests-generally-available/
GitHub Changelog: Agentic autofix for code scanning alerts general availability, October 15, 2026
Top comments (0)