GitHub released REST API endpoints on September 10, 2026, for managing AI Scan enablement at the organization and repository levels. The public preview gives teams a programmatic way to roll out AI-powered security detections for pull requests across select repositories without manually configuring each setting in the GitHub UI. GitHub's September 10 changelog explicitly states that GitHub Enterprise Server is not supported in this release. The tool works. The API works. The self-hosted version does not ship with either.
The 120-route construction ERP at coenconstruction.com runs on servers I control. Payroll data, bid histories, subcontractor contact lists, and project financials do not leave the network perimeter. The app uses GitHub Enterprise Server for version control and pull request reviews because the code that touches that data cannot sync to a third-party cloud service without triggering a compliance exception. GitHub AI Scan is an LLM-based security detection engine that runs alongside CodeQL on pull requests and surfaces potential vulnerabilities in languages and frameworks that CodeQL's built-in analysis does not cover, using probabilistic LLM inference on the specific code changes in a pull request. That capability is exactly what a small security team needs when developers are shipping features faster than manual code review can catch every edge case.
The API solves the audit problem but only on the cloud
The new API endpoints allow programmatic management of AI Scan enablement; using the /orgs/{org}/code-scanning/ai-scan endpoint, an organization admin can enable AI Scan at the organization level through the REST API, and repository-level enablement can be managed via /repos/{owner}/{repo}/code-scanning/ai-scan. A team subject to compliance frameworks like SOC 2, ISO 27001, or the US Department of Defense's CMMC can now generate machine-readable records of which repositories had AI scanning active at any given point — evidence that would be difficult to reconstruct from UI clicks alone. That audit trail is not optional. It is the difference between passing a compliance review and explaining to an auditor why your security tooling configuration lives in screenshots.
Estimate.pro uses GitHub Actions for CI/CD. The integration runs linters, tests, and CodeQL scans on every pull request before merging to production. Security teams can now write scripts that query which repositories have AI Scan enabled, enable it for the highest-risk repositories first, and expand progressively as they calibrate false-positive rates against their specific codebase profiles. That staged rollout is the only sane way to introduce a probabilistic security tool into a pipeline that already gates deployments on deterministic checks. You start with the API endpoints that handle payment processing, measure the noise, adjust the thresholds, and then expand to the rest of the codebase. The REST API makes that workflow scriptable. But only if your GitHub instance is hosted by GitHub.
The feature exists. The API exists. The on-prem version does not.
Three prerequisites apply: an enterprise owner must allow AI security detections at the enterprise policy level, the organization must have GitHub Advanced Security enabled, and CodeQL default setup must be active on any repository targeted for AI scanning. Those are reasonable gates. The problem is not the prerequisites. The problem is that Enterprise Server customers already meet all three requirements and still cannot use the tool because the deployment target determines availability, not the license tier.
Self-hosted deployments are not a legacy concern
Thepunchlist.ai processes construction punch-list photos through a vision model. The app runs on Cloudflare Workers. The code is in GitHub. The integration tests run on GitHub Actions. The CI pipeline uses CodeQL to catch SQL injection and path traversal bugs before they reach production. That workload is cloud-native and would benefit immediately from AI Scan. The ERP at coenconstruction.com cannot move to GitHub Cloud because the data governance requirements are stricter than the feature velocity. The codebase is just as complex. The attack surface is larger. The need for automated vulnerability detection is higher. The tool that would help is not available.
The pace from the July feature preview to September API access — two months — suggests the team is iterating quickly, and general availability alongside eventual Enterprise Server support appears to be the logical roadmap target. Eventual is not a release date. The feature gap between GitHub Cloud and Enterprise Server used to be measured in quarters. Now it is measured in capabilities that may never ship to self-hosted customers, because the LLM inference that powers AI Scan is easier to run in a data center GitHub controls than in a server rack a customer operates.
The strategic bet GitHub is making is that security tooling requiring third-party model inference will be cloud-exclusive, and customers who need on-prem deployments will accept a feature gap or migrate. That bet may be correct for most customers. It does not work for the ones who picked Enterprise Server specifically because their compliance posture or data classification rules prohibit sending code diffs to an external API. The model shipped. The API shipped. The deployment option that half the security-sensitive customers depend on did not, and the roadmap does not promise it will.