Picture two teams using GitHub Copilot. One reviews each new capability before making it available. The other moves quickly once a feature is generally available. Both approaches can be reasonable. The trouble begins when nobody owns an unconfigured setting and the platform's default becomes the decision.
In a September 24 announcement, GitHub introduced a global default policy for generally available Copilot features and supported client capabilities in Business and Enterprise settings. Administrators can choose to enable them, disable them, or let organizations decide. The setting is available now; its effect on eligible, unconfigured features begins October 22, 2026.
The distinction matters. GitHub is not saying every Copilot feature changes access today. Administrators have 28 days to set a policy before it starts governing the features that qualify. GitHub's documentation adds a consequential detail: the initial default is Enabled. Without an administrator changing it, eligible unconfigured features will be enabled on October 22.
What the default will cover
Once effective, eligible features still marked “Unconfigured” will follow the selected global policy. Existing explicit decisions to enable or disable a feature remain in place. Preview features remain opt-in, and a preview already adopted keeps that choice if it later reaches general availability.
GitHub says the scope includes capabilities on its “Features & clients” page, the Copilot code review policy under Agents, and the policy for MCP servers in Copilot. Its documentation describes eligibility and exceptions. A default policy, then, is not one switch for everything branded Copilot.
For a technology leader, the more useful question is not simply “on or off?” It is who owns the decision when a new capability arrives. Delegating to organizations may fit a company whose teams have distinct needs and mature controls. A central default may fit one with shared requirements for security, data handling or compliance. That is a governance judgment, not an automatic argument for the most restrictive option.
A review worth doing before October
I would start with settings that are still unconfigured, particularly where Copilot can work with project context, review code or connect to outside tools. For each, name the decision owner, record the reason, and decide when to revisit it. Otherwise, “unconfigured” can quietly start looking like “approved.”
This release is a reminder that AI governance does not end when licenses are purchased. As a platform changes, its defaults become product decisions with operational consequences. The period before October 22 gives teams a useful chance to make that decision themselves, while they still know they are making it.
Sources: GitHub's announcement and its default availability documentation.