GitHub AI App Scanning: Setup, XPIA and Limits
GitHub's AI-application scanner is in preview. Learn what prompt-injection risks it detects, how to enable it, billing, and what it cannot scan.
GitHub introduced code scanning for AI applications in public preview on October 28, 2026. The new detector reviews pull-request changes for security risks specific to AI applications and agents. The key detail is narrower than the launch headline: the current preview detects indirect prompt injection (XPIA), not every category of AI-agent vulnerability mentioned in the announcement.
For teams shipping assistants that read documents, websites or issue comments and then call tools, this adds an earlier place to catch dangerous trust-boundary patterns. It is not a general security certification, a repository-wide audit or a replacement for existing code review.
What launched—and what is actually covered
GitHub's detector uses an LLM-based approach to examine code paths and data flows in eligible pull requests. It looks for cases where instructions in untrusted material could influence an agent with access to tools, data or business systems. GitHub's current documentation says the public preview only detects XPIA vulnerabilities. Although the feature overview also describes sensitive information disclosure and excessive agency, teams should not assume those additional detectors are active today.
As of November 1, 2026: AI applications scanning covers indirect prompt injection in eligible pull requests only. Findings are advisory, and coverage may change during public preview.
Three GitHub scanners solve different problems
Choose the scanner by risk and code scope
| Capability | Current scope |
|---|---|
| AI Scan for repositories | On-demand scan of the default branch for general code vulnerabilities across languages; results enter the code-scanning backlog. |
| AI Scan for pull requests | General security issues in changed code, including selected languages and frameworks outside CodeQL coverage. |
| AI applications scanning | AI-agent/application risks in eligible pull requests; current preview detection is indirect prompt injection only. |
These are separate capabilities with different enablement and billing conditions. GitHub explicitly distinguishes the AI-application detector from CodeQL and from its other AI Scan detectors. A team that already scans a repository backlog should still assess AI-agent data flows in new changes; conversely, enabling the new detector does not retroactively inspect every existing file.
A concrete risk pattern worth reviewing
Imagine a support agent that reads an uploaded troubleshooting document and can create tickets or change account settings. A document is lower-trust input, while those actions require privileged tools. A malicious instruction hidden in the document could try to redirect the agent from summarizing the issue to changing a record. The useful engineering question is whether the application separates retrieved content from trusted instructions and restricts what tools can do. This is a hypothetical example, not a claim that GitHub detects every such exploit.
How teams should roll it out
- Confirm that your organization uses GitHub Enterprise Cloud with GitHub Advanced Security and that the enterprise owner allows AI-powered scanning.
- Have an organization owner enable Scan for AI applications explicitly; do not assume another AI Scan switch turns it on.
- Check that code scanning is enabled for the eligible repository, and review repository-level settings and opt-outs.
- Open a representative pull request touching an AI-agent data flow, then inspect the advisory findings and suggested fixes.
- Validate any suggested remediation with tests and a security reviewer; keep existing CodeQL and branch protections in place.
The scanner runs when an eligible pull request is created and after new commits. Findings appear as comments with an AI-app label and feedback controls. GitHub also generates Copilot Autofix suggestions for these findings independently of the CodeQL Autofix setting. Treat suggestions as review material: a fix that silences a detector still needs to preserve intended permissions and application behavior.
Operational limits and budgeting
- Public preview: behavior and coverage can change; current detection is XPIA only.
- Pull requests only: no full-repository backlog scan for AI-application risks.
- No fork or Dependabot pull-request scans under the current detector rules.
- Advisory comments cannot be enforced as required merge checks through rulesets.
- Requires GitHub Advanced Security and additional AI-credit consumption; no Enterprise Server support in this preview.
The practical rollout is a layered one: use CodeQL and other code-security checks for established vulnerability classes, apply the AI-application detector to agent-specific pull-request changes, and maintain threat modeling for tool permissions, data access and prompt-injection boundaries. Measure useful findings and review time in your own repositories rather than assuming a published accuracy rate or a guaranteed reduction in incidents.
Questions people ask
Does GitHub AI applications scanning detect data leaks and excessive agency today?
Not yet. As of November 1, 2026, GitHub's public-preview documentation says this detector currently identifies indirect prompt injection (XPIA) vulnerabilities in AI agents only. Sensitive information disclosure and excessive agency are described as broader risk categories, not confirmed live detection coverage. Teams should keep separate authorization, secret-handling and security reviews rather than treating this preview as comprehensive AI-agent protection.
If AI Scan is already enabled, do I need to turn on AI applications scanning separately?
Yes. GitHub says the two scanners have separate organization-level enablement, even though they share an enterprise AI Scan policy. An enterprise owner must allow the capability, and an organization owner must enable Scan for AI applications for eligible repositories. The feature is off by default; enabling AI Scan for pull requests does not automatically activate the AI-application detector. Confirm settings before expecting alerts.
Can AI applications scanning block merges or scan pull requests from forks?
No. GitHub describes its findings as advisory pull-request comments, not merge-blocking ruleset checks. The public preview does not scan pull requests from forks or those created by Dependabot, and it does not analyze the existing repository backlog. For protected branches, continue using established code-scanning policies and human review; do not rely on this detector alone as a required merge gate.
What does GitHub AI applications scanning cost, and does it work on Enterprise Server?
It requires GitHub Advanced Security and consumes AI credits in addition to that license, including for eligible public repositories. GitHub lists support for Enterprise Cloud, including data-residency deployments, but not Enterprise Server in the October 2026 preview announcement. The cited documentation does not establish a universal per-scan dollar amount, so review your organization's current credit rates and usage before budgeting.
GitHub AI applications scanning gives security teams a pull-request checkpoint for indirect prompt injection in agent code. Its value is specific, not universal: the October 2026 preview does not yet cover every advertised AI risk, does not scan the full repository and cannot block merges. Enable it deliberately, budget for credits and keep conventional security controls alongside it.
Explore related Make Better resources
- GitHub AI Scan for repositories: setup and costs— Different default-branch scanner
Sources & useful resources
- GitHub: AI applications scanning public preview— Primary announcement October 28, 2026
- GitHub Docs: AI applications scanning for pull requests— Current official coverage, eligibility, setup and billing
- GitHub Docs: About AI Scan— Official distinction among three scanning capabilities