GitHub AI Scan REST API: Enable Repository Security Scanning Safely at Scale

Security scanning only helps when teams can control where it runs, understand its costs, and verify the results. GitHub’s November 13, 2026 update adds a useful administrative building block for organizations managing many repositories.

Why this change matters

On November 13, 2026, GitHub announced a public-preview REST API setting for AI Scan for repositories. Security teams can now manage repository backlog scanning eligibility at organization and repository levels without clicking through each settings page. This is an enablement control, not a command that automatically starts a scan. That distinction matters for both risk coverage and budgets: an administrator can turn the feature on while a repository still has no newly completed scan.

Check prerequisites before rollout

Confirm the repositories are hosted on GitHub.com. GitHub Enterprise Server is not supported by this preview. GitHub says organization-owned public repositories are eligible, while private and internal repositories require GitHub Code Security or GitHub Advanced Security. An enterprise policy must permit AI Scan. Organization owners and security managers can manage the organization setting, while repository administrators can opt repositories out. Before making any API request, verify that the identity you use has the required administrative permission and that your authentication mechanism is approved by your security team. Do not embed access tokens in shell history, scripts committed to Git, or CI logs.

Understand the two controls

The API exposes two distinct settings: pr_scan for pull request scanning and repository_scan for repository scanning. The new repository_scan field accepts enabled or disabled. Both fields can be updated together, but a blocked change returns HTTP 422 and neither field is applied. Organization-level disabling prevents repositories from enabling the feature. Organization-level enabling allows repositories to inherit the setting and opt out individually. This hierarchy is useful for staged rollouts: establish an organizational default, then record exceptions for sensitive or incompatible projects.

Read the current configuration first

Use the documented GET endpoints /orgs/{org}/code-scanning/ai-scan and /repos/{owner}/{repo}/code-scanning/ai-scan. Substitute real organization and repository names; never paste an actual token into a shared troubleshooting ticket. Use a REST client configured for the GitHub API and appropriate authorization. Save the response in a restricted change record and note both the organization policy and each repository's effective setting. A successful GET establishes configuration visibility, not evidence that code has been scanned.

Change one pilot repository or organization

After confirming enterprise policy and eligibility, use PATCH on the same documented endpoint with the repository_scan property set to enabled. For a cautious rollout, select a noncritical repository with an owner who can review findings and credit consumption. If your organization has a central governance model, coordinate the organization-level setting before allowing individual opt-outs. Avoid changing pr_scan in the same request unless you explicitly intend to change pull request scanning too. If the API responds with 422, do not blindly retry: investigate enterprise policy, inherited settings, eligibility, and whether the request attempted an incompatible combined change.

Run a scan deliberately and budget for it

GitHub explicitly states that enabling AI Scan for repositories does not initiate a scan. A user with write access must run scans on demand, and each scan consumes GitHub Code Security AI credits. Create an approval workflow for scan initiation, choose the repository scope, and record who requested it. Establish a spending guardrail and a remediation owner before scaling the rollout. A newly enabled repository should not be reported as security-reviewed until an actual scan finishes and its results are triaged.

Validate configuration and outcomes separately

After the PATCH request, repeat the GET request and compare the returned repository_scan state against the intended policy. Check a repository that inherits the organization default and another that explicitly opts out. Then arrange a permitted on-demand scan and verify that findings appear in the expected security workflow. Document the scan date, repository revision, responsible reviewer, and follow-up actions. Treat an empty findings list cautiously: it does not prove the absence of vulnerabilities, and an enablement toggle alone says nothing about scan coverage.

Plan a safe organization-wide rollout

Inventory eligible repositories, classify them by business criticality, and identify teams responsible for fixing findings. Pilot the setting on a small cohort, review permission errors and credit usage, then expand in controlled stages. Keep exceptions time-limited and review them regularly. Existing static analysis, dependency checks, secret scanning, and human review should continue: AI Scan is an additional detection layer rather than a replacement for established controls. For teams maintaining customer-facing applications, connect any new security finding to the normal issue, patch, staging, and release process.

Common troubleshooting cases

HTTP 422 when enabling the feature can mean enterprise policy blocks AI Scan; the announcement also notes that a blocked update to either setting prevents both changes. A successful enablement with no findings may simply mean nobody has run an on-demand repository scan. A repository that appears disabled despite an enabled organization default may have an explicit opt-out. GitHub Enterprise Server installations should not assume this cloud preview exists. Recheck the official documentation before automating production-wide changes because preview behavior can evolve.

Conclusion

The November 13 API update makes AI Scan configuration easier to govern across repositories, but it does not remove the need for authorization, scan scheduling, credit monitoring, and human remediation. Start by reading the current state, pilot the new repository_scan setting, verify the inherited policy, then run and review an explicitly authorized scan. This creates an auditable security improvement rather than a misleading dashboard toggle.