A default is still a product decision. GitHub has introduced a global policy for how eligible, unconfigured Copilot features behave in Business and Enterprise plans. Administrators can configure it now, but the feature policy starts applying on 22 October 2026.
What GitHub announced on 24 September
The GitHub announcement describes three choices: Enabled, Disabled, or Let organizations decide. The policy covers eligible generally available features and supported client capabilities. It also reaches the Copilot code-review policy on the Agents page and the MCP-servers-in-Copilot policy.
The announcement date is 24 September. The effective date is 22 October. During the 28-day configuration window, changing the new default does not yet change users’ feature access.
What happens on 22 October
GitHub’s default-availability documentation says the feature policy is enabled by default. If an administrator takes no action, eligible features still marked Unconfigured will be enabled when the policy becomes active.
Explicit choices remain explicit: an individually enabled or disabled feature is not overwritten by the global default. Preview features remain opt-in. If a preview later reaches general availability, GitHub says the existing choice is preserved.
This does not mean every Copilot capability will suddenly turn on. Eligibility, existing decisions and documented exceptions matter. Two listed exceptions are restrictive model policies on GHE.com and the policy for storing local Copilot CLI and VS Code sessions in the cloud.
Features and models are separate controls
The documentation distinguishes the upcoming feature default from the model default, which is already active. That difference matters during review: a team can have a conservative feature posture while separately deciding which released models are available.
The enterprise policy guide also notes that policies follow the organization or enterprise providing the Copilot license. When a user has access through multiple organizations, conflict rules can affect the result. Direct enterprise assignments need separate attention because “Let organizations decide” does not govern them in the same way.
Engineering analysis: replace “Unconfigured” with intent
For an engineering leader, the risky state is not necessarily Enabled. It is ambiguity. Export or inventory every policy still marked Unconfigured, then assign an owner and an explicit decision based on the feature’s actual access to code, repositories, external tools and data.
Treat MCP servers as integration boundaries, not merely UI switches. Review authentication, scopes, tenant context, tool descriptions and auditability. The same principle appears in reliable API contracts: an implicit fallback can become a production contract even when nobody consciously approved it.
A useful review classifies capabilities into three groups: safe for broad enablement, suitable for a controlled pilot, and prohibited pending further evidence. This classification is editorial guidance, not a GitHub requirement.
A practical checklist before the deadline
First, capture the current policy state and the number of eligible unconfigured items shown in GitHub’s banner. Choose the enterprise default, then set exceptions explicitly. Test at least one organization, one directly assigned user if applicable, and a user with overlapping licenses.
Next, document who may change AI controls and monitor the audit log for policy changes. Communicate the effective date to repository owners. Finally, schedule a verification after 22 October to compare intended and effective access.
Do not use the default policy as a substitute for authorization or renewed identity checks. Sensitive operations still need their own controls; GitHub’s separate proof-of-presence update illustrates that boundary.
The product lesson is simple: defaults reduce administration, but they also encode governance. The safest rollout turns every important default into a visible, owned decision.
Official references
These references document the tools discussed. Examples and design decisions are illustrative and should be adapted to the project and its versions.
Prepared by: Noor Yasser
Working through a similar engineering challenge?
I help teams turn architecture decisions into a clear scope and dependable, reviewable implementation.
