GitHub announced on September 24, 2026 a new global policy for Copilot Business and Copilot Enterprise: a default that decides what happens to every eligible generally available Copilot feature an administrator has not explicitly configured. The policy can be set today and takes effect on October 22. GitHub's documentation is plain about the default: it is enabled, and if you take no action, unconfigured features switch on that day.
The set is wider than autocomplete. It covers every policy on the enterprise "Features & clients" page, plus the Copilot code review policy and the "MCP servers in Copilot" policy. That last one decides whether Copilot clients across your company can run Model Context Protocol servers at all, which is the door through which an agent reaches your tools and data. Twenty-eight days is enough time to decide it deliberately. This post is the checklist.
- 01On October 22, every eligible unconfigured GA Copilot feature follows a global default that is enabled unless you change it.GitHub's docs: "This policy is enabled by default. If you don't take action, unconfigured features will be enabled on October 22." Explicit enable or disable decisions are preserved; preview features stay opt-in.
- 02MCP servers and Copilot code review are inside the policy set.The changelog names both alongside the Features & clients page. Three policies are outside it: the data-residency and FedRAMP model restrictions, and the setting to store local sessions in the cloud.
- 03Three settings: Enabled, Disabled, or Let organizations decide.Disabled keeps current eligible features off and makes future ones need approval. Let organizations decide pushes the choice down a level, where unconfigured features then follow the organisation's own default.
- 04The right answer for MCP is usually enabled with an allowlist, which GitHub itself recommends.The enforced route is a managed-settings.json file, which is generally available; the custom-registry route is a public preview that users can bypass by editing configuration files.
01 — The changeWhat flips on October 22, in GitHub's words
The changelog entry describes a "Default policy for new features" under the AI Controls page's Copilot subpage. For 28 days it can be configured without affecting anyone's access. From October 22 it applies. The mechanics, each from the changelog or the default-availability documentation, are below.
- What the policy governsNew GA features, features that move from preview to GA, and existing GA features still marked Unconfigured.
- Three classes
- Which policies count as featuresEverything on the enterprise Features & clients page, plus Copilot code review on the Agents page and MCP servers in Copilot on the MCP page.
- Features + 2
- What happens if you do nothingThe policy is enabled by default, so unconfigured features are enabled on October 22.
- EnabledSilence is a decision
- What is preservedAny feature you have explicitly enabled or disabled. A preview you opted into keeps your choice when it reaches GA.
- Explicit choices
- What stays opt-inFeatures in preview. The policy does not apply to them.
- Previews
- Where it can be setAt the enterprise, for features marked Unconfigured; at the organisation, for features the enterprise set to Let organizations decide and the organisation has not configured.
- Two levels
- How to see your exposureA banner in policy settings shows how many eligible policies are currently unconfigured.
- One banner
The documentation states the reason for the change without saying much about risk: with the default policies on, "users benefit from the latest features and models without the need for administrator intervention". That is true, and it is also why an unconfigured MCP policy is the item to look at first.
02 — The choiceThe three settings, and the fourth one most enterprises will pick by accident
Enabled
The stated default. Right for a company that wants every GA feature the day it ships and has an allowlist for MCP servers and a review process for agents. Wrong if nobody has read the Features & clients page recently.
Disabled
The conservative setting. Nothing unconfigured switches on, and each new GA feature waits for an administrator. The cost is that a feature nobody objects to also waits, and the approval queue becomes the bottleneck.
Let organizations decide
Organisation owners choose. Note the docs' second rule: at the organisation level the default applies to features the enterprise delegated but the organisation never configured. Delegating without telling the organisations is the same as choosing Enabled for them.
Unconfigured
Not a setting, but the state most enterprises will be in on the day if the banner is not read. Treat it as a choice you are making now.
We have argued before that agent tooling should ship default-off and be turned on by a named person. Our post on the default-off change for AI review bots made that case for one GitHub setting; our census of coding-agent permission defaults shows how few vendors ship that way. This policy runs the other direction, which is why the deadline matters.
03 — The decisionWhy "MCP servers in Copilot" is the policy to decide on purpose
GitHub's MCP management documentation says the policy "defines whether MCP servers can run at all across Copilot clients", and recommends keeping it enabled while restricting the servers users can run to an approved list. That is the right shape. An MCP server is code that Copilot can call with your developers' credentials; an unrestricted policy means any server a developer adds to a client configuration runs. The incidents we track in our MCP security incident ledger are mostly servers that did more than their name suggested.
The question is therefore not enabled or disabled, but which allowlist mechanism. GitHub documents two, and is candid about the difference.
| Aspect | Managed settings file | Custom registry |
|---|---|---|
| Release phase | Generally available | Public preview; GitHub says it is not prioritised for development |
| Setup | A configuration file hosted on GitHub that applies to clients automatically | You host a registry that matches the MCP specification and serves HTTPS |
| Enforcement | Enterprise-wide settings that users cannot override; enterprise teams can be given overrides | Enterprise-wide or per organisation |
| Server matching | Name, URL or stdio command | Name or ID only; GitHub notes users can bypass it by editing configuration files |
The practical reading: if you can publish a managed-settings file before October 22, set the MCP policy to Enabled and let the file enforce the list. If you cannot, set the MCP policy to Disabled explicitly, so the October 22 default does not decide it for you, and revisit when the file is ready. Copilot code review is the second item worth an explicit answer, because it decides whether an agent comments on pull requests across every repository the policy covers.
04 — The checklistThe 28-day checklist
Four weeks, one owner per week. The dates run from the September 24 announcement to the October 22 effective date.
"From October 22, any eligible Copilot feature we have not explicitly configured will turn on, including MCP servers and code review. The Features & clients page shows how many are unconfigured today. We will decide the MCP allowlist by October 8 and set the global default by October 15."
05 — The edgesWhat is not affected, and what already changed
Three policies are excluded by name: the two restrictive model policies on GitHub's data-residency enterprise offering that limit Copilot to data-residency or FedRAMP models, and "Store local sessions in the Cloud" for Copilot CLI and VS Code. Preview features are outside the policy entirely.
A separate default-availability policy for models is already active. Models you have not configured carry a "Delegate to Default Policy" label and inherit the default when released. Four classes are disabled by default whatever that policy says: pre-GA models; open-weight models, which the docs list as DeepSeek, Kimi K2.7 Code and Kimi K3; models not covered by GitHub's data retention agreement, listed as Claude Fable 5 and Claude Fable 5.1; and, for restricted enterprises, any model that does not meet the data-residency or FedRAMP restriction.
Nothing in the announcement concerns individual Copilot plans; it is scoped to Business and Enterprise. The changelog says the policy lives in both enterprise and organisation Copilot settings, so an organisation without an enterprise account should check whether it has the same decision to make. Our AI transformation practice runs this inventory as part of agent governance reviews.
06 — ConclusionThe default is enabled, and the policy set includes the agent doors
Read the unconfigured count this week, set MCP and code review explicitly, and choose the global default before October 22 rather than inheriting it
Most of the features that switch on will be welcome. The two that decide what an agent can reach deserve a named decision, and GitHub has given four weeks to make it.