GitHub Adds Enterprise Team Model Policy Targeting: Admin Control Over Which AI Models Each Team Gets

GitHub announced on July 31 that enterprise model policy targeting is in public preview: admins can now set a baseline of Copilot models for the whole enterprise, then grant additional models to specific enterprise teams. It is the first step of a shift the changelog describes as team-level governance, and it matters because model access control is quietly becoming the most important enterprise AI lever, ahead of billing or prompts.

What Changed#

The feature lives in the Copilot page under "Models" as an Enterprise teams mode toggle. Once enabled, model availability is managed at the enterprise level through three states per model:

• Enabled - available to all enterprise members
• Disabled - not available to any enterprise member
• Optional - only available when assigned to an enterprise team

Admins can create enterprise teams and assign Optional models to them before switching the mode on, which lets them prepare model-to-user assignments during the rollback window.

Two behaviors in the changelog are worth reading twice. First, evaluation uses a least-restrictive strategy: if a user gets a model from any single enterprise team, they have access to it everywhere, across every org they belong to. Second, when enterprise teams mode is on, organization-level model settings no longer apply at all - the enterprise policy becomes the only policy.

The preview also includes a rollback: during the preview you can reset to your previous configuration. GitHub is rolling the opt-in out gradually, with most enterprise customers gaining access on August 3.

This lands two days after GitHub's "Default model enablement" change for Copilot Business and Enterprise, and the two read as one program: first make a sensible model default available to everyone, then let admins carve access down by team rather than by org.

Why This Matters#

Model policy is the layer between "Copilot works" and "Copilot works safely at 5,000 people," and until now the only granularity was the org. That is the wrong granularity for how companies actually work: a platform team that needs a frontier model for agentic work is a team, not an organization, and so is a security review group that should only get models approved for code review.

Three implications for developers:

Cost control becomes role-based. Enterprises do not pay for model access per user in the abstract - they pay for frontier model usage, and the pricing story has been shifting to usage-based all year. Assigning expensive models to the teams whose work justifies them, instead of to every org, is the cleanest spend control that does not touch billing policy at all. It should reduce the budget-blowout scenario where one enthusiastic team's frontier-model usage balloons an enterprise bill.

Least-restrictive access is a real security property. A user who sits on two enterprise teams inherits the union of both teams' models. That is convenient and predictable, but it means team-level policies do not isolate: access is a superset, never an intersection. Security teams should treat "assigned to a team" as "assigned to everyone in that team's blast radius."

The org layer is going away, quietly. When enterprise teams mode is enabled, org-level model settings stop applying. Any org with hand-tuned model availability that upgrades to this preview should diff its org settings against the new enterprise policy before flipping the toggle, because the old configuration does not layer - it is simply bypassed.

How It Fits With Adjacent Tools#

GitHub is building the enterprise governance layer in stages: default model enablement first, team targeting now, and more team-level controls promised. It slots into the same admin story as Copilot usage-based billing, agent PR governance, and the agent metrics review surface - the pattern is that as Copilot agents get more autonomous, GitHub keeps giving admins more precise levers over what models run, who can invoke them, and how their output is reviewed.

For teams that run Copilot alongside other providers, the same governance gap exists everywhere: any platform that exposes multiple models needs a policy layer. If your stack is multi-vendor, the questions this changelog answers (baseline, per-team grants, least-restrictive semantics, rollback) are the right checklist to apply to whatever you use instead.

Continue Reading#

• Enterprise AI coding budget blowouts: where the money goes - why frontier-model usage is the cost driver model policy should be controlling
• GitHub Copilot usage-based billing, explained - how enterprise Copilot spend is actually metered
• Agent PR governance: the review pipeline GitHub Copilot needs - the other half of safe agentic coding
• GitHub Copilot agent metrics: measuring review quality - what admins can measure once access is controlled
• GitHub Copilot Coding Agent CLI - what the agent runtime the policy applies to can do

Sources#

• Enterprise teams model policy targeting in public preview - GitHub Changelog
• Managing availability of models in your enterprise - GitHub Docs
• Default model enablement for Copilot Business and Enterprise - GitHub Changelog