What GitHub shipped
GitHub's changelog says GET and PATCH endpoints are generally available for model policies at four levels:
| Scope | Route listed in the changelog |
|---|---|
| Enterprise | /enterprises/{enterprise}/copilot/model-policies |
| Enterprise teams | /enterprises/{enterprise}/teams/{team_slug}/copilot/model-policies |
| Enterprise apps | /enterprises/{enterprise}/copilot/apps/model-policies |
| Organization | /orgs/{org}/copilot/model-policies |
Enterprise policies can delegate model control to organizations in organization mode. In enterprise teams mode, they can delegate to teams and apps instead.
A path discrepancy to check first
The changelog lists the team route with a {team_slug} placeholder. GitHub's enterprise AI-controls API reference, as captured for this story, documents the enterprise app, enterprise and related endpoints. Per the reporting notes, its team parameter is {team_id}, an integer identifier, and its examples use TEAM_ID. I could not independently confirm the team-route reference text in this pass. Confirm the identifier type in the live reference before you hard-code the route into automation.
Enterprise-level behavior
- Permissions: enterprise owners and users with
read_enterprise_ai_controlscan read policies. Writing requires an owner orwrite_enterprise_ai_controls. - Tokens: classic personal access tokens and OAuth app tokens need
read:enterprisefor GET andadmin:enterprisefor PATCH. Fine-grained GitHub App tokens need the "Enterprise AI controls" enterprise permission, set to read or write. - Default availability: the enterprise PATCH can set it to
enabled,disabled, ordelegate_to_organizations. - Per-model states:
enabled,disabled,delegate_to_teams_and_apps, ordelegate_to_organizations. Enterprises without organizations can't use the last one. - Status codes on update: 200, 401, 403, 404, 422 and 503.
Teams and apps
Team and app policies are deliberately simple. You can set a model to enabled or disabled, or use optional to remove a stored policy. Locked models can't be updated. Responses include the enterprise policy state and an editable flag.
The docs warn that these states don't necessarily decide whether an individual user can access a model. The enterprise teams docs explain why. Team grants are additive, and a user in several teams gets the union of what the enterprise and their teams enable. A team can't be explicitly set to disabled, because "optional" just means not enabled for that team.
Organization-level behavior
Organization owners can use the organization endpoints. They return the effective policy for every model available to the organization.
- If a model has no explicit policy but is eligible for default availability, the enterprise default applies when configured. Otherwise the organization default applies.
- A model that isn't eligible and has no explicit policy is disabled.
- PATCH is atomic: if any change in the request can't be applied, none are saved.
- Locked and inherited settings: models with an inherited enterprise policy are locked, and default availability can't be changed when it is inherited.
- Mode restriction: the organization must be independent or belong to an enterprise that isn't using enterprise teams for model policy.
- Tokens: classic tokens need
admin:orgorrepo. Fine-grained tokens need organization Administration (write). SAML authorization and OAuth app restrictions apply.
Practical notes for administrators
- The documented examples send
Accept: application/vnd.github+jsonandX-GitHub-Api-Version: 2026-03-10. - On GHE.com, swap
api.github.comfor your dedicatedapi.SUBDOMAIN.ghe.comhost. - Fetch the organization policy with GET first. PATCH requests must use the
model_namevalues that GET returns, and each name must be unique in the request.
A minimal enterprise update, adapted from GitHub's example shape, looks like this:
curl -L -X PATCH \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
[url]https://api.github.com/enterprises/ENTERPRISE/copilot/model-policies[/url] \
-d '{"default_availability":{"policy_state":"enabled"},"models":[{"model_name":"gpt-5.6-sol","policy_state":"enabled"}]}'
Why teams mode needs a plan
Teams mode is still an opt-in preview. The docs say organization-level model settings are deactivated once you opt in. Models delegated to organizations become unavailable until they are enabled for specific teams. Enterprise-level enabled or disabled settings carry over. GitHub also says you can roll back during the preview, but enterprise-level policy changes made after switching are not preserved.
The model works like this: admins set an enterprise baseline, then allow additional models to specific teams. That lets access differ by job role, training level, or experimentation with new models. Independent commentary from BaristaLabs makes the same point. Organization-level settings stop applying, and one permissive team membership can give a user access to a model. If you automate team grants, audit membership as carefully as the policy itself.
Bottom line
This release adds no new models. It adds consistent, scriptable control over which models people can use. That makes policy-as-code, drift checks and bulk changes practical for enterprise, team, app and organization scopes. Before deploying, check:
- The team identifier type in the live API reference.
- The token permissions you're using.
- Whether your enterprise is in organization mode or teams mode.
- Whether each returned policy is editable or inherited.
Even then, a returned policy state isn't a guarantee of any one user's access.
References
- Copilot model policy API for enterprise, orgs, and teams GitHub Changelog · 2026-10-19T21:32:18+00:00
- REST API endpoints for enterprise AI controls - GitHub Enterprise Cloud Docs docs.github.com
- REST API endpoints for Copilot model policy management - GitHub Enterprise Cloud Docs docs.github.com