Start an AI Scan adoption review with a list of repositories and a clear question: which repositories in this list currently show the feature as enabled? Keep evidence of actual pull-request scanning in a separate column. That small distinction prevents an adoption report from becoming an unsupported security assurance.
GitHub's October 6, 2026 update adds AI Scan for pull requests status to Security overview: summary counts, individual repository rows, filters and a CSV field. This guide turns that visibility into an original, read-only review worksheet. Documentation was checked October 7, 2026 (KST); no organization was audited or scan triggered for this article.
Fix the inventory before counting
Write the review boundary before opening a status filter. Otherwise, it is easy to compare one team's active repositories today with the whole organization's repositories next week and call the difference progress.
- Included: exact organizations, teams and repository names.
- Excluded: the agreed treatment of archived repositories, experiments and repositories outside the responsible team's scope.
- Observed by: reviewer, role, time and any notice that results are restricted.
- Inventory reference: an already authorized repository list against which the export can be reconciled.
GitHub's permissions matrix gives organization owners and security managers organization-wide visibility. Members with repository admin access can use Coverage for those repositories; write-only access does not grant that view. Enterprise visibility follows the organizations where the viewer is an owner or security manager. Member views can be restricted to the 3,000 most recently updated repositories, with a notice.
If a repository is missing, record it as unobserved until you establish why. Do not silently add it to the disabled count. Ask an authorized owner to supply the missing observation rather than creating credentials or expanding access simply to finish a spreadsheet.
Capture a baseline, then inspect each status
Open the organization's or enterprise's Security and quality → Coverage view. GitHub's adoption guide explains that filtering changes both the repository list and its summary. Preserve your inventory filters, but remove AI Scan status filters when taking the full in-scope baseline.
The new status filters are:
code-scanning-ai-scan-pr-scan:enabledcode-scanning-ai-scan-pr-scan:not-enabled
Record the exact filter string and export time with each file. The CSV field is Code Scanning AI Scan for pull requests; preserve its enabled and not-enabled values rather than rewriting them as “safe” and “unsafe.”
The export documentation says CSV files reflect the applied filters. Use Export CSV beside the search bar and retain the original file before adding your own analysis columns. Its Teams field lists at most 20 teams with write access per repository, so confirm the responsible owner separately.
Keep exports in an approved internal location. Repository names and security settings can be operationally sensitive; an adoption exercise is not a reason to upload the file to a public converter or paste it into an unrelated service.
Keep enablement and execution separate
In the adoption guide, enabled means the effective result after enterprise policy, organization configuration, prerequisites and repository opt-out have been applied. Not enabled can include ineligible repositories; Coverage does not identify the cause.
Current AI Scan documentation describes a public-preview feature that runs on eligible pull requests with qualifying changes when code scanning and effective AI Scan enablement are present. It does not require CodeQL default setup or a successful CodeQL analysis. Findings appear on pull requests, are advisory and cannot enforce merge requirements. Full-repository scans, fork pull requests and Dependabot-created pull requests are outside its documented coverage.
For this worksheet, the practical consequence is to use two independent fields:
- Configuration observation: the exact Coverage status and when it was read.
- Execution observation: an existing pull-request link and what you could actually verify there, or “not checked.”
An empty findings list does not tell you whether an eligible analysis completed. Even reviewed findings cannot certify an entire repository as vulnerability-free. Write a narrower statement when the evidence is narrower.
Make an evidence row, not a guessed diagnosis
Copy this worksheet structure into your own approved document. These are proposed review fields, not additional GitHub status values.
| Field | What belongs there |
|---|---|
| Repository and scope | Canonical repository URL, inventory reference and inclusion reason |
| Snapshot | Timestamp, reviewer role, exact filter and original export filename |
| Observed status | GitHub's unchanged CSV value, or unobserved if absent |
| Explanation | Confirmed reason and evidence link, or unresolved |
| Existing PR evidence | Link, relevant commit and precise observation, or not checked |
| Follow-through | Confirmed responsible owner, proposed action and review date |
For a not-enabled row, inspect only settings and policy records you are already allowed to read. Possible questions include whether policy permits the feature, whether organization settings and repository prerequisites apply, and whether a repository opted out. Treat these as investigation prompts. If you cannot establish the reason, keep “unresolved” and name the person who can answer.
For example, a fictional repository called example/billing-tools shows not-enabled in the export. The reviewer can see its row but cannot inspect enterprise policy. A useful result is “reason unresolved; enterprise policy owner to confirm.” Writing “blocked by policy” would convert a missing observation into an invented diagnosis.
Use a denominator you can explain
Suppose a fictional review inventory contains ten repositories. Eight appear in the authorized export: five enabled and three not-enabled. Two inventory items remain unobserved.
- Observed enablement: five of eight exported repositories, or 62.5%.
- Inventory visibility: eight of ten intended repositories observed.
- Still unknown: the two missing statuses and any unverified eligibility among the observed rows.
This arithmetic is an illustrative reporting example, not measured adoption. Do not label 62.5% “eligible coverage” unless eligibility has been established separately. Counting only enabled rows in the denominator would produce a tidy but meaningless 100%.
A summary suitable for that example is: “Five of eight observed repositories show AI Scan enabled. Two planned repositories were not observed. Reasons for not-enabled rows are being reviewed.” It says what the snapshot supports without hiding its gaps.
Close the review before changing settings
Finish with an owner and proposed next step for each unresolved row. Enabling a feature is a separate decision: the current AI Scan documentation requires Advanced Security and Copilot licenses during preview, and use consumes AI credits. Do not trigger a test pull request or change policy merely to make an adoption report look complete.
After a separately approved change, repeat the same inventory and filters. Compare matching repository identities, and list additions, removals or visibility changes separately. Preserve both snapshots. A status change can then be traced to a particular repository instead of inferred from a moving total.
The finished deliverable is small: one original export, one scope note, an evidence row for each repository and a short unresolved-items list. Keep scan execution, finding review and broader security assurance attached to their own evidence.