GitHub Copilot Model Policies API: Automate Org and Enterprise Defaults

GitHub's Copilot model policy API adds GET and PATCH endpoints for enterprises, teams, apps, and organizations. Here is how to automate access without losing control.

Enterprise, organization, team, and app policy panels routing Copilot model access through permission gates

GitHub now exposes generally available REST endpoints for reading and updating Copilot model policies at the enterprise, enterprise team, enterprise app, and organization levels. That turns a settings task into something you can audit, review, and run from the same control plane as the rest of your developer platform.

The useful distinction is policy scope. An enterprise can keep control centralized, delegate model decisions to organizations, or delegate them to teams and apps when the enterprise is using enterprise teams mode. The API lets you make that choice repeatably instead of relying on screenshots and manual toggles.

What is available

GitHub's changelog lists GET and PATCH endpoints for four policy surfaces:

Enterprise model policies.

Enterprise team model policies.

Enterprise app model policies.

Organization model policies.

Start with the organization endpoint

For many teams, the organization endpoint is the easiest place to start. A GET request returns the effective policy for every model available to the organization, including the default availability setting and whether a model is enabled or disabled.

The organization GET endpoint is https://api.github.com/orgs/ORG/copilot/model-policies. Send the recommended Accept header, an Authorization bearer token, and the current GitHub API version header.

The response is more useful than a list of explicit overrides. GitHub resolves inherited defaults and reports the effective result, so an audit can show what members actually see rather than only what an administrator last changed.

Updates are atomic

The PATCH endpoint updates the policies in a request atomically. If one requested change cannot be applied, GitHub saves none of the changes. That makes policy-as-code safer: a failed rollout does not leave half of your model list in a new state.

PATCH the same endpoint with default_availability and a models array. For example, set default_availability.policy_state to disabled and set the returned MODEL_NAME to enabled. Keep the token in your secret manager rather than embedding it in a URL or script.

Use model_name values returned by GET. Do not hard-code a catalog from an old document: model availability changes, and inherited enterprise policies can make some organization settings non-editable.

Policy state is not the same as user access

A policy says whether a model is available through the relevant Copilot control surface. It does not replace seat assignment, product eligibility, organization membership, or other access checks. GitHub's enterprise app documentation also warns that policy states do not necessarily determine whether an individual user can access a model.

Permission and token choices

The organization endpoints are owner-level controls. GitHub documents support for GitHub App user access tokens, GitHub App installation access tokens, and fine-grained personal access tokens with the required organization Administration permission. Classic OAuth and personal tokens need the documented organization scopes.

For an automated policy job, use a GitHub App installation token where possible. Keep the token in a secret manager, give the app only the permissions required to read or write the policy, and record the target scope in the job's audit output without logging the token.

A safe rollout pattern

GET the current policy and save a redacted snapshot for review.

Compare the desired state against the effective state, including inherited enterprise settings.

PATCH only the changes approved by the review.

GET again and verify the effective result, then notify owners if a model is locked by enterprise policy.

This pattern also gives you a useful drift report. If a manual change appears in the GET response, you can decide whether to preserve it, restore the approved state, or change the source policy that is supposed to own it.

The practical takeaway

If your organization has more than a handful of Copilot users, treat model availability like any other developer-platform policy. Read the effective state, make the intended scope explicit, use a narrow automation identity, and verify after every update. The new API gives you the missing mechanics for doing that consistently.

Sources: GitHub Changelog: Copilot model policy API; organization model policy API documentation; enterprise AI controls API documentation.