Copilot admins can now script which AI models each team gets

GitHub, a Microsoft company, has released a REST API that lets administrators read and change Copilot model policies at four levels: enterprise, enterprise team, enterprise app and organization. The GET and PATCH calls are generally available.

Four endpoints cover every level of control

According to the GitHub changelog entry from October 19, the API exposes one model-policies resource under four paths:

• /enterprises/{enterprise}/copilot/model-policies for the whole enterprise
• /enterprises/{enterprise}/teams/{team_slug}/copilot/model-policies for an enterprise team
• /enterprises/{enterprise}/copilot/apps/model-policies for enterprise apps
• /orgs/{org}/copilot/model-policies for a single organization

Enterprise policies can also hand control down. In organization mode, decisions pass to organizations. In enterprise teams mode, they pass to teams and apps. GitHub says this makes it easier to manage which Copilot models are available across an enterprise.

The entry is short. It does not say which roles or permissions a caller needs, and it does not list plan eligibility. Those points have to be checked in the REST API reference.

What the API changes for admins who clicked through settings

GitHub’s documentation on managing model availability describes the policy states the API now reaches. A model can be enabled for all users and agent apps, disabled for all, or delegated. On Copilot Business and Copilot Enterprise plans, a separate default-availability setting decides whether models that nobody has configured are on or off.

Until now, those choices were described in the context of the enterprise settings pages. A programmatic interface means a company with dozens of organizations can keep its model list in version control, review changes like code, and apply them in one pass when a new model appears. That is the practical gain, and it is a workflow change rather than a new capability. The changelog does not claim any new models or controls.

The teams mode deserves a warning. According to the GitHub docs, enterprise teams mode is an opt-in preview, and turning it on switches off organization-level model policies. Team settings are additive: a model the enterprise has disabled cannot be enabled for a team, and a model the enterprise has enabled is always on for teams. Teams cannot explicitly disable a model, and someone who belongs to several teams gets every model that any of those teams allows. The documentation also cautions that delegated models become unavailable until enabled for specific teams, so a migration can cause regressions, and that rollback is possible only while the feature is in preview.

Model access becomes a governance question, not a preference

The angle that fits this release is risk control. Choosing which model a developer’s assistant can call is, for many companies, a security and compliance decision, and an API makes that decision auditable.

Microsoft’s own security guidance points the same way. In an October 16 post on the Azure blog, Microsoft security assurance manager Michael Scovetta described a joint Microsoft and NVIDIA paper, Risk Management for Open-Weight Models in Enterprise, the first in a planned series. The paper sorts risk into five categories: cybersecurity, data protection, content, human-AI interaction and bias. It argues that weight openness alone does not decide how risky a system is, and says safeguards depend on the service and on how a model is deployed. Enterprises that run their own deployments may have to supply controls that a managed service would otherwise provide.

That framing explains why per-team model lists matter. A security group may be comfortable with one model for internal tooling and not for a team handling regulated data. With enterprise-level disables that always take precedence, according to GitHub’s docs, an administrator can set a ceiling that no team or organization can override.

The same concern runs through our earlier coverage of Microsoft’s agent security work, which starts from the assumption that AI agents may behave in ways their operators did not intend. Restricting the models that agents can reach is one of the simpler levers available.

What the announcement leaves unanswered

The changelog gives no rate limits, no audit-log details and no statement about whether policy changes made through the API are logged differently from those made in the web interface. It does not say how quickly a changed policy reaches users in editors. It also does not name any model, so it is unclear which current models the policies would cover beyond those the enterprise already sees in its settings.

Developers who use Copilot through sessions that move between tools, such as the Copilot app and VS Code, are affected indirectly: the docs say agent app models are controlled at the enterprise level, so one policy decision applies across those surfaces.

For now, the API is a management tool for enterprise administrators, with no consumer impact. Teams that want to use it should read the REST reference first, test on a single organization, and avoid the teams preview until they have worked out how additive team rules interact with their current model list.