Developer Security
GitHub Adds APIs for AI Scan, With an Organization-Level Gate
GitHub added REST APIs for managing AI Scan on pull requests on September 10. Teams can read or change organization and repository settings programmatically, but enabling one repository does not override an organization-level disabled state. The preview is for GitHub Advanced Security customers on github.com, not Enterprise Server.
Citation-ready: GitHub's AI Scan API preview preserves organization-level precedence: a repository cannot enable pull-request scans when the organization has disabled them.
Evidence boundary: Official feature preview and documented setting hierarchy. No scan was executed and no detection-accuracy or vulnerability-absence claim is made.
What happened and why it matters
The new API makes fleet configuration easier, but the hierarchy means that a successful repository update is not enough to establish effective scan coverage.
Primary evidence
Primary reference: GitHub Changelog. Kaleido Field checked the event date and the article's attributed facts against this source.
| Source date | September 10, 2026 |
|---|---|
| Checked by Kaleido Field | September 11, 2026, CST |
| Source function | developer security -> effective configuration and API readback |
Two settings contribute to the result
The release names /orgs/{org}/code-scanning/ai-scan and /repos/{owner}/{repo}/code-scanning/ai-scan. A rollout needs the organization setting as well as the selected repository settings.
After a configuration write, read back both levels and retain the effective state. An API response confirming a write should not be relabeled as a completed scan of the current pull request.
The deployment boundary is explicit
The public preview is offered on github.com to GitHub Advanced Security customers. GitHub says Enterprise Server is not supported in this release. A script used across both environments needs a supported-platform check.
A useful inventory should distinguish unsupported, disabled, enabled and actually scanned repositories. Combining those states into one adoption percentage would hide the work that remains.
Enablement is not a clean bill of health
A scan setting describes intended coverage. A scan receipt describes one run, and a reviewed finding describes another step. None of these individually proves the absence of security flaws.
Compare the configuration hierarchy with our cache permissions report: both require reading the effective control, not just the most local setting.
Evidence boundary
Official feature preview and documented setting hierarchy. No scan was executed and no detection-accuracy or vulnerability-absence claim is made.
FAQ
Can a repository enable AI Scan when its organization has disabled it?
No. The announcement explicitly says repository settings do not override an organization-level disabled state.