GitHub opens Copilot model policies to enterprise and organisation APIs

Generally available endpoints let administrators read and change model availability for enterprises, teams, agent apps and organisations.

GitHub has made REST endpoints for Copilot model policies generally available, allowing administrators to manage model availability through software as well as the product interface. The 19 October release covers four scopes: enterprises, enterprise teams, agent apps and organisations.

The update gives platform teams a more direct way to coordinate the models available across a large development organisation. A policy can now be retrieved, compared with the intended configuration and updated through an authenticated API workflow.

Four scopes for availability

The new endpoints provide GET and PATCH operations. Enterprise policies use the enterprise's Copilot model-policy route; separate routes cover enterprise teams and Copilot agent apps. Organisations have their own model-policy route under the organisation API.

GitHub says enterprise policies can delegate model control to organisations in organisation mode, or to teams and apps when the enterprise uses enterprise teams mode. That preserves the hierarchy rather than making every API caller an independent policy authority.

The scope distinction is useful when adoption differs across teams. One group may use a model for everyday development while another has a specialised agent application with different requirements. An enterprise can set the governing structure and delegate choices at the level that fits its operating model.

Configuration as a managed workflow

For engineering administrators, API access makes model policy easier to connect with existing internal tooling. A company could build a review screen that reads the current values, shows the proposed changes and records the approved update. It could also compare policy across organisations to identify configuration drift.

The read operation matters as much as the write. Before an update, an administrator can inspect the actual current state rather than apply a change based on an old spreadsheet or a screenshot. Afterward, the same endpoint can confirm that the intended value is present.

This is particularly useful in enterprises where a platform team manages many organisations. Repeating the same manual navigation for each one can be slow and difficult to audit. An API-based workflow can make the target, scope and requested policy explicit in one request record.

Availability is a separate administrative decision

The release concerns whether a model is available within Copilot. It does not announce a new model or change the behaviour of an existing one. That separation is useful: the product team can evaluate a model's capabilities while administrators decide where it should be offered.

It also gives organisations a clearer way to handle an evolving model catalogue. A new model can be reviewed and enabled for the appropriate scope without rewriting the entire client configuration. Conversely, changing a policy does not by itself establish which model a particular developer used for a particular task; usage evidence belongs to a separate operational record.

GitHub links the release to its documentation for model availability and enterprise AI controls. Those references define how policy delegation works and which administrative interfaces apply to each scope.

The practical change is a programmable control plane for a decision enterprises already make. Platform teams can integrate Copilot model choices with their normal configuration and approval processes, while retaining the enterprise, team, app and organisation boundaries the product exposes.

Sources

- [Copilot model policy API for enterprise, orgs, and teams](https://github.blog/changelog/2026-10-19-copilot-model-policy-api-for-enterprise-orgs-and-teams/) — GitHub