On September 24, 2026, GitHub announced a global default for Copilot Business and Enterprise features. Starting October 22, eligible features left Unconfigured will follow that default. Administrators can choose it now, during a preparation window that does not yet change feature access.
For a security team that reviews new capabilities before enabling them, an untouched setting now needs a decision. GitHub's default-availability reference says the feature default starts Enabled. It covers existing unconfigured capabilities as well as future eligible releases.
The harder check is who receives the resulting access. An organization can disable MCP while a developer licensed by another organization still receives it. Prepare the rollout around affected users and their license sources, then keep execution permissions in the separate coding-agent security baseline.
This is a documented policy change and a proposed administrative review procedure. General Analysis has not tested the upcoming enforcement in a Copilot tenant.
Choose what happens when nobody has made a decision#
The September 24 announcement gives enterprise owners three choices: Enabled, Disabled, or Let organizations decide. Explicit feature enables and disables survive the transition. Previews remain opt-in, and a choice made during preview is preserved when the feature reaches general availability.
If your rule is "review every new capability before use," set the default to Disabled and record the capabilities already approved. This recommendation does not mean changing the default revokes existing approvals. Inspect explicit enables separately.
If most new capabilities can be accepted automatically, keeping Enabled may fit your policy. Give sensitive exceptions explicit decisions and an owner who reviews later scope changes. An exception with no owner is easy to forget when a team changes its workflow.
The organization policy guide says organization owners cannot override an explicit governing enterprise choice. Where the enterprise delegates, have each owner record the intended outcome for their users before the cutover.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Inventory the settings outside the main feature list#
Start in the enterprise's AI controls → Copilot → Features & clients settings. Also inspect Agents for Copilot code review and MCP for MCP servers in Copilot. GitHub's enterprise administration guide documents these separate locations.
The default-availability reference provides an unconfigured-policy count in the settings banner. Use that count to reconcile your inventory, then inspect the actual rows. Its documented exceptions are:
- GHE.com restrictions to data-resident or FedRAMP models.
- Store local sessions in the Cloud for Copilot CLI and VS Code.
Those controls need their own review. The model default is also separate and already active. A completed feature-default review does not establish which models users can access.
For each row, record the current state, the decision source, and the expected state after enforcement. Keep excluded controls in the record and name who will review them separately.
Check the user who belongs to two licensing organizations#
Consider a hypothetical enterprise that delegates the MCP policy. The Research organization enables it; the Finance organization disables it. A developer receives a Copilot license through both. The Finance settings page alone would give an incomplete account of that developer's access.
GitHub's policy-conflict reference lists MCP servers in Copilot as least restrictive across the organizations granting a user a license. An enable in either organization therefore makes the feature available to that user. Code review, the CLI, and the Copilot app also use that rule. Other controls, including the Copilot Metrics API, use the most restrictive organization.
Use these documented distinctions to choose pilot accounts. The table is a proposed acceptance matrix, not results from a deployment:
| Account and policy case | Expected policy outcome | Evidence to retain |
|---|---|---|
| One licensing organization; eligible feature left unconfigured | Follows the applicable default after enforcement begins | Default, feature row, license source, observation time |
| Feature explicitly disabled at the governing enterprise scope | Default change preserves the disable | Enterprise decision and resulting access |
| Two licensing organizations; delegated MCP enabled in one and disabled in the other | Least restrictive rule permits MCP | Both organization decisions and the user's license assignments |
| Two licensing organizations; Metrics API disabled in one | Most restrictive rule blocks that capability | Both decisions; do not generalize the MCP result |
The same reference describes different resolution across multiple enterprises. Keep that population separate. Do not infer access from ordinary organization membership alone: the documented conflict rule concerns organizations that grant the user a Copilot license.
If a capability must be unavailable to every user in an enterprise, consider an explicit enterprise restriction instead of relying on one organization's disable. If teams need different access, resolve overlapping license assignments and verify the intended users. Avoid removing licenses blindly; that may disrupt approved work without addressing the actual governing policy.
Keep availability separate from action authority#
Allowing MCP makes a connection capability available. It does not establish that each connected server has suitable credentials or that every action should run without approval. Review those through MCP server security and the managed operation-permissions rollout.
GitHub's enterprise policy guide also limits the MCP switch's scope: it does not govern access to the GitHub MCP server from other host applications such as Claude or Cursor. Include those hosts in a separate inventory if the security requirement is to restrict access to GitHub data.
Likewise, enabling code review is a different decision from letting an AI approval satisfy a merge requirement. Preserve the required human-review controls when reviewing that feature row.
Save a cutover record that can explain a surprise#
Before October 22, assign an owner to each unresolved feature and delegated organization. Preserve a dated settings capture and a list of affected license sources in an approved evidence store. Use account identifiers without copying tokens or private repository content into the record.
This illustrative template is a review record, not a GitHub configuration file or API payload:
Code source: illustrative.
Feature:
Enterprise decision and default:
Licensing organizations and their decisions:
Explicit decision, inherited default, or exception:
Affected pilot accounts:
Expected access after enforcement:
Observed access and timestamp:
Evidence location:
Owner and corrective action:
During the preparation window, a saved default proves the intended setting, not future enforcement. After the policy starts applying, check the same pilot accounts and record both expected and observed access. Use harmless tasks and approved test resources; this review does not require attempting an exploit.
If a user receives unexpected access, trace the feature's explicit settings, defaults, and license sources before changing unrelated controls. To withdraw a specific capability, make the relevant explicit policy decision and verify the result. Turning the global default off alone is insufficient when an explicit enable survives it.
Leave an unresolved access mismatch open in the change record, with the affected account and the administrator responsible for resolving it.
Frequently asked questions
- Will disabling the new Copilot feature default turn off explicitly enabled features?
No. GitHub says explicit enable and disable decisions are preserved. The default governs eligible features without an explicit decision. Review existing enables separately if you need to remove access.
- Does the feature default also control which models are available?
No. Default availability for released models is a separate policy that is already active. Review both settings; changing the feature default does not change the model default.
- Can one organization's MCP disable block a user licensed by two organizations?
Not necessarily. GitHub lists MCP servers in Copilot as following the least restrictive licensing organization. When enterprise policy delegates the choice, an enable in another licensing organization can make the feature available to that user. Review the user's license sources and governing enterprise policy.
