For organizations that assumed an unconfigured model was safely unavailable, this is a governance change rather than a cosmetic settings update. The organization-level or enterprise-level switch is enabled by default. Unless an administrator disables it, eligible generally available models shown as “Delegate to Default Policy” become available without a separate per-model approval.
GitHub’s July announcement says the policy took effect on August 26 after a 28-day preparation period. TechTimes reports that enforcement is being rolled out incrementally through September 1, but GitHub’s public changelog describes August 26 as the effective date and does not itself publish a September 1 completion commitment. Admins should act on the policy now rather than treat September 1 as a safe deadline.
The old unconfigured state no longer means “off”
Before this change, adding a newly released Copilot model to an enterprise deployment required an administrator to find it and make a model-level choice before users could select it. That created administrative friction, but it also established a dependable opt-in control: doing nothing prevented a new model from appearing in developer workflows.
GitHub has replaced that implicit block with a global default. The policy applies only to generally available models that administrators have not intentionally enabled, disabled, or delegated elsewhere. When the global setting is enabled, those models are available to users; when it is disabled, they stay unavailable.
The practical difference is significant for teams that use model access as a formal change-control mechanism. A monthly or quarterly model-review process may no longer catch the first day of use. A newly supported general-availability model can appear in GitHub Copilot Chat, the Copilot CLI, Visual Studio Code, Visual Studio, JetBrains, or other supported surfaces according to its product availability before the next governance meeting occurs.
GitHub’s documentation says explicit per-model decisions are preserved. An administrator who has set a model to enabled or disabled should not see that decision overridden by the global policy. The new default fills the gap left by models that had no explicit setting.
That safeguard limits the blast radius, but it does not solve the main problem for organizations whose intended policy has always been “nothing new is permitted until reviewed.” Those organizations must now encode that posture explicitly by switching Default availability for released models to disabled.
“Delegate to Default Policy” is a status, not a fourth access tier
The supplied reporting describes a four-state hierarchy: enabled, disabled, delegated to organizations or enterprise teams, and delegated to the default policy. GitHub’s current enterprise documentation presents the model controls somewhat differently.
At the enterprise baseline, an owner can enable a model for everyone, disable it for everyone, or delegate a decision to organizations or enterprise teams and apps. Separately, GitHub labels models without an explicit configuration as “Delegate to Default Policy.” That label tells the administrator that the model follows the global fallback policy.
This distinction matters when auditing settings exports, screenshots, or internal control evidence. “Delegate to Default Policy” does not represent a granular exception granted to a group. It means no model-specific decision has been recorded at that scope, so the global switch decides availability.
There is also an additional layer for enterprises using GitHub’s optional enterprise-teams model-access preview. In the standard configuration, an enterprise can delegate decisions to individual organizations. In enterprise-teams mode, organization-level controls are deactivated and model access can instead be added by enterprise team. GitHub warns that models previously delegated to organizations can become unavailable during a migration until they are explicitly enabled for appropriate teams.
For administrators, the result is a hierarchy with real operational consequences:
- An enterprise-wide explicit disable prevents a model from being enabled for a team.
- An enterprise-wide explicit enable makes the model available across teams.
- Delegation permits more targeted organization or team decisions, depending on the mode in use.
- A model left at “Delegate to Default Policy” follows the global availability setting rather than remaining inert.
The safe reading is straightforward: filter the model-policy page for the default-policy status, then review the resulting models as a group. That is the set whose effective access can change when the global setting changes.
The exclusions are broader than the headline suggests
GitHub has not made every model eligible for automatic enablement. Its current Copilot documentation lists four categories that remain disabled by default regardless of the global policy:
- Pre-general-availability models remain outside the automatic-enable policy.
- Open-weight models, including DeepSeek and the Kimi K2.7 Code and Kimi K3 examples named by GitHub, require explicit enablement.
- Models outside GitHub’s data-retention agreement, with Claude Fable 5 named by GitHub, require explicit enablement.
- Models that do not meet a customer’s data-residency or FedRAMP model restrictions remain unavailable where those restrictions apply.
The last item is especially important for regulated Microsoft and GitHub estates. A global policy enabled at the enterprise level does not override data-residency or FedRAMP restrictions. In other words, the new fallback expands access only inside the existing compliance boundary; it is not a bypass for a separately configured residency or government-cloud control.
Claude Fable 5 illustrates why administrators should not reduce the exclusions to an “open versus closed” model question. GitHub says Fable 5 requires explicit enablement because it is not covered by the company’s usual data-retention agreement. GitHub’s model-hosting documentation says Anthropic retains Fable 5 prompts and outputs for up to 30 days to operate safety classifiers, although the data is not used to train Anthropic models. That is a materially different review issue from the availability of an ordinary GA model covered by GitHub’s zero-data-retention arrangements.
The open-weight exception similarly should not be mistaken for a judgment that such models are necessarily unsafe. GitHub is instead preserving an explicit approval step for a category whose provider terms, hosting arrangements, security assessment requirements, and intellectual-property review can differ from proprietary hosted models.
What to check in Copilot administration
The immediate task is to verify the desired default at both the enterprise and organization level. GitHub allows a global enterprise policy, but its documentation also allows organizations with stricter requirements to disable default availability locally. That makes it possible to permit automatic access in lower-risk development organizations while retaining an opt-in posture for teams handling regulated code, customer data, production infrastructure, or sensitive repositories.
Administrators should also avoid confusing model availability with a general approval of every Copilot capability. Allowing a model in the picker does not set its cost controls, content-filtering expectations, agent permissions, plugin access, repository context, or MCP server permissions. Those are separate governance questions, particularly when Copilot can run commands or interact with connected services.
A short review should include:
- Verify whether Default availability for released models is enabled or disabled at the enterprise and each relevant organization scope.
- Identify every model currently marked “Delegate to Default Policy” and decide whether inherited access is acceptable.
- Explicitly disable models that are unacceptable even if the organization keeps the global default enabled.
- Confirm whether data-residency, FedRAMP, and provider-retention restrictions already exclude models that compliance teams would reject.
- Document the model-review owner and the interval for reviewing GitHub’s Copilot changelog, because automatic availability does not remove the need to assess new providers and model terms.
GitHub’s model policy is designed to eliminate repetitive approvals for enterprises comfortable with fast access to new GA models. That is a legitimate operational improvement for organizations that already trust GitHub’s supported-model process and want developers to receive new options immediately.
For organizations whose control standard is explicit approval before exposure, the change requires a deliberate reversal of GitHub’s default. Leaving the policy untouched is now an affirmative choice to allow eligible, unconfigured GA models as GitHub adds them.
