GitHub's global Copilot model policy makes delegation a live choice

GitHub is gradually enforcing a global availability policy for generally available Copilot models through September 1, 2026. When enforcement reaches a Copilot Business or Enterprise account, previously unconfigured models will move to Delegate to default policy; because the global policy starts enabled, applicable delegated models will become available.

The important change is not another model in the picker. It is that an unconfigured row becomes a live inheritance choice. Administrators should decide which models may follow a changing global default and which require an explicit model-level state, then verify the effective settings in their own account because rollout timing differs by enterprise.

What takes effect during the rollout?

GitHub's August 26 announcement says enforcement is rolling out gradually through September 1. It may take effect at different times for different enterprises.

Once it does, previously unconfigured models no longer remain inert. They change to Delegate to default policy and begin following the global setting. New generally available models follow that policy as well.

The default global state is enabled. That means an applicable model delegated to the default becomes available unless an administrator changes the global state or gives the individual model an explicit setting.

GitHub preserves explicit per-model choices. A model deliberately set to Enabled or Disabled does not change merely because enforcement starts or the global default moves. This makes explicit state the durable exception to inheritance.

Two groups are excluded from default enablement: open-weight models and models not covered by GitHub's data-retention agreement. GitHub gives DeepSeek and Kimi K2 as open-weight examples and Fable 5 as a retention example. Exclusion from the enabled default is a starting control, not a complete security or compliance assessment.

What do the four model states mean?

After rollout, GitHub says a model can show one of four states.

Enabled is an explicit model-level grant. Disabled is an explicit model-level block. These choices remain attached to that model when the global default changes.

Delegate to enterprise teams/apps or organizations follows a narrower inherited setting elsewhere in the policy hierarchy. The effective result depends on that delegated scope rather than the global default.

Delegate to default policy is different. GitHub describes it as live and dynamic. Every applicable row in that state follows the global policy whenever an administrator changes it.

That distinction matters operationally. A screenshot showing a model available today does not reveal whether the state is durable. An explicit Enabled row and a delegated row under an enabled global default can produce the same current availability while carrying different future behavior.

Which rows should remain delegated?

Delegation is appropriate when the business decision is genuinely about a class of applicable generally available models rather than one named model. If the policy intent is “make ordinary GA Copilot models available unless GitHub places them in an excluded category,” a delegated row expresses that intent and keeps future launches aligned.

Use an explicit state when the model has its own approval, prohibition, contractual condition, workload restriction, or expiry. In those cases, allowing a global switch to change the row later would erase the distinction the review was meant to create.

This is BaristaLabs guidance, not a GitHub requirement. The test is whether the owner can finish the sentence: “This model should change whenever the global default changes because…” If the answer names a model-specific fact, delegation is probably the wrong representation.

Do not confuse the global default with the enterprise-team migration covered in our team model-access guide. That feature determines how optional models can be granted through additive team membership. The global policy determines what applicable unconfigured and future GA models do by default. A complete access explanation may need both layers.

Open-weight models also keep their separate decision. Our model exception guide explains why an off-by-default model should retain its requester, data boundary, evaluation, and expiry. The new global policy does not convert that exception into ordinary delegated access.

How can administrators verify the effective baseline?

Start with the account's current enforcement state rather than the calendar alone. GitHub says rollout completes through September 1, but it does not publish an exact activation time for each enterprise. Inspect the model settings exposed in the enterprise or organization before concluding that the migration has occurred.

Export or record every named model and its displayed state. Separate explicit Enabled and Disabled rows from both delegated states. Record the global default beside the inventory so a later reader can explain the effective result without reconstructing historical settings from memory.

For every delegated-default row, name the policy owner and the reason dynamic inheritance is acceptable. For every explicit row, preserve the model-specific reason and next review date. This turns an apparently simple toggle into two auditable populations: models intended to move together and models intended to remain exceptions.

Then test representative users in the scopes that matter. A policy row is configuration evidence, not proof of what every user can select. Include at least one ordinary licensed user and any organization, enterprise-team, or application scope that introduces another inherited layer. Record the account, effective model set, time, and settings baseline used for the check.

Model availability also does not prove model use. If a model appears in a picker, that shows access at that moment. Usage reports, workflow traces, or other product evidence are needed to establish that a person or agent actually selected it and sent work through it.

What should happen before September 1?

Resolve only the rows where accidental inheritance would matter. There is no benefit in turning every delegated row into an explicit copy of today's global state if the team truly wants those models to move together.

Focus on regulated repositories, contractual data restrictions, approved-model lists, and teams whose support or evaluation process depends on a named model. Make those exceptions explicit and leave a reason. Keep ordinary delegated rows dynamic only when the platform owner accepts both directions of change: a global disable removes access, and a global enable makes applicable delegated models available.

Finally, assign a post-rollout verification owner. That owner should compare the captured inventory with the settings and representative-user access after enforcement, investigate unexpected gains or losses, and preserve the result with the date. GitHub says it is evaluating whether to remove Delegate to default policy in favor of an explicit global decision, but that is not a committed product change; govern the state that exists now.

The useful outcome is a model baseline whose future behavior can be explained. Explicit rows remain named exceptions. Delegated rows move with a global choice because someone intended them to. Anything else is an unowned policy transition.

BaristaLabs helps platform teams connect AI settings to accountable workflow evidence through process automation. If you cannot yet distinguish deliberate delegation from leftover configuration, bring one Copilot model inventory to a focused baseline review.

Sources

• GitHub Changelog: Global model policy generally available
• GitHub Docs: Managing access to AI models in GitHub Copilot