September 16 update: AI Scan no longer requires CodeQL default setup
Update, September 16, 2026: GitHub says AI Scan for pull requests can now run without CodeQL default setup. Repositories still need code scanning enabled, and AI Scan must be enabled at the repository, organization or enterprise hierarchy that governs the project.
| Requirement | Current status | What to verify |
|---|---|---|
| CodeQL default setup | No longer required for AI Scan | Do not use its absence as a proxy for disabled AI Scan |
| Code scanning | Still required | Confirm repository eligibility and effective enablement |
| AI Scan policy | Still required | Check repository, organization and enterprise hierarchy |
| GitHub Advanced Security | Required in this public preview | Confirm licensing for the target owner |
| GitHub Enterprise Server | Not supported | Keep cloud and server coverage reports separate |
Why the change affects coverage reports
A security inventory that equated AI Scan with CodeQL default setup can now undercount protected repositories. Update reporting logic to query AI Scan policy directly, preserve organization and enterprise overrides, and confirm that a representative pull request actually receives a scan. This strengthens the original article’s central point: configuration state is not the same as verified coverage.
GitHub describes the change as public preview for organization-owned and personal repositories on GitHub.com for GitHub Advanced Security customers. GitHub Enterprise Server remains unsupported.
Primary source for this update
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.
