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

TL;DR
GitHub Copilot enterprise model policy targeting lets admins set a company-wide model baseline and grant extra models to teams. How the preview works.
Last updated: July 31, 2026
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.
FAQ#
What is GitHub enterprise team model policy targeting?#
It is a Copilot feature in public preview, announced July 31, that lets enterprise admins set a baseline of Copilot models for the whole enterprise and then grant additional models to specific enterprise teams. It is enabled through an Enterprise teams mode toggle under Models on the Copilot page.
What do the Enabled, Disabled, and Optional model states mean?#
Enabled models are available to all enterprise members, Disabled models are not available to any member, and Optional models are available only when assigned to an enterprise team.
What happens when a user belongs to more than one enterprise team?#
Evaluation is least-restrictive: if a user gets a model from any single enterprise team, they have access to it everywhere, across every org they belong to. Access is the union of their teams' models, never the intersection.
Do organization-level Copilot model settings still apply?#
No. When enterprise teams mode is on, organization-level model settings no longer apply and the enterprise policy becomes the only policy. The post recommends diffing org settings against the new enterprise policy before flipping the toggle. During the preview you can reset to your previous configuration.
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
- The September policy reset: prepaid seats, unified agent experience, Balanced by default
- GitHub Copilot Coding Agent CLI - what the agent runtime the policy applies to can do
- Gemini 2.5 Pro and Gemini 3 Flash Deprecated in GitHub Copilot: What to Switch To
Sources#
Get the next deep dive like this in your inbox
One email a week on News and the rest of the AI dev stack. Free.
Read next
Enterprise AI Coding Budget Blowouts: What Uber and Microsoft Teach Us
Enterprise AI coding budget lessons: Uber spent its 2026 AI tools budget by April and Microsoft is canceling Claude Code licenses. Spend controls that work.
8 min readGitHub Copilot's New Usage-Based Billing: What Changed June 1 and What It Costs Now
GitHub Copilot moved to AI Credits billing on June 1. What changed, how Copilot Max and budgets work, and how costs compare to Claude Code and Codex for teams.
8 min readAgent PR Governance: The New Rules for Copilot Reviews
Agent PR governance for Copilot code review: a five-layer policy stack for agent-authored pull requests, from agent validation and review depth to attribution.
8 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.







