GitHub Copilot enterprise governance in 2026: 6 managed settings keys and the new team override rules

Summary. On 3 August 2026 GitHub shipped enterprise team specialization for Copilot managed settings, letting an enterprise mark individual configuration keys as overridable so a named team can supply its own value. Three days earlier, on 31 July 2026, GitHub opened a separate public preview for enterprise teams model policy targeting, with most enterprise customers getting the opt-in toggle on 3 August. Both build on managed-settings.json, which reached general availability on 1 July 2026 with 5 supported keys; the reference documentation now lists 6. The mechanics matter more than the announcement. Keys you do not mark overridable set a ceiling that teams cannot move. Overridable and unmanaged keys set a floor. When a user belongs to several teams, GitHub combines the team-level settings using the least restrictive value for each key, then applies them beneath the enterprise file. Model policy adds a third state alongside Enabled and Disabled: Optional, meaning available to assign to enterprise teams, with the same least-restrictive evaluation. This is also a spend control. Copilot Business is $19 per user per month including $19 in monthly AI Credits, and Copilot Enterprise is $39 per user per month including $39 in credits, after GitHub replaced premium request units with token-metered AI Credits on 1 June 2026. Which models a team can reach is now the same lever as what a team can spend. The configuration is fetched when a user authenticates, held in memory and refreshed hourly, so a policy change is not instant.

What shipped, in what order

The four announcements land inside five weeks and each one changes a different layer.

Date	Change	Status	What it moved
1 July 2026	managed-settings.json generally available	GA	5 keys, enforced in VS Code and Copilot CLI
27 July 2026	Managed settings extended to the Copilot app and Copilot cloud agent	Release	Enforcement surface
31 July 2026	Enterprise teams model policy targeting	Public preview	Model access moves from org level to team level
3 August 2026	Enterprise team specialization for managed settings	Release	Per-team values for marked keys

Read as a sequence, GitHub is moving Copilot governance off the organization and onto the enterprise team. GitHub says so directly in the 31 July post: "This public preview is the first step in a broader shift toward team-level governance. Historically, model access has been managed at the organization (i.e., resource) level, but enterprise teams give you finer grained, user-based control that better maps to how people actually work: by role, training level, or function."

For a platform team, that is the planning signal. Any Copilot policy you have expressed through organization membership is on a path to being expressed through enterprise teams instead.

The file layout

Everything hangs off one repository, and the path is exact.

Select a source organization in the AI Controls tab of enterprise settings, or set it through the REST API. Copilot then looks for managed-settings.json in that organization's .github-private repository, at the path copilot/managed-settings.json on the default branch. There is backward compatibility for the older .github/copilot/settings.json location. If you already configured a source organization for custom agents, this uses the same .github-private repository.

Team specialization adds two more paths inside the same repository:

• copilot/teams/ holds one settings file per specialization, containing only the keys you marked overridable.
• team-mappings.json pairs each settings file with one or more team slugs, so a single file can cover several teams.

GitHub's own suggestion in the 3 August post is to set the .github-private repository to internal visibility and let engineers open pull requests against the configuration: "Set your AI standards source .github-private repository to internal visibility and let your users open pull requests to suggest changes that keep their specialized governance configuration up to date."

That is the operational point most teams will miss. Governance stops being a ticket to the platform team and becomes a reviewed pull request, which is the only version of this that survives contact with a thousand engineers.

The six keys the reference documents

GitHub's enterprise managed settings reference lists the supported keys. The page carries a preview warning: "This feature is in public preview and subject to change."

Key	Type	Accepted values	What it controls
permissions.disableBypassPermissionsMode	string	"disable"	Disables bypass or allow-all behaviour
enabledPlugins	object	Key format PLUGIN-NAME@MARKETPLACE-NAME, value true	Enables specific plugins
extraKnownMarketplaces	object	Marketplace object with source.source and source.repo	Adds marketplaces users can reach
strictKnownMarketplaces	array	Marketplace objects with source values	Restricts installs to listed marketplaces
model	object	default set to a supported model name	Default model governance
telemetry	object	enabled, endpoint, protocol, captureContent, lockCaptureContent, serviceName, resourceAttributes, headers	OpenTelemetry export for VS Code

The GA announcement on 1 July listed five: extraKnownMarketplaces, enabledPlugins, strictKnownMarketplaces, disableBypassPermissionsMode and model. telemetry is the addition, and GitHub states that "additional keys will be continuously added over time".

The reference gives one complete example:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  },
  "enabledPlugins": {
    "my-plugin@agent-skills": true
  },
  "extraKnownMarketplaces": {
    "agent-skills": {
      "source": {
        "source": "github",
        "repo": "OWNER/REPO"
      }
    }
  },
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "OWNER/REPO"
    }
  ],
  "model": {
    "default": "MODEL-NAME"
  },
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.com",
    "protocol": "otlp-http",
    "captureContent": false,
    "lockCaptureContent": true,
    "serviceName": "copilot",
    "resourceAttributes": {
      "deployment.environment": "production"
    },
    "headers": {
      "Authorization": "Bearer TOKEN"
    }
  }
}

Two details in that block deserve attention before you copy it. The "git" plus url source variant is documented only for strictKnownMarketplaces, not for extraKnownMarketplaces. And lockCaptureContent paired with captureContent: false is the combination that stops a team from turning prompt content capture back on, which is the setting your privacy review will ask about.

How the override model actually resolves

The 3 August post spells out the merge rules, and they are not the usual "most specific wins".

Mark a key overridable in copilot/managed-settings.json using the { "overridable": ... } syntax. An overridable key takes the team's value when the team sets one, and falls back to the enterprise default when the team leaves it unset. Keys you do not mark stay an enterprise-level decision.

Behaviour	Applies to	Effect
Ceiling	Keys not marked overridable	Team cannot change the value; compliance settings stay locked
Floor	Unmanaged or overridable keys	Enterprise baseline is the minimum; teams can go above it
Additive	enabledPlugins, extraKnownMarketplaces	Team additions layer on without weakening the enterprise baseline
Least restrictive	A user in multiple teams	Team values are combined per key using the least restrictive one
Enterprise last	All keys	Combined team settings are applied beneath the enterprise file

GitHub's worked example is a team that gets to choose its own model and bypass behaviour: set "disableBypassPermissionsMode": "unmanaged" and "model": "unmanaged" in that team's settings file, and members of that team get the specialization while every other team inherits the enterprise defaults.

The least-restrictive rule is the one to design around. If an engineer sits in both a locked-down payments team and a permissive AI pioneers team, the permissive value wins for every key both teams set. Team membership is now a security boundary, and sprawling team membership quietly widens it. Audit who is in which enterprise team before you write a single settings file.

Model policy targeting: three states, not two

The 31 July preview changes how model access is granted. At the enterprise level a model can now be:

• Enabled: available to all members of the enterprise.
• Disabled: not available to any member of the enterprise.
• Optional: available to assign to enterprise teams.

Optional is the new one, and it is what makes role-based model access possible without delegating to organization admins. Evaluation is least restrictive here too: if a user gets a model from any one enterprise team, that user has the model everywhere.

Turning it on is a toggle labelled Enterprise teams mode on the Copilot page under Models. Three consequences follow, and all three are worth writing into the change record:

1. When enabled, model access is managed at the enterprise level and through enterprise teams, and organization-level model settings no longer apply.
2. During the preview you can roll back to reset the policy to its previous configuration.
3. If your enterprise does not use Enterprise Managed Users, members may hold Copilot licences from other enterprises. In enterprise teams mode, only your enterprise's model policies apply to users on a licence assigned from your enterprise, and restrictions from any other enterprise do not apply.

GitHub's stated migration path is to build the teams first: create enterprise teams and assign Optional models to them before enabling enterprise teams mode, so the user-to-model mapping already exists when organization settings stop applying.

Where the documentation has not caught up

This is the part that will cost you an afternoon if nobody warns you.

As of 6 August 2026, GitHub's enterprise managed settings reference documents the six keys and a precedence order, but it does not mention overridable, copilot/teams/, team-mappings.json, or any team layer at all. The team specialization mechanics exist only in the 3 August changelog post and in the enterprise-cloud version of the configuring guide it links to. If your platform team standardises on the reference page, it will conclude the feature does not exist.

The reference page also contradicts itself on precedence. It lists the order as server-managed settings, then MDM-managed settings, then file-based settings, then user-level settings. The prose immediately below says the opposite: "MDM-managed settings take precedence. If MDM-managed settings are not available, clients apply server-managed settings before file-based settings." Do not build a policy model on either half alone. Test the actual resolution on a pilot team and record what you observe.

The real cost here is usually the verification, not the configuration.

Enforcement surface and refresh timing

Two operational facts change how you roll this out.

At GA on 1 July, managed-settings.json was enforced in VS Code and Copilot CLI. The 3 August post widens that to VS Code, Copilot CLI, the Copilot app and Copilot cloud agent, for users holding a Copilot Business or Copilot Enterprise licence issued from the enterprise or one of its organizations. GitHub says it is working to extend support across all Copilot clients through the Copilot SDK, which is a plain statement that coverage is not yet complete. Any client outside that list is currently ungoverned by this file.

The refresh model is equally important. Configuration is fetched from the server every time a user authenticates, stored in memory, and refreshed hourly. A policy tightening is therefore not instantaneous across a fleet, which matters when the change is a response to an incident rather than a planned rollout.

Why this is a cost control, not just a security control

Model policy and spend are now the same dial.

GitHub replaced premium request units with GitHub AI Credits on 1 June 2026, billing token consumption including input, output and cached tokens at each model's published API rate. Seat prices did not move: Copilot Business stayed at $19 per user per month with $19 in monthly AI Credits, and Copilot Enterprise at $39 per user per month with $39 in credits. Existing Business and Enterprise customers received promotional included usage of $30 and $70 in monthly AI Credits respectively for June, July and August 2026.

Mario Rodriguez, Chief Product Officer at GitHub, set out the reasoning in the announcement: "Today, a quick chat question and a multi-hour autonomous coding session can cost the user the same amount."

Two mechanics follow from that. Included usage is pooled across a business rather than stranded per user, and admins can set budgets at enterprise, cost centre and user levels, choosing whether to allow overage at published rates or cap spend. Also note that Copilot code review consumes GitHub Actions minutes in addition to AI Credits, billed at the same per-minute rates as other Actions workflows, so a review-heavy rollout shows up on two lines.

Put those together with Optional model states and the picture is clear: granting an expensive frontier model to a 12-person team instead of a 900-person enterprise is now a one-line policy change. Teams already tracking spend through Copilot September 2026 model deprecations should sequence the two changes together, because a deprecation forces a model reassignment anyway.

A rollout plan that does not break the fleet

Step	Action	Why this order
1	Audit enterprise team membership and remove stale members	Least-restrictive merging makes membership a security boundary
2	Create the .github-private source organization mapping in AI Controls, or set it via the REST API	Nothing loads until the source org exists
3	Commit copilot/managed-settings.json with compliance keys unmarked	Unmarked keys are the ceiling you actually want
4	Mark only the keys you are willing to devolve as overridable	Every overridable key is a floor, not a rule
5	Create enterprise teams and assign Optional models before flipping Enterprise teams mode	Org-level model settings stop applying at the flip
6	Pilot on one team, verify resolution against the contradictory precedence text	The docs will not settle it for you
7	Set the repository to internal and open the configuration to pull requests	Governance survives only if teams can propose changes
8	Wire budgets at enterprise, cost centre and team level	Model access and spend are the same lever

If you are still deciding which agent controls belong at the platform layer at all, the broader pattern is covered in our guide to enterprise AI agent governance layers and in the wider view of enterprise AI agents in production.

India-specific considerations

Three points change the calculation for Indian engineering organisations and global capability centres.

Team-level model policy maps cleanly onto the GCC structure. A captive centre running several client-facing pods can now hold a conservative enterprise baseline and grant a frontier model only to the pod whose client contract permits it, without creating a separate GitHub organization per client. That was the usual workaround, and it carried its own administrative cost.

The telemetry key is where the data-protection review lands. captureContent controls whether prompt content is exported to your OpenTelemetry endpoint, and lockCaptureContent stops a team from re-enabling it. If prompts can carry personal data, that export is a processing decision under the Digital Personal Data Protection Act 2023, and the engineering controls are set out in our DPDP Act engineering playbook for Indian startups.

Billing is the third. AI Credits are consumed at each model's published API rate, so a team on a costly model burns a shared pool faster regardless of where the engineers sit. Budgets at the cost-centre level are the mechanism to keep an offshore delivery pod from silently consuming an onshore team's credits.

FAQ

What is the difference between a ceiling key and a floor key?

A key you do not mark overridable in the enterprise file sets a ceiling: teams cannot change it, which keeps compliance-critical settings locked. Unmanaged or overridable keys set a floor, meaning the enterprise value is a baseline that a team can raise through its own settings file under copilot/teams/.

What happens if an engineer belongs to two enterprise teams?

GitHub combines the team-level settings using the least restrictive value for each key, then applies that combination beneath the enterprise file. The same rule applies to model policy: if a user receives a model from any one enterprise team, that user has access to the model everywhere. Team membership therefore behaves as a security boundary.

Which Copilot clients enforce managed settings?

As of 3 August 2026, the configuration is enforced in VS Code, Copilot CLI, the Copilot app and Copilot cloud agent, for users holding a Copilot Business or Copilot Enterprise licence issued from the enterprise or one of its organizations. GitHub states it is working to extend support across all Copilot clients through the Copilot SDK.

How quickly does a settings change take effect?

Not immediately. Copilot fetches the configuration from the server each time a user authenticates, stores it in memory, and refreshes it hourly. Plan a policy tightening around that hour rather than assuming a commit to the default branch propagates to every active session straight away.

Where exactly does the configuration file live?

In the .github-private repository of the organization you select as the AI standards source, at copilot/managed-settings.json on the default branch. The older .github/copilot/settings.json path retains backward compatibility. Team specialization files sit under copilot/teams/, with team-mappings.json pairing each file to team slugs.

Does enabling enterprise teams mode break organization-level policy?

It replaces it. When Enterprise teams mode is on, model access is managed at the enterprise level and through enterprise teams, and organization-level model settings no longer apply. GitHub allows a rollback during the preview to reset the policy to its previous configuration, so build the teams and assign Optional models before flipping the toggle.

How does model policy relate to Copilot spend?

Directly. Since 1 June 2026 Copilot usage consumes GitHub AI Credits metered on input, output and cached tokens at each model's published API rate. Copilot Business includes $19 in monthly credits and Copilot Enterprise $39, pooled across the business, with budgets settable at enterprise, cost centre and user levels.

Is the reference documentation complete for this feature?

No. As of 6 August 2026 the enterprise managed settings reference lists six keys and a precedence order but does not mention overridable, copilot/teams/ or team-mappings.json. It also contradicts itself on precedence, listing server-managed settings first while the prose says MDM-managed settings take precedence.

How eCorpIT can help

eCorpIT runs Copilot and coding-agent rollouts for engineering organisations from Gurugram as a senior-led team, CMMI Level 5 assessed and ISO 27001:2022 certified. The work here is mostly the parts the changelog does not cover: auditing enterprise team membership before least-restrictive merging turns it into a security boundary, writing the ceiling and floor split so compliance keys stay locked, verifying real precedence on a pilot team when the documentation disagrees with itself, and wiring model policy to cost-centre budgets so spend and access move together. If you want the rollout designed, piloted and documented as one programme, talk to our team.

References

1. GitHub Changelog, Enterprise team specialization for managed settings, 3 August 2026.
2. GitHub Changelog, Enterprise teams model policy targeting in public preview, 31 July 2026.
3. GitHub Changelog, Enterprise managed-settings.json is generally available, 1 July 2026.
4. GitHub Docs, Enterprise managed settings reference, accessed 6 August 2026.
5. GitHub Docs, Configuring enterprise-managed settings, accessed 6 August 2026.
6. Mario Rodriguez, GitHub Blog, GitHub Copilot is moving to usage-based billing, 27 April 2026.
7. GitHub Changelog, Enterprise managed settings in the GitHub Copilot app and Copilot cloud agent, 27 July 2026.
8. GitHub Changelog, Upcoming August 2026 model deprecations in GitHub Copilot, 31 July 2026.
9. GitHub Changelog, Customize the reasoning level for Copilot cloud agent, 3 August 2026.
10. GitHub Changelog, Trigger Copilot automations with comments, 3 August 2026.
11. GitHub Community, Enterprise-managed settings for Copilot Business and Copilot Enterprise, discussion 199139, accessed 6 August 2026.
12. GitHub Community, Enterprise teams model policy targeting, discussion 203163, accessed 6 August 2026.
13. Visual Studio Code Docs, Manage AI settings in enterprise environments, accessed 6 August 2026.
14. GitHub Docs, About billing for GitHub Copilot in organizations and enterprises, accessed 6 August 2026.

Last updated: 6 August 2026.