GitHub AI Scan API Adds Repository-Wide Controls in Public Preview

What changed​

The setting sits on the same endpoints as before:

• GET and PATCH /orgs/{org}/code-scanning/ai-scan
• GET and PATCH /repos/{owner}/{repo}/code-scanning/ai-scan

Set repository_scan to enabled or disabled. GitHub's documentation shows an organization-level PATCH that sets both properties in one body. The examples use the X-GitHub-Api-Version: 2026-03-10 header, which is the version shown in the docs. The documented example is -d '{"pr_scan":"enabled","repository_scan":"enabled"}'. The response returns both values.

The docs show the same two properties on the repository-level endpoints. Not every doc rendering has caught up, though. A search snippet from the Enterprise Cloud docs page still listed only pr_scan for the repository PATCH. If your script depends on repository_scan, test it against a non-critical repository first. This is preview functionality and GitHub says it may change.

How the hierarchy works​

The rules match the pull request setting, so existing assumptions carry over:

• Organization disabled: repositories cannot enable the feature themselves.
• Organization enabled: repositories inherit the setting. Repository administrators can opt individual repositories out.
• Enterprise policy: if the enterprise does not allow AI Scan, a request to enable it returns a 422 error. GitHub's docs say the enterprise policy is "Not allowed" by default. Allowing it does not switch it on.
• Combined updates: you can send pr_scan and repository_scan in one request. If either change is blocked, the request returns 422 and neither setting changes.

The all-or-nothing behavior matters for automation. A script that sends both settings can't end up half-configured. If an enterprise policy blocks one of the two, you also won't get a partial result. A script should treat a 422 as "nothing changed" and read the settings back before retrying.

Enabling is not scanning​

Turning on repository_scan does not start a scan. Users with write access run scans on demand. GitHub's documentation says each scan consumes Code Security AI credits. That usage is separate from active-committer licensing.

Some documented behavior to know before a broad rollout:

• Scope: scans cover the default branch only. They are triggered manually, with no scheduled or on-push scans. Self-hosted runners are not supported.
• Languages: AI Scan supports all languages, including those CodeQL already covers. It runs independently of CodeQL.
• Results: findings appear in the code scanning alert list alongside CodeQL alerts. You can filter them by the AI Scan tool.
• Accuracy: matching against existing CodeQL alerts is best effort, so duplicates can occur. GitHub also warns that AI-generated findings can be inaccurate and says a scan does not guarantee it finds every vulnerability.
• Limits: detection steps are capped at 30 minutes and 150,000 AI credits.
• Billing: usage is billed to the account responsible for the organization's billing. Included AI credits from a Copilot entitlement are used first. After that, usage is metered under your budgets. A hard budget that leaves no credits means scans can't produce findings.

Enabling the setting across an entire organization therefore sets up the option to spend credits. It does not spend them by itself. Check budgets before you encourage teams to start scans.

Who can call these endpoints​

Per GitHub's API reference:

Organization endpoints

• The caller must be an organization owner or security manager.
• Fine-grained tokens need organization Administration permission: read for GET, write for PATCH.
• Classic tokens need admin:org, repo, or write:org. Owners can use admin:org or repo. Security managers need write:org.

Repository endpoints

• Fine-grained tokens need Code scanning alerts (read) for GET. GitHub's reference lists repository Administration (write) for PATCH.
• Classic tokens use security_events or public_repo for GET. For PATCH they use repo or public_repo.
• GET returns 403 if GitHub Advanced Security is not enabled for the repository.

Eligibility​

• Organization-owned public repositories: available without an active-committer license.
• Organization-owned private or internal repositories: need GitHub Code Security or GitHub Advanced Security.
• Personal-account repositories: public ones are available. Private ones are not.
• Copilot: a GitHub Copilot license is not required.
• GitHub Enterprise Server: not supported. Tech Times noted the same exclusion for the earlier pull request API, with no roadmap date given.

Suggested rollout approach​

This is general practice, not GitHub guidance:

1. Confirm the enterprise policy allows AI Scan.
2. Set budgets for Code Security AI credits.
3. Use a GET on the organization endpoint to record the current pr_scan and repository_scan values.
4. PATCH the organization setting, then read it back to verify.
5. Opt out repositories that shouldn't participate, using the repository endpoint with a token scoped for repository administration.
6. Store the calls in your infrastructure-as-code pipeline so the configuration can be reviewed and audited.

The bottom line​

The new repository_scan property is a small API addition, but it closes a real gap. Teams managing many organizations and repositories can now handle the full-repository AI Scan setting the way they already handle the pull request one. The preview label, the manual scan trigger, and the credit-based billing are the details to plan around. AI findings also still need human review.