GitHub AI Scan status: filters and the coverage CSV explained

The status answers whether AI Scan is effectively enabled

GitHub Security overview lets you inspect enablement of AI Scan for pull requests. A pull request proposes merging a set of code changes into a repository. Security coverage is the view that shows which repositories have adopted particular security capabilities.

GitHub added this visibility in its October 6, 2026 announcement: summary counts show repositories with the feature enabled or not enabled, while the repository list shows individual status. This guide was published on November 13 using the verified announcement and current official coverage documentation; the announcement is not a new release on that date.

Enabled reflects effective configuration after enterprise policy, organization configuration, prerequisites and repository opt-out are applied. It does not establish that a particular pull request has been analyzed or that the code has no security issues. Execution and findings require separate evidence.

Where to look and who can access the view

The documentation lists write access to repositories in the organization as the access requirement for organization views. For enterprise views, it lists organization owners and security managers. These are viewing requirements; they do not establish permission to change every enterprise policy or enable the feature for every repository.

For an organization, open its main page, select Security and quality, then choose Coverage in the sidebar. Confirm the organization, teams and repository scope before reading counts or individual statuses.

For the enterprise view, navigate to GitHub Enterprise Cloud, open the enterprise you want to inspect, and select Coverage under Security and quality. This guide uses Enterprise Cloud documentation; do not assume the same path applies to GitHub Enterprise Server.

The two reviewed sources do not provide a complete AI Scan plan-eligibility matrix, country availability list, specific pricing or prerequisite checklist. Access to the coverage view or a displayed repository row does not establish that all usage conditions are met. Check the relevant product rules separately before enabling anything.

Filter repositories and check the CSV column

To show repositories where the feature is effectively enabled, enter code-scanning-ai-scan-pr-scan:enabled in the search box. To assemble a follow-up list, use code-scanning-ai-scan-pr-scan:not-enabled. Preserve the values and hyphens exactly rather than turning a natural-language interface label into a different query.

You can also narrow the view using the enabled or not-enabled summary counts and the Teams dropdown. The documentation says the list and displayed metrics update with the current selection, so record the organization, teams and filters alongside any count.

In the GitHub coverage CSV, the column is Code Scanning AI Scan for pull requests, with enabled or not-enabled values. The documentation supports downloading data displayed in Security coverage. This guide does not invent an export-button location that was not verified.

When handing the list to colleagues, retain the export time, viewing scope and original status values, then record who will investigate. This is a suggested workflow, not an automatic GitHub eligibility diagnosis. The CSV does not explain each reason for a not-enabled status.

Why not enabled does not automatically mean a configuration fault

The current official documentation explicitly says not enabled can include repositories that are ineligible for AI Scan, and Security overview does not distinguish the reason. That column alone is not a reason to ask every repository owner to repeatedly toggle the feature.

Have the appropriate owners check the repository’s enterprise policy, organization configuration, applicable prerequisites and opt-out setting separately. Coverage gives the effective status; identifying the cause still requires the relevant configuration and eligibility rules. This guide does not fill unknown prerequisites with guessed activation steps.

For example, suppose a team filters out ten repositories that are not enabled. Those are ten items to classify, not necessarily ten immediately fixable faults. They also provide no scan-success rate. This is a hypothetical example; no real organization operation was performed.

Keep adoption separate from evidence that a scan completed

Record two questions separately: is AI Scan currently effectively enabled for this repository, and does the particular pull request have an actual execution record, output or finding? Coverage can help answer the first question. The enabled field cannot answer the second.

The same official guide defines another metric, Pull request alerts, as enabled only after code scanning has analyzed at least one pull request since alerts were enabled. That is the definition of a separate metric, not evidence that AI Scan has run on every pull request.

A handoff list can record repository, observation time, coverage status and responsible owner. For a particular pull request, add the actual execution evidence. This connects adoption work with specific scan outcomes without treating no alerts, not enabled or enabled as a security guarantee.