GitHub Code Scanning for AI Applications: What It Actually Catches

On October 28, 2026, GitHub put code scanning for AI applications into public preview. And it changes what a pull request review means when an agent is in the loop. The new detector flags indirect prompt injection, sensitive information disclosure. And excessive agency directly in pull requests, runs when a PR is created and again after each new commit. And posts mitigation guidance inside the PR so you fix the risk before merge (GitHub changelog). It's live on GitHub.com, runs alongside your existing CodeQL analysis, and requires a GitHub Advanced Security license. That license requirement is the part small operators need to hear, and I'll come back to it.

What the scanner catches, in plain terms

The detector covers three vulnerability classes. Each one maps to a distinct way agent code actually fails.

- Indirect prompt injection (XPIA). Malicious instructions embedded in external content, such as documents, websites, or API responses, influence the model's behavior (GitHub docs). The instructions ride in on data your app was only supposed to read. - Sensitive information disclosure. Paths where data leaves the system through the AI layer in ways nobody intended. - Excessive agency. An AI application or agent holds more functionality, permissions, or autonomy than its job requires, which lets it take unintended or harmful actions.

Under the hood, the detector is static analysis of code patterns and data flows. Concretely, it flags agent code paths where untrusted content can reach a model that has access to tools, data, or business systems. That one sentence is the whole product: find every pipe that carries text you don't control into a model that can do things.

I build agent automations for a living, and that framing is exactly right. The dangerous PR is never the one that looks strange in review. It's the one that quietly adds a fetch, passes the response into context. And the agent on the other end happens to hold a production credential.

Why prompt injection earned its own scanner

GitHub states the priority flatly: indirect prompt injection is the top risk in the OWASP Top 10 for LLM Applications (changelog). Traditional static analysis was built for a world where input goes into a query or a buffer. Injection into a model is different, because the input becomes instructions and the model can't reliably tell the difference.

The blast radius description is the part worth memorizing.

If an agent has access to tools, data, or business systems, hidden instructions in external content can manipulate its behavior or trigger unintended actions.

Read that as a compound risk: untrusted text multiplied by privileged access. Either factor alone is a bug.

Together they're a remote-control hole.

That's why excessive agency sits in the same detector as prompt injection. They're the same failure measured from two ends.

The injection is how an attacker steers; the over-permissioned agent is why the steering matters.

The honest limits: it's static, and it's gated

Two catches, and I'd rather state them than have you discover them.

First, the findings come from static analysis of code patterns and data flows.

Static analysis sees the pipe, not the water.

It catches the shape of a vulnerable path, which is genuinely useful. But it can't observe what a hostile document does to your agent at runtime. Treat this detector as a seatbelt, not a chauffeur. GitHub positions it the same way, running alongside your existing CodeQL analysis rather than replacing it.

Second, the access gate. The feature requires a GitHub Advanced Security license. And the detector only starts scanning pull requests in repositories where code scanning and scans for AI applications are both enabled (changelog). For an enterprise org, that's a config toggle. For a solo operator or small team, Advanced Security is the paid tier. And the builder most likely to wire an agent straight to a live database is often the least likely to hold that license.

The risk curve and the license curve point in opposite directions.

That's a market observation, not a knock on the tool itself.

Your repository is an injection surface too

One angle almost everyone misses: the scanner guards your pull requests, while GitHub's own guidance admits the attack surface is bigger than that.

Agents are prompted from GitHub Issues, files within a repository. And many other places, so the initiator needs a clear picture of all the information guiding it (GitHub blog).

GitHub warns that malicious users can hide directives and trick repository maintainers into running agents with bad instructions. The stated mitigations are instructive: GitHub displays the files from which agent context is generated. And attempts to remove invisible or masked information delivered via Unicode or HTML tags before passing it to the agent. Sit with what that implies. Invisible text inside a file can end up steering an agent. And the defense is showing maintainers the context sources and stripping hidden characters.

So the full picture is two doors. The PR scanner watches the code path, meaning how untrusted content flows into your model. The context hygiene guidance covers the conversation path, meaning what your agent reads before it acts. You need both, since an attacker picks whichever door you left open.

What to do this week

If you hold a GitHub Advanced Security license, enable code scanning and scans for AI applications on every repository where an agent touches external content.

The detector does nothing until it's turned on at both levels. And the feature is new enough that most orgs haven't flipped the switch.

If you don't hold the license, the manual version costs an afternoon. List every source of untrusted content that reaches your models: documents, websites, API responses, GitHub Issues, files sitting in your repos. Then list what each model can do at the moment it reads that content: tools, data, business systems. Wherever those two lists intersect, you've found the exact condition the new scanner flags. And you found it for free.

Then cut permissions. Excessive agency is the multiplier on every injection.

A poisoned agent that can only draft text is a nuisance; a poisoned agent with write access to production is an incident.

Your move: pick the one agent you run with the most access. And trace every piece of untrusted content that reaches it.

That path is the vulnerability GitHub built an entire product to catch. Audit it before someone else exercises it.