GitHub Copilot Now Lets Enterprise Admins Push Team-Level AI Policies

GitHub rolled out team-level specialization for Copilot enterprise managed settings on 3 August 2026. Administrators can now mark individual keys in their managed-settings.json file as overridable, letting specific teams set their own Copilot configuration while the enterprise-wide defaults remain the ceiling for everything else. The change is aimed at large organizations that need governance flexibility without routing every config tweak through a central admin.

What happened

Detail	Value
Release date	3 August 2026
Feature name	Enterprise team specialization for managed settings
Required license	Copilot Business or Copilot Enterprise
Supported clients (today)	VS Code, Copilot CLI, Copilot App, Copilot cloud agent
Config file location	copilot/managed-settings.json (enterprise) and copilot/teams/ (per team)
Team mapping file	team-mappings.json

GitHub’s enterprise Copilot governance previously worked as a single policy stack: one config file pushed to everyone. The new system lets admins flag individual JSON keys as overridable. When a key is marked overridable, the team’s chosen value takes effect for that team’s members. When the team leaves it unset, the enterprise default kicks in automatically.

Keys that are not marked overridable remain locked at the enterprise level. Compliance-critical settings stay untouched regardless of what any team file says.

How the configuration actually works

The syntax in copilot/managed-settings.json uses an { "overridable": } wrapper on the key you want to open up. Two example keys called out in the changelog are disableBypassPermissionsMode and model, both of which can be set to "unmanaged" in a team’s file to give that team its own defaults.

For plugins and marketplaces, the behavior is additive rather than substitutive. The keys enabledPlugins and extraKnownMarketplaces let teams add on top of the enterprise baseline. A team cannot remove what the enterprise has mandated; it can only extend it.

Multi-team membership rule

If a user belongs to more than one team, GitHub combines all applicable team-level settings using the least restrictive value per key, then applies that combined result beneath the enterprise file. The enterprise file always wins at the ceiling; teams compete at the floor.

Setting it up: what to do

1. Configure your base copilot/managed-settings.json and mark the keys you want teams to control using the { "overridable": } syntax.
2. Create per-team settings files under copilot/teams/. Only include keys you have already marked overridable.
3. Edit team-mappings.json to pair each settings file with one or more team slugs. One file can serve multiple teams (for example, a single ai-users.json for all teams that have completed training).
4. Set your .github-private repository to internal visibility so team members can open pull requests to suggest config updates rather than emailing admins.
5. Test against VS Code, Copilot CLI, and the Copilot App. Broader client support via the Copilot SDK is coming but not yet available.

Why it matters

For organizations managing dozens of teams, a single Copilot policy either locks everyone down to the strictest requirements or exposes everyone to the loosest ones. This change breaks that trade-off. A security team can stay on locked-down defaults while an AI Pioneers group gets to pick their own model and bypass permissions.

The pull-request workflow for config suggestions is also worth noting. Instead of IT fielding ad-hoc requests, teams propose changes via PRs against a known file. That keeps an audit trail and distributes the governance work without removing admin control. For businesses thinking about how to scale AI integration across different departments, this pattern is worth borrowing beyond GitHub itself.

GitHub’s framing that “maintaining effective guardrails is a shared responsibility” reflects a broader shift in enterprise AI governance: central policy teams set the floor and ceiling, individual teams fill in the space between. We have covered similar themes in our look at what business leaders need to know about open-weight AI models, where governance and model choice intersect in much the same way.

Our take

This is a genuinely practical improvement for any organization above about 50 Copilot seats. The previous all-or-nothing policy model was always going to create friction between security teams (who want tight controls) and product developers (who want flexibility). The overridable key pattern resolves that without requiring a new tool or a separate admin portal.

The additive-only rule for plugins is smart. It prevents teams from silently removing enterprise-mandated integrations while still letting them add the tools specific to their role. That is the right default for a compliance context.

The one gap worth watching: SDK-based client support is still in progress. If your teams use Copilot surfaces outside VS Code and the CLI, the team-level policies may not yet apply uniformly. Do not treat the rollout as complete until GitHub confirms full SDK coverage.

If you are scoping how to govern AI tools across teams with different risk profiles, talk to us about how we structure those rollouts for clients.

Source: GitHub Changelog