- GitHub is enforcing a global default for unconfigured generally available Copilot features on Business and Enterprise plans, with rollout running through October 26.
- The change happens once. Settings an administrator has explicitly enabled or disabled stay as they are. Blank settings take the default.
- Leaders should find out who owns Copilot settings, what the default is, and which features and MCP servers are still unconfigured.
A blank setting is still a decision
Most software has settings nobody touches. They sit at "unconfigured" for years. People assume that means nothing was decided. GitHub's latest Copilot change shows why that is wrong. When a setting is blank, a default can fill it.
What GitHub announced
In September, GitHub announced a default policy for Copilot features. It covers features that are out of preview. It applies to Copilot Business and Copilot Enterprise plans. It also covers supported client capabilities.
On October 22, GitHub said enforcement was starting. The rollout runs through October 26. GitHub says it "may take effect at different times for different enterprises and organizations." Today is the last day of that window.
How the policy works
Each eligible feature has a policy setting. An administrator can turn it on, turn it off, or leave it unconfigured. Under the new policy, unconfigured features take the global default. GitHub lists three possible defaults: Enabled, Disabled, or Let organizations decide.
The policy covers eligible settings under "Features & clients" and "MCP servers in Copilot." MCP servers are connectors. They let an AI assistant reach outside tools and data.
Administrators can check the setting under AI Controls, then Copilot, then "Default policy for new features."
GitHub sets three limits. First, explicit choices stay. If an administrator enabled or disabled a feature, the rollout does not change it.
Second, preview features remain opt-in. If you opted into a preview, GitHub keeps your choice when it reaches general availability. Otherwise, the default applies once the feature becomes eligible.
Third, the change happens once. Later changes to the default policy will not alter feature policies that are already set.
Why the one-time part matters
The one-time rule is the detail to watch. Once a blank is filled, it becomes a set choice. Changing the default later does not reopen it. The moment the blank turns into a value is the moment that counts.
This shows how control over AI tools can drift with no one deciding. An administrator who never opened these settings still made a choice. They left it to the default.
A security lead who asks why a feature is on will want a better answer than "it was left blank."
One caveat. The changelog does not say which default applies to an enterprise that never picked one. It also does not say when the rollout reaches a given organization. Your own settings page has to answer those questions.
Questions to put to your team
Start with ownership. Who in your organization manages Copilot policy? Do they know the rollout window closes today?
Then ask for evidence. What does "Default policy for new features" show today? Which settings under "Features & clients" and "MCP servers in Copilot" were unconfigured? What value did each one take?
Treat MCP servers as their own decision. They connect AI assistants to other systems. A team should choose that setting on purpose, not inherit it.
Finally, set explicit values where you have a view. GitHub says explicit choices are preserved. A recorded choice with a named owner is not changed by this rollout.
A setting nobody chose is still a decision. The open question is who made it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub.
