The practical answer: enterprise administrators should review every unconfigured Copilot feature, set an intentional default, and retain evidence of the resulting access decisions. On October 22, 2026, GitHub began gradually enforcing its new default policy for eligible generally available Copilot features. The rollout continues through October 26, so different organizations may see the change at different times. This is a governance change, not evidence that every feature has been switched on for every customer.

The new rule matters because “we never approved that feature” and “the feature is disabled” are no longer interchangeable statements. An unconfigured setting may inherit an enterprise default. Teams that assess controls only when they purchase a license can miss later changes in the set of capabilities their developers can use.

What GitHub actually changed on October 22

GitHub’s October 22 announcement says eligible generally available features left Unconfigured are assigned according to a global default: Enabled, Disabled, or Let organizations decide. This initial assignment is a one-time transition; later changes to the default do not rewrite feature policies already set. Administrators’ explicit individual choices are preserved. Preview features remain opt-in, subject to the documented transition behavior when a preview reaches general availability.

The scope includes eligible feature and client settings, plus the policy governing MCP servers in Copilot. The official policy reference explains how enterprise and organization decisions interact. The model-availability default is a separate policy; treating the two as one switch would produce an inaccurate inventory.

Why “unconfigured” is a real access state

Consider a regulated software team that explicitly disabled one Copilot feature after a security review but left another feature untouched. The first decision is preserved during the rollout. The second may inherit the global default. If the default is Enabled, the second capability can become available without a new feature-specific approval. That does not imply the tool can bypass repository permissions or execute unrestricted actions; it means the product capability’s availability changed.

For a security review, record three different things: availability (can the user invoke the feature?), authority (what data and systems can it access?), and oversight (what records show its use?). The distinction is especially important for tools that can invoke agents or external integrations. CorpExcellence has separately explained why an OAuth token is not a complete authorization decision and why code-review approvals need separation of duties.

A four-column control ledger

Rather than capture only a screenshot of the global default, create a small control ledger for each eligible capability. This is an original operational framework, not a GitHub-supplied compliance certification.

Control record Question to answer Evidence
Scope Which enterprise, organization, client and feature? Settings export or dated admin screenshot
Effective state Enabled, disabled, delegated, or explicitly set? Read-back after rollout
Risk owner Who approved the data and action boundaries? Review ticket and decision date
Change trigger What release, policy edit, or model change requires retesting? Changelog reference and next review date

Make effective state a first-class field. A delegated organization may apply its own default; a policy that is merely inherited is not equivalent to an explicit decision by the enterprise security team.

Seven steps to check your current exposure

  1. Inventory the current default. In AI Controls → Copilot, locate the default policy for new features. Record its state and the time checked.
  2. List unconfigured eligible policies. Include features, supported clients, code-review settings and the MCP-server policy where applicable. Do not include preview-only features as though they are automatically enabled.
  3. Separate enterprise from organization scope. Where the enterprise delegates, check each organization’s own policy rather than assuming the parent setting decides everything.
  4. Explicitly decide sensitive features. Use a documented review for capabilities that can touch source code, secrets, repositories or external systems. Explicitly disable what has not been approved.
  5. Check the rollout result. Because enforcement is gradual through October 26, read the actual effective policy after it takes effect for your account. Do not assume a global announcement is proof of local activation.
  6. Test with representative users. Confirm access for an ordinary developer and an administrator, and test permitted actions separately from mere feature visibility.
  7. Retain change evidence. Store the before-and-after state, reviewer, exception and next review trigger in the normal change-management system.

Do not confuse feature defaults with model defaults

GitHub documents a separate default for generally available models. Its scope and exceptions differ, including certain pre-GA and other excluded models. An organization might choose to enable new features by default while restricting model availability, or the reverse. Procurement, privacy and engineering reviewers need both inventories because model choice can affect data handling, capability and cost independently of whether a Copilot feature is available.

Nor should an enabled feature be treated as a completed risk assessment. Review repository access, third-party integrations, agent permissions and human approval boundaries on their own merits. CorpExcellence’s third-party security-agent risk framework and responsible delivery controls offer complementary questions for those reviews.

The decision that matters after the rollout

A reasonable organization may prefer Enabled for rapid experimentation, Disabled for tightly controlled environments, or delegated decisions for different business units. None of those settings is universally correct. The failure is leaving the choice undocumented while assuming that an empty field means no access.

For the October 22–26 transition, prioritize evidence over slogans: identify what was unconfigured, determine what became effective, confirm who approved it, and test what the capability can actually do. That is the difference between a software release happening to the organization and a release being governed by it.

References

Related posts:

  1. Four Control Planes for Enterprise AI Agents: Identity, Authorization, Egress and Audit
  2. EU AI Act After the Digital Omnibus: The New Compliance Calendar and What Not to Delay
  3. Buying AI Security Agents: A Third-Party Risk and Control Framework
  4. Agent Tool Authorization: Why an OAuth Token Is Not a Permission Decision