GitHub AI Scan for Pull Requests: Manage It with the REST API

GitHub now exposes REST API endpoints for managing AI Scan for pull requests at the organization and repository levels. That gives security teams a way to roll the setting out with automation instead of opening every repository's settings page by hand.

The feature is in public preview, available on github.com for GitHub Advanced Security customers, and not supported on GitHub Enterprise Server in this release. The GitHub announcement gives the short version. The AI Scan REST API reference has the current authentication, request, and response details.

Think in two switches

The organization setting is the ceiling. It can enable or disable AI Scan for the organization, and it respects an enterprise policy. If the enterprise disallows AI Scan, an organization cannot enable it. When the organization is enabled, individual repositories can still opt out.

The repository setting controls the local choice. A repository cannot use it to override an organization-level disabled state. This parent-child relationship is the first thing to model in an automation script.

Enterprise policy
  └─ Organization setting
       └─ Repository setting

Enterprise disabled → organization cannot enable
Organization enabled → repository may opt out

Read the organization setting

The organization endpoint returns the setting stored on the organization. The API docs say the caller must be an organization owner or security manager. Use a fine-grained token with Administration organization permissions set to read, or the token type and scope appropriate for your integration.

gh api \
  -H 'X-GitHub-Api-Version: 2026-03-10' \
  /orgs/ORG/code-scanning/ai-scan

A successful response has the shape { pr_scan: enabled } or { pr_scan: disabled }. Treat the value as the stored organization setting, not proof that every repository is currently scanning. Repository opt-outs and eligibility still matter.

Enable the organization setting carefully

The update endpoint accepts enabled or disabled. Because this is a security setting with organization-wide effect, put it behind a reviewed change, log the actor and response, and run the read request first.

gh api \
  --method PATCH \
  -H 'X-GitHub-Api-Version: 2026-03-10' \
  /orgs/ORG/code-scanning/ai-scan \
  -f pr_scan=enabled

A 403 usually means the caller does not have the required access or the organization is not eligible. A 422 can indicate validation failure. If the enterprise policy blocks the setting, changing the organization request will not bypass it.

Check a repository before changing it

Use the repository endpoint to inspect one repository's value. Reading requires Code scanning alerts repository permission for a fine-grained token. Updating is more privileged and requires Administration repository permissions for a fine-grained token.

gh api \
  -H 'X-GitHub-Api-Version: 2026-03-10' \
  /repos/OWNER/REPO/code-scanning/ai-scan

# Enable one repository after the organization allows it
gh api \
  --method PATCH \
  -H 'X-GitHub-Api-Version: 2026-03-10' \
  /repos/OWNER/REPO/code-scanning/ai-scan \
  -f pr_scan=enabled

The repository update endpoint can return 403 when the repository is archived or Advanced Security is not enabled. It can also fail when the caller lacks repository administration access. Keep those cases separate in your report so a policy restriction is not mistaken for a transient API error.

A sensible rollout script

1. Read the organization setting and record the enterprise constraint if the API exposes one.
2. List target repositories and classify them by language, build time, and Advanced Security eligibility.
3. Enable the organization setting only after the owners approve the scope.
4. Read each repository setting and update only the repositories that should participate.
5. Re-read every changed repository and store the result with the run date, repository name, and API response status.

What the API does not do

• It does not replace code scanning workflow configuration or decide which repositories your policy should include.
• It does not override an enterprise policy that disables AI Scan.
• It does not make the public preview stable forever. Pin API versions in requests, but still watch the documentation for preview changes.

The useful mental model is a hierarchy, not a single on/off switch. Enterprise policy sets the boundary, the organization chooses the broad default, and the repository chooses whether to participate. Use the new API to inspect first, change second, and verify last. That gives security teams a repeatable rollout without hiding policy decisions inside a one-off script.