GitHub announced REST API controls for repository AI Scan on 13 November 2026, adding a public-preview way to manage enablement across organizations and repositories. The change lets teams automate configuration, but enabling the setting does not launch an analysis. For university research software teams, the distinction is between permission to scan and evidence that a scan actually ran.
What changed in the REST API
The new repository_scan property accepts enabled or disabled. GitHub’s REST reference documents GET and PATCH operations at /orgs/{org}/code-scanning/ai-scan and /repos/{owner}/{repo}/code-scanning/ai-scan. These endpoints read or change the setting; the separate pr_scan property controls pull-request scanning.
For fine-grained access tokens, the reference specifies Administration write permission at organization level for organization updates and at repository level for repository updates. The November 13 announcement identifies organization owners and security managers as the people who manage the organization setting, with repository administrators able to opt individual repositories out.
This extends an existing feature: GitHub introduced repository AI Scan in public preview on October 28. That launch put repository findings alongside CodeQL alerts. The new development is programmatic management of enablement, rather than a new general-availability release of the scanner.
Enterprise policy still governs repository settings
GitHub says repositories inherit an enabled organization setting and can opt out individually. An organization that disables repository AI Scan prevents its repositories from opting in. Enterprise owners must allow AI Scan through enterprise policy; an attempt to enable it against that policy returns HTTP 422.
A request can update pr_scan and repository_scan together. If either change is blocked, GitHub says the API returns 422 and leaves both settings unchanged. For institutional automation, that means a rejected combined request cannot be treated as a partial rollout.
Availability and scans remain separate
The repository-backlog documentation lists public organization repositories as eligible, while private or internal organization repositories require GitHub Code Security or GitHub Advanced Security. A GitHub Copilot license is not required. The November 13 announcement excludes GitHub Enterprise Server.
Users with repository write access still initiate scans manually, and each scan consumes Code Security AI credits. GitHub documents default-branch analysis and says scheduled scans and automatic scans on push are unsupported. Its scanner selects code within a time budget; it does not examine every file exhaustively or guarantee detection of every vulnerability. AI findings can also be inaccurate and require review.
What it means for research software governance
The institutional implication is a separation of responsibilities. Enterprise policy establishes whether the feature is allowed; organization and repository settings establish where it is enabled; execution and assessment establish whether a scan was performed and what happened to its findings. A configuration inventory alone cannot establish the latter.
For a research office coordinating with research software engineers, the new controls offer a way to manage settings across eligible repositories while retaining named responsibility for running scans and assessing alerts. The practical consequence of GitHub’s stated limits is that scan findings belong alongside other source-code analysis and research software code review. An enabled flag is not evidence that a codebase is secure or that its scientific results are correct.
Sources
- GitHub Changelog, Manage AI Scan for repositories using the REST API, 13 November 2026. Checked 2026-11-14.
- GitHub Docs, REST API endpoints for code scanning. Checked 2026-11-14.
- GitHub Docs, AI Scan for a repository’s backlog. Checked 2026-11-14.
- GitHub Changelog, AI Scan for repositories in public preview, 28 October 2026. Checked 2026-11-14.
