GitHub now shows AI Scan for pull requests enablement in the security overview coverage view. The October 6 changelog update adds organization and enterprise counts, per-repository status, filters, and a CSV column for the feature.
This is useful because an AI security feature is easy to enable in one repository and hard to govern across hundreds. The coverage view gives platform and security teams a place to answer a basic question: which repositories are protected right now, and which ones need a decision?
Where to find the status
For an organization, open the organization page, choose Security and quality, then open Coverage. For an enterprise, open the enterprise Security and quality view and choose Coverage. The GitHub documentation lists the access requirements and the same path for organization and enterprise views.
Read enabled and not enabled correctly
The status is effective enablement, not just a single repository toggle. GitHub says `enabled` reflects enterprise policy, organization configuration, prerequisites, and repository opt-out. That makes it the right value for measuring the current result of your policy, but not necessarily the right value for explaining why a repository is missing coverage.
- `enabled` means the feature is effective for that repository after the applicable controls are evaluated.
- `not enabled` can include repositories that are not eligible for AI Scan. The coverage view does not distinguish every reason.
- An enabled count is a coverage signal, not proof that every pull request has already been analyzed.
Use the coverage filters for a working queue
The new coverage view supports two search filters: `code-scanning-ai-scan-pr-scan:enabled` and `code-scanning-ai-scan-pr-scan:not-enabled`. Use them to turn a dashboard into a short, reviewable queue.
- Start with `not-enabled` and group the results by owning team.
- Separate active product repositories from archived, experimental, or ineligible repositories.
- Give each team a reason code such as policy block, missing prerequisite, opt-out, or needs investigation.
- Recheck the same filter after the team changes configuration, rather than relying on a separate spreadsheet.
Export the view for reporting
Coverage CSV exports now include a `Code Scanning AI Scan for pull requests` column with `enabled` and `not-enabled` values. Keep the export as a point-in-time snapshot with the date, organization or enterprise scope, and filters used. Do not treat it as a live inventory after the next policy change.
A safer rollout plan
- Capture a baseline export before changing the organization or enterprise policy.
- Review not-enabled repositories with their owners and classify the reason.
- Enable a small group of representative repositories and verify that pull request results match the team's expectations.
- Use the enabled and not-enabled counts as a weekly adoption measure, but investigate changes before calling them regressions.
- Keep opt-outs explicit and owned by a team with a review date.
Do not confuse coverage with proof of analysis
GitHub's adoption documentation makes a related distinction for pull request alerts: a feature can be reported as enabled only after code scanning has analyzed at least one pull request since alerts were enabled. Use the coverage view to find configuration gaps, then use actual pull request results and code scanning data to confirm the feature is doing useful work.
Check access before promising a report
Organization coverage views require write access to repositories in the organization. Enterprise views are available to organization owners and security managers. If a team cannot see the coverage data, fix the role or delegate the export rather than copying partial results into a manual report.
The new AI Scan status turns enablement from a one-time setting into something teams can measure. Start with the not-enabled queue, classify the reasons, export snapshots for change tracking, and validate real pull request results before declaring the rollout complete.