GitHub has introduced REST API support for managing AI Scan for pull requests in public preview. The change gives eligible GitHub Advanced Security customers on github.com a programmatic way to read and update organization-level settings, as well as manage the feature at repository level.
For engineering and security teams, the main benefit is centralized administration through scripts, internal tooling, and GitHub management workflows. The controls still sit behind enterprise policy, organization permissions, and repository code-scanning prerequisites. GitHub Enterprise Server is not supported for this release.
What changed
The September 10, 2026 announcement places the AI Scan pull request APIs in public preview. The API supports management at both organization and repository levels.
At the organization level, the documented endpoints are:
GET /orgs/{org}/code-scanning/ai-scanto retrieve the stored organization setting.PATCH /orgs/{org}/code-scanning/ai-scanto update the setting.
The organization setting accepts the documented pr_scan values enabled and disabled. The REST API documentation shows examples using api.github.com, the application/vnd.github+json media type, and the X-GitHub-Api-Version: 2026-03-10 header.
Repository management uses the path /repos/{owner}/{repo}/code-scanning/ai-scan. The supplied documentation confirms the path, but does not establish the repository endpoint’s complete permissions model, request body, response format, status codes, or examples. Those details should not be assumed when building automation.
How AI Scan fits into code security
GitHub describes AI Scan as an AI-based scanning engine that runs during pull request review. Its purpose is to find vulnerabilities in supported languages and frameworks that are not covered by CodeQL. It therefore extends the coverage available through GitHub Code Security; it should not be treated as a replacement for CodeQL or other security controls.
AI Scan requires code scanning to be enabled for the repository, but it does not require CodeQL default setup. The supplied repository security guidance also states that Code Security features are available for public repositories and for private repositories whose organizations use GitHub Code Security or GitHub Advanced Security.
The available material does not provide a complete detection taxonomy, language and framework list, scan-trigger description, or full explanation of how findings are presented in pull requests. Teams should avoid treating the preview as a guarantee of coverage for a particular technology stack.
Policy and inheritance controls
AI Scan has several separate administrative controls. First, an enterprise owner can control whether organizations in the enterprise may enable the feature. The supplied enterprise policy documentation says the setting defaults to Not allowed. Changing the enterprise policy to allow AI Scan only permits organizations to use it; it does not enable the feature automatically.
After enterprise policy permits the capability, an organization administrator must enable AI Scan for the organization. If the organization setting is disabled, repositories cannot enable AI Scan. When the organization setting is enabled, eligible repositories inherit that setting, while repository administrators can opt out individual repositories.
This hierarchy means a successful rollout requires more than sending a PATCH request. Enterprise permission, organization enablement, repository code scanning, and repository-level opt-out are distinct steps or controls. The policy context is described in GitHub’s code security and analysis policy documentation.
Permissions for organization automation
The organization operations require the authenticated caller to be an organization owner or security manager. For fine-grained tokens, the documented organization permission is Administration with read access for the GET operation and write access for PATCH.
Requirements for OAuth app tokens and classic personal access tokens vary by operation and role, so automation owners should consult the endpoint documentation rather than assuming that a repository-level permission is sufficient for organization changes.
A practical first step is to use the organization GET endpoint to inspect the current stored setting before making a change. This can help administrative tooling avoid blindly overwriting an existing state and makes the intended organization policy visible in deployment logs or approval workflows.
What developers and administrators should do
- Confirm eligibility. Verify that the organization matches the announcement’s stated availability: a GitHub Advanced Security customer on
github.com. Do not assume that every account configuration or Enterprise Cloud deployment has identical access to the preview. - Check enterprise policy. Confirm that enterprise owners have allowed organizations to enable AI Scan. Organization-level API changes cannot bypass an enterprise prohibition.
- Validate the caller. Use an organization owner or security manager, and provide the documented token permissions for the requested GET or PATCH operation.
- Read before changing. Retrieve the organization setting with
GET /orgs/{org}/code-scanning/ai-scan, then update it with the documentedpr_scanvalue when a change is approved. - Prepare repositories. Ensure code scanning is enabled for repositories that should use the feature. Test the organization inheritance behavior and the repository opt-out process before applying the setting broadly.
- Keep preview safeguards. The organization endpoints are explicitly subject to change. Automation should be designed to tolerate API or behavior changes and should be checked against the official documentation as the preview evolves.
Availability and preview limitations
This is a public preview, not a generally available API. GitHub has not supplied a general-availability date in the material available for this report. GitHub Enterprise Server is excluded from this release, and the supplied sources do not fully establish the API support matrix across github.com and GitHub Enterprise Cloud.
Important operational details also remain undocumented in the supplied references, including AI Scan-specific rate limits, audit-log events, webhooks, failure-handling guidance, and the complete repository endpoint contract. Teams should avoid building workflows that depend on those behaviors until GitHub documents them.
For now, the API is most useful for teams that already manage GitHub security settings programmatically and need centralized organization control with repository-level flexibility. Its preview status and incomplete repository API details make a controlled test rollout more appropriate than treating it as a finalized platform contract.
