A script successfully enables AI Scan across a set of repositories. The rollout report turns green. How much code has the rollout analyzed? Possibly none: GitHub’s November 13, 2026 API announcement explicitly says enabling AI Scan for repositories does not start a scan.
AI disclosure: This article was generated with AI assistance from public sources. The rollout report and maintenance exercise below are proposed examples, not reported implementations or security findings from Keith’s projects.
The public preview adds a repository_scan setting to GitHub’s organization and repository AI Scan endpoints. That is useful configuration automation. The operational work begins when a team decides who will run the enabled feature, review its output, and act on what it finds.
Give enablement its own column
GitHub’s REST API reference describes responses containing pr_scan and repository_scan settings. Reading back an enabled value establishes configuration state. It is not a scan receipt.
A proposed rollout report should make that distinction visible. For each repository, record whether the setting is enabled, whether a scan has completed, and who owns assessment of the results. Leave an unrun scan explicitly marked “not run.” Do not turn an empty findings column into a zero-vulnerability claim.
Consider a fictional maintenance team with six eligible repositories. It enables all six but runs an initial scan on only two. Its report should say “six enabled; two initial scans completed.” That gives the team a useful next action. “100% protected” would conceal the four outstanding runs and overstate what even the completed scans establish.
Those counts are illustrative, not measurements from a real organization.
Start from the sites people maintain
The public Okeike Web Editor case study describes a working editor under ongoing development. A central site registry supports multiple maintained websites, recoverable drafts, and focused AI-proposed patches. Publishing creates a GitHub commit and follows the existing deployment pipeline to the relevant Firebase Hosting target.
That kind of maintenance arrangement gives a rollout an operational starting point: the sites the team is responsible for. It does not establish that Okeike uses AI Scan or that its repositories qualify for this preview.
For a similar multi-site workflow, begin by mapping maintained sites to their source repositories and responsible maintainers. Several sites might share a repository; a site might also depend on code outside its content repository. Count the real maintenance units before presenting a repository percentage as business coverage.
Then choose an initial scanning scope the team can actually assess. A smaller completed pass with named owners is easier to operate than an enablement campaign whose output nobody has time to read.
Read the configuration failures precisely
The new API follows policy inheritance. GitHub says repositories can opt out of an enabled organization setting, while an organization that disables the feature prevents its repositories from enabling it. Enterprise policy can also block enablement.
There is a specific detail worth preserving in rollout scripts: if a request updates pr_scan and repository_scan together and either change is blocked, GitHub returns 422 and neither setting changes.
A script should therefore preserve the response for that repository, read back the applicable state, and report the failure clearly. Do not report the first requested property as changed merely because the second property caused the error.
Keep this report separate from scan outcomes. A policy-blocked repository, an enabled repository awaiting its first run, and a completed scan with findings call for different follow-up.
Put a person on the next action
GitHub’s AI Scan documentation describes on-demand analysis of the default branch. During preview, scheduled scans and automatic scans on push are not supported. The agent selects code within a time budget; it does not examine every file exhaustively or guarantee detection of every vulnerability.
That scope should shape the team’s language and workload. A completed run is evidence that an analysis occurred, with limits. Findings still need assessment, and each scan consumes Code Security AI credits.
Assign the initial run to someone with the required access and budget visibility. Assign findings to a maintainer who can understand the affected behavior. If the available budget or review time constrains the first pass, document the remaining scope instead of hiding it behind the enabled setting.
For a small maintenance team, this is also a staffing decision. Making a feature available across repositories can expand the queue of work faster than the team can resolve it.
GitHub’s scan management guide also requires another manual scan after a potential fix reaches the default branch; merging the fix does not trigger one automatically. Put that follow-up into the assigned task.
The November 13 change makes configuration easier to repeat. A useful rollout report must show what happened after configuration: which runs completed, what remains unassessed, and who will pick up the work next.
Top comments (0)