GitHub has added organization and repository APIs for rolling out AI Scan on pull requests. Security teams can now inspect and change enablement programmatically, with one hierarchy rule that can override every repository setting.
GitHub announced the AI Scan pull-request APIs on September 10, 2026. They are in public preview for GitHub Advanced Security customers on GitHub.com and are not available for GitHub Enterprise Server.
The APIs expose two policy levels
Organizations can read or update AI Scan enablement through /orgs/{org}/code-scanning/ai-scan. Repository administrators can use /repos/{owner}/{repo}/code-scanning/ai-scan for repository-level state.
| Scope | Endpoint | Operational use |
|---|---|---|
| Organization | /orgs/{org}/code-scanning/ai-scan | Read or set the organization policy |
| Repository | /repos/{owner}/{repo}/code-scanning/ai-scan | Read or set an individual repository |
Organization disabled overrides repository enabled
GitHub states that when AI Scan is disabled at the organization level, the organization policy takes precedence over repository settings. A repository that appears enabled therefore may not have an effective enabled state.
Inventory scripts should save both requested state and effective state. If a dashboard stores only the repository value, it can report protection that the organization policy has already switched off.
Build rollout around rings, not one bulk request
- Export the current organization and repository states before writing anything.
- Start with a disposable repository that has representative languages and pull requests.
- Expand to a small ring of low-risk repositories with named owners.
- Measure useful findings, duplicates, dismissals, review delay and developer corrections.
- Move high-risk repositories only after branch rules and escalation paths are verified.
- Keep the initial export as a tested rollback manifest.
The same staged approach appears in our GitHub Copilot agentic autofix analysis. For merge controls after automated changes, use the VS Code Agent Merge guide.
API success is not rollout success
A successful update response proves that GitHub accepted a configuration request. It does not prove that a scan ran on an eligible pull request, that the repository policy is effective or that a useful finding reached the right reviewer.
After each rollout ring, create a known test pull request and verify the complete chain: effective policy, scan execution, finding visibility, permissions, dismissal workflow and audit record. Keep a benign test case so the check can be repeated after preview changes.
Public preview changes the automation contract
Preview endpoints can change before general availability. Pin the API version and media type documented by GitHub, treat unknown response fields as nonfatal, and alert when expected fields disappear. Do not make the endpoint the only record of your intended security policy.
GitHub.com’s availability also matters for mixed estates. An organization using GitHub Enterprise Server cannot assume the same control exists there, even if other code-scanning APIs look similar.
What security leaders should report
Report coverage as eligible repositories with effective enablement, not repositories that received an update call. Add scan execution rate, actionable findings, false-positive dismissals, median time to resolution and the number of repositories outside GitHub.com.
That turns a rollout counter into a security outcome. It also exposes the organization-level override before it becomes a silent coverage gap.
Read the primary documentation
Checked September 12, 2026. Availability and hierarchy behavior are attributed to GitHub. Rollout and reporting guidance are MustHave.ai analysis.
