GitHub's AI Scan reads the files CodeQL skips, but it can't block a merge and a spent budget looks like a clean scan

Ask a coding agent to containerise a service, add a bucket and ship a deploy script, and most of what comes back isn’t C#, TypeScript or Python. It’s a Dockerfile, some Terraform and a Bash script. Those are the files CodeQL doesn’t analyse, and GitHub now has something that does look at them in pull requests: AI Scan, generally available since 15 October 2026.

There are three things to know before you lean on it. It’s advisory, so it can’t gate a merge. It runs only on pull requests, so nothing sweeps the default branch. And if its budget runs out, the result is no findings at all, which looks exactly like a clean scan.

What it covers

According to the GitHub changelog , AI Scan finds vulnerabilities in the changes in a pull request, for languages and frameworks CodeQL doesn’t currently support. The named examples are PHP, Shell/Bash, Terraform (HCL), Dockerfiles, JSP for Java and Blazor for C#.

The documentation says it analyses the pull request code without a build system, and can use code search for extra context. That’s the point of it: there’s no extra pipeline to wire up. The finding categories are string injection, weak cryptography, broken access control, sensitive data exposure, security misconfiguration, authentication failures, data integrity failures, SSRF and supply chain risks.

Results show up on the Conversation and Files changed tabs next to CodeQL alerts, marked with an “AI” label. Each one describes the issue and its risk, most carry a suggested fix, and Copilot Autofix may offer a code change. It runs when the pull request opens and again after each new commit, and it still runs if CodeQL fails or is waiting.

You don’t need a Copilot licence. Public repositories can use it. Private and internal repositories owned by an organisation need GitHub Code Security or GitHub Advanced Security.

Why agent-written changes are the target

Infrastructure and glue files are where agents are most casually trusted. A model asked to “make it deployable” produces a plausible Dockerfile in seconds, and a reviewer skims it because it looks like every other Dockerfile. Here’s the kind of change that deserves a second look:

resource "aws_security_group_rule" "api_ingress" {
  type              = "ingress"
  from_port         = 8080
  to_port           = 8080
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.api.id
}

#!/usr/bin/env bash
set -e
curl -fsSL "$INSTALL_URL" | sh
docker build -t "api:$TAG" .

Both are illustrative, written for this article, and nothing here claims AI Scan flags either one. The first opens a port to the whole internet, which is a security misconfiguration. The second pipes a remote script into a shell and the image tag comes straight from an unvalidated variable. Neither would get a CodeQL alert, because CodeQL has no query pack for them. A human skimming a 40-file agent diff can miss both.

That’s the gap AI Scan fills, and the changelog’s own framing is that it complements CodeQL rather than replacing it.

It’s advisory, and that matters for your branch rules

GitHub states that AI Scan findings are advisory. They don’t fail the code scanning check, and the documentation says they can’t be used in rulesets to block merges, noting that this isn’t yet supported.

If your branch protection requires code scanning results to pass, AI Scan doesn’t change when that check goes green. A pull request with an AI-flagged open port will still show a passing check and an enabled merge button. Treat the findings as review comments that someone has to read, not as a gate.

A practical consequence for teams that merge agent pull requests quickly: the finding only helps if a person reads the Files changed tab. If your process is “CI green, merge”, AI Scan adds nothing to it. Put a line in the pull request template or the review checklist that says to read the AI-labelled findings, and say who resolves them.

It only sees the diff

The documentation is explicit that it’s pull request analysis only. Full repository scans aren’t supported, findings appear on pull requests and not in the security view’s backlog, and nothing is described for the default branch.

Two groups of pull requests are skipped entirely: ones from forks and ones created by Dependabot. And the change has to touch a supported language, so a pull request that only edits C# produces no AI Scan output.

The consequence is that existing Terraform and Dockerfiles in your repository get no coverage unless someone changes them. A repo full of old shell scripts stays unscanned until each is edited. If you want a baseline, this isn’t it.

One more limit, relevant to anyone who has invested in agent instruction files: the documentation says AI Scan doesn’t use custom instruction files such as copilot-instructions.md or CLAUDE.md. Your “never open 0.0.0.0/0” rule in CLAUDE.md guides the agent that writes the change. It does nothing to the scanner that checks it.

The budget trap

AI Scan bills through Code Security AI Credits, separate from active-committer licensing. Charges start only when a qualifying pull request is scanned. Included credits from a Copilot entitlement are used first, and after that usage is metered under whatever budgets apply.

Here’s the line worth reading twice. According to the documentation, if a hard budget leaves no credits, AI Scan produces no findings, and scanning resumes when an admin raises the budget or a new billing cycle starts. There’s no description of a failed check or a banner on the pull request in that case. The visible result is an absence of AI-labelled findings, which is also what a clean pull request looks like.

An agent-heavy team opens a lot of pull requests, and every push to each one is another scan. That’s the usage pattern most likely to hit a hard budget late in a billing cycle. If you set a SKU-level budget for Code Security AI Credits, which the changelog says you can, decide whether it’s a hard stop, and put a calendar reminder next to it.

Related: the documentation warns that enabling the organisation setting can consume credits before repository admins opt out. Enterprise owners get a “Not allowed” default that they have to change, and allowing it at enterprise level doesn’t switch it on. Organisation owners and security managers do that, and repository admins can opt out but can’t opt in against the organisation’s setting. The REST API manages an ai-scan setting for both organisations and repositories, if you’d rather script the rollout than click through it.

How to check it’s working

GitHub has put metrics in security overview, in public preview: findings generated and resolved, remediation rate, how often developers applied the autofix, and an AI Scan tab on the “Code scanning on pull requests” report. The changelog notes it isn’t available on GitHub Enterprise Server. The Coverage view shows which repositories have it enabled.

Those numbers answer the question the pull request page can’t. A flat line at zero for a team that merges twenty pull requests a day is a signal to look at the budget, not a sign of good code.

Try this week

Pick one repository with a Dockerfile, enable AI Scan there, and open a throwaway pull request that changes it with a deliberate problem, such as running the container as root or an ADD from a remote URL. Check that a finding appears with the AI label. Then check the budget settings and the security overview tab, and write down who reads the findings, because nothing will make anyone do it.