GitHub AI Scan for Pull Requests Now Configurable via REST API

GitHub shipped REST endpoints to programmatically manage AI Scan for pull requests enablement — previously a UI-only toggle for Advanced Security customers. Public preview as of September 10, 2026.

What changed

Four new endpoints under code scanning, verified in the REST API reference:

• GET /orgs/{org}/code-scanning/ai-scan — org-level read
• GET /repos/{owner}/{repo}/code-scanning/ai-scan — repo-level read
• Matching update endpoints for both levels

The setting lives behind a single field: {"pr_scan": "enabled"} is the documented 200 response shape. Status codes on the org GET: 200, 403, 404.

The precedence rule is the real story: repository settings do not override an organization-level disabled state. Org gates first, repos opt in below the ceiling. GitHub Enterprise Server is not supported — github.com GHAS customers only.

Why a builder cares

Every security feature that starts as a UI toggle ends up as configuration drift: turned on in one repo, off in another, nobody remembers which. An API endpoint is the difference between AI Scan being a setting and being infrastructure — you can now gate it in Terraform, audit it in CI, and enforce it from a policy repo instead of clicking through org settings page by page.

The flip side: an API for enablement is also an API for silent disablement. A leaked fine-grained PAT with code-scanning write access can now flip pr_scan to disabled across a whole org in one request, no audit-log tripwire unless you've built one. Watch the audit log for these endpoints the way you already watch CodeQL default-setup changes — GitHub added audit tracking for Code Quality enablement changes in August, and this follows the same pattern.

Compare with the same-day cache-mode release: GitHub is pushing least-privilege configuration into workflow syntax and programmatic security controls in the same week. The direction is clear — security posture is becoming declarative, not manual.