GitHub’s AI Scan Reaches Repositories. What Does the Preview Actually Search?

GitHub’s repository AI Scan preview adds manual, time-bounded vulnerability searches. We examine coverage limits, review work, and AI-credit costs.


A narrow ochre light reveals a few branches in a dense field while most remain in shadow.

Filed under


Independent reporting. Sources and corrections are listed with each story.

GitHub announced AI Scan for repositories in public preview on October 28, 2026, extending its AI-assisted security scanning to a repository’s existing code. The practical question is what that search covers. GitHub describes an agent that chooses where to investigate within a fixed time budget. For security teams, the preview offers another source of vulnerability leads, with limits that matter when interpreting its results.

What the repository scan actually searches

According to the launch announcement, an authorized user can manually scan the latest commit on a repository’s default branch. GitHub says the scanner concentrates on code it considers more likely to contain vulnerabilities. Findings enter the code-scanning backlog alongside CodeQL alerts.

The repository documentation makes the selection process clearer: the agent picks files and functions for deeper analysis, rather than reading every file in full, and stops when its time expires. “Repository” therefore identifies the search scope; it should not be read as a promise that every part receives equal scrutiny.

Coverage limits become review work

GitHub warns that the search is not exhaustive and findings can be inaccurate. Matching against CodeQL alerts is best-effort, so duplicates can reach the backlog. GitHub positions the feature as a supplement to CodeQL, with supported languages including those CodeQL already supports.

Those qualifications change how a team should read the output. An alert needs investigation before it becomes a remediation decision. An empty result cannot establish that the repository is secure.

The scans also require manual triggering: they do not run on a schedule or automatically on push. A team seeking another assessment after merging a fix must initiate another scan. Keeping that work current consequently needs an owner, rather than an assumption that each code change starts a fresh search.

Two colored paths overlap at a few points across a branching field, leaving other branches untouched.
AI-generated editorial illustration: AI News Fab / OpenAI. Conceptual illustration of complementary detection paths and remaining coverage gaps; not a GitHub interface or scan result.

Credits add another evaluation question

GitHub’s billing documentation says AI Scan consumes Code Security AI credits, including for public repositories that do not require active-committer licenses. Eligible usage draws first on included Copilot-entitlement credits; remaining usage can be metered. GitHub advises administrators to review included credits and set a hard budget before broad enablement.

The reviewed materials establish no typical credit or dollar cost per repository scan. Teams should measure actual consumption alongside the time reviewers spend assessing findings. Those are separate adoption costs, and neither can be estimated confidently from the launch description alone.

Three AI Scan scopes need separate treatment

GitHub’s overview distinguishes three capabilities: repository scanning, pull-request scanning, and scanning for AI-application and agent risks, including indirect prompt injection. Their coverage, availability, and billing requirements differ.

The October 15 pull-request release examines changes in selected languages and frameworks outside CodeQL coverage. GitHub says those findings are advisory and cannot block merges through ruleset requirements. That release does not establish the behavior of the repository preview.

For a separate policy-control question, our GitHub license-compliance coverage examines dependency-license enforcement on pull requests.

A useful pilot would measure the review burden

Our recommendation is a limited evaluation on representative repositories. Record which findings warrant fixes, which duplicate existing alerts, how much review effort they require, and what rescans consume. Compare results with existing review processes to identify added value and remaining gaps.

This is proposed evaluation guidance; no repository scan or independent security test was performed for this report. As of October 29, the reviewed official sources establish neither independently measured detection accuracy nor remediation outcomes. The documentation is undated and preview behavior may change. Adoption decisions should stay tied to observed results.

Sources

About the author