GitHub Copilot Switches to Default-Allow on October 22: Unconfigured Features Will Turn On Automatically

What happened: one default, two philosophies

On September 24, GitHub published a seemingly boring but far-reaching announcement in its official changelog: a new global default policy — "Default policy for new features" — for Copilot Business and Copilot Enterprise. From the announcement date, administrators get 28 days to configure it; starting October 22, it takes effect: every GA feature still sitting in the "Unconfigured" state will automatically follow this global default.

The policy offers three options: Enabled — current and future eligible features are available to users by default; Disabled — they stay unavailable, and new features require administrator approval one by one; Let organizations decide — the decision is delegated to organization admins under the enterprise. The critical detail hides in the docs: the policy itself defaults to Enabled. In other words, if you do nothing, Copilot features you never configured will be switched on automatically after October 22.

The scope is broader than it looks: every policy on the enterprise "AI Controls → Copilot → Features & clients" page, plus the Copilot code review policy on the "Agents" page and the MCP servers in Copilot policy on the "MCP" page. The good news: preview features still require explicit opt-in and won't be auto-enabled; features you've explicitly enabled or disabled won't be overridden, GitHub promises. But the "Unconfigured" middle state — where countless admins left rows untouched and never looked back — now has a defined meaning: follow the default, and the default is "on."

To feel the weight of this change, some history helps. In November 2025, GitHub fixed a bug in how enterprise and organization policies interact: the corrected rule was that when an enterprise policy is Unconfigured, the matching organization policy defaults to Disabled — "unconfigured" meant "off," a default-deny security philosophy. Then on July 29 this year, GitHub did the same thing on the "models" side: a default-enablement policy for models, enforced starting August 26, automatically switching on unconfigured models. Now it's features' turn. From default-deny to default-allow, GitHub has completed a reversal of governance philosophy within a year.

Why this time is different: MCP meets default-allow

If you only look at "new features turn on automatically," this seems like mere admin convenience. But pull one item out of the scope list and the flavor changes: "MCP servers in Copilot" is also covered by the default policy. MCP (Model Context Protocol) is the channel through which agents call external tools and data sources. Auto-enabling the MCP server policy means the set of external services an agent can reach could expand without explicit administrator approval. In an era when agents can read files, run commands, and call APIs, "default-allow" for external tool access is a security decision to take seriously — not a convenience feature that "saves a few clicks."

The timing coincidence is even more telling. Around this announcement, GitHub issued three waves of model retirement notices in quick succession: on September 3, deprecating Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code, and Claude Opus 4.7 effective October 2; on September 18, deprecating GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini, Grok 4.5, and Gemini 3.7 Flash effective October 19. The replacements are uniformly newer models (Gemini 3.8 Flash, Kimi K3, GPT-5.6 Sol/Luna, Grok 4.6, Claude Opus 5). Read together with the default-enablement policy, GitHub's intent is clear: use the lever of "defaults" to accomplish two things at once — push users toward newer models and push new features toward broader enablement. It's a very "platform" way of operating: no mandates, no pop-ups — just the gravity of defaults pulling the ecosystem where the platform wants it to go.

Zoom out, and this is the same industry theme in different companies' variations. On September 22, JetBrains launched Air, productizing "governance" for enterprises; GitHub instead bakes "governance" into "defaults," writing it directly into platform rules. One says "here are tools to govern with," the other says "the defaults are already set for you." Neither approach is inherently superior, but both point to the same judgment: agents are moving from "personal toys" to "organizational infrastructure," and the default configuration of infrastructure is the shape of power. By setting the default to Enabled, GitHub is effectively making a value judgment on behalf of hundreds of thousands of organizations' admins: that the benefit of new features outweighs the risk of enabling them unreviewed. Admins can change it — but "not changing it" has itself become a choice.

What admins should do now: three checklists

If you administer Copilot Business or Enterprise, three things are worth doing before October 22. First, inventory your "Unconfigured" backlog. Check the banner on the AI Controls page — GitHub shows how many eligible policies are currently unconfigured. For each one, ask: if it gets switched on automatically on October 22, am I okay with that? Copilot code review (agents auto-reviewing code) and MCP servers (agents reaching external services) deserve special attention — their "auto-enable" is not the same risk class as some UI feature's "auto-enable."

Second, decide your default philosophy. There's no standard answer among the three options, but there are fitting scenarios: for security-sensitive, heavily regulated industries (finance, healthcare, government), Disabled is the more responsible choice — reviewing new features one by one is slower, but every enablement is an explicit decision. For R&D organizations optimizing for speed, Enabled paired with regular policy audits may fit better. Let organizations decide suits conglomerates, letting each business line follow its own risk appetite. The worst choice is "haven't thought about it" — because the default outcome of "haven't thought about it" is Enabled.

Third, look at model retirements and feature policy together. The two retirement waves on October 2 and October 19 mean your team's model picker will change over the coming weeks; if internal docs, prompt templates, or evaluation baselines hardcode old model names (say, Gemini 3.6 Flash or GPT-5.5), now is the time to clean up. In the new default-enable world, model and feature changes will reach your users faster with fewer explicit notices — governance cadence has to shift from "approval-based" to "patrol-based."

A final word for everyday developers: after October 22, if you suddenly notice unfamiliar features in Copilot, don't be surprised — ask your admin first. Odds are GitHub didn't sneak them in; your organization's "Unconfigured" simply became "on" that day. Defaults are a letter the platform writes to everyone. Most people just never read it.

One level deeper: the power of defaults, and the age of "patrol-based" governance

Behavioral economics has a classic concept called the "default effect": people tend to accept the default option — not because of careful deliberation, but because changing it is effort. GitHub's choice of "default enable" is a large-scale default-effect experiment, except the subjects are hundreds of thousands of organizations' admins. GitHub is betting that most admins won't review every item within 28 days, so the enablement surface of new features expands naturally. This isn't conspiracy thinking; it's platform-operations common sense — default search engines on phones and default privacy settings in browsers all play the same game.

But Copilot's default effect has a special variable: the "users" here aren't individuals, they're enterprises. Enterprise admins and individual users decide by different logic: individuals trade privacy for convenience; enterprises trade compliance risk for convenience. When the "default-on" object shifts from "small UI features" to "agents auto-reviewing code" and "agents reaching external MCP services," the cost of the default effect shifts from "one more button" to "one more attack surface." Including MCP servers in Copilot in the default policy signals that GitHub considers this risk acceptable — but between "GitHub considers it acceptable" and "your industry considers it acceptable" lies an entire compliance apparatus. Admins in finance, healthcare, and government should not be lazy during these 28 days.

There's another rarely discussed angle: the default policy is GitHub's accelerator for feature-release cadence. Previously, every new feature faced the long tail of "enterprise admins haven't configured it yet" — the feature shipped, but big-enterprise users only got it half a year later. With default enablement, how fast new features arrive no longer depends on the slowest admin. That's good for GitHub's competitive position: when Cursor, JetBrains, and Devin all ship agent capabilities weekly, "can your enterprise users get it on day one" becomes a direct measure of platform competitiveness. Default-on essentially moves GitHub from the passive side of "waiting for admins to nod" to the automatic side of "shipping without waiting."

This brings us to the concept of "patrol-based" governance. Traditional enterprise IT governance is "approval-based": every change gets requested, reviewed, then shipped. But in the agent era there are too many change sources — models retiring weekly, features enabling by default, new MCP servers daily. Approval-based processes can't keep up; the only option is "patrol-based": set your default philosophy (Enabled or Disabled), then regularly patrol "what actually got enabled and whether anything looks off." The "unconfigured" banner GitHub placed on the AI Controls page is the first tool of patrol-based governance. Expect more: policy-drift alerts, anomalous-enablement notifications, risk-tiered defaults per team. JetBrains' Air Governance and GitHub's default policy look like two different routes, but they're answering the same question: in the agent era, how do enterprises stay "in control" without "slowing down."

One more implication, for "shadow AI" governance: in many companies, Copilot's real state is "the admin configured it once and never looked again, while developers run all kinds of preview features and third-party MCP servers themselves." After the default policy takes effect, "never configured" no longer means "off" — it means "on per the default." The old trick of "soft-disabling by not configuring" stops working entirely. If your organization ever used "non-configuration" to quietly shelve a sensitive feature (like a code-review agent), you must now explicitly set it to Disabled. Silence is no longer a position; silence is consent.

A final word for individual developers: after October 22, if your Copilot Chat model picker changes (say, Gemini 3.6 Flash is gone and Kimi K3 appears), or agent mode suddenly reaches MCP services you never configured — don't panic, and don't rush to turn things off. Check your organization's AI Controls first. Understanding where "defaults" come from is the cheapest way to stay in control in this era. The platform won't take responsibility for your "not noticing"; it only takes responsibility for your "explicit choices."

One more practical detail: GitHub's docs state explicitly that this default policy is "enabled by default" — many admins will wrongly assume a "new policy" defaults to "inactive," but "default enablement" here has two layers: the policy itself defaults to Enabled, and after October 22 unconfigured items follow that value. If you plan to choose Disabled or Let organizations decide, set it explicitly on the AI Controls page before October 22 — don't wait until after it takes effect. Because the moment it goes live, unconfigured features flip all at once to whatever the default is then, and cleaning up afterward is far more painful than setting it beforehand.

One line to close: October 22 isn't doomsday — it's a coming-of-age for defaults. From that day on, there's no "haven't decided" option left in your Copilot governance. Decide, configure explicitly, review regularly. That's it.