Set AI model defaults without expanding access

TL;DR

Before choosing a default AI model for your team, separate two decisions: which model starts a new conversation, and which models people may use at all. Record where each setting comes from, what an exception permits, and what happens when the provider adds a model. A preferred model does not, by itself, establish an access restriction.

The useful signal

GitHub's September 2 announcement says Copilot Business and Enterprise administrators can set a preferred model for new conversations through enterprise-managed settings. It also describes team-specific defaults: administrators make the model key overridable and configure team mappings, while other users inherit the enterprise default. GitHub lists the Copilot app, CLI, and Visual Studio Code as supported surfaces for these managed model defaults.

That is a starting-choice setting. GitHub's separate August 26 announcement describes model availability. Previously unconfigured and new generally available models can inherit a global policy. A model in “Delegate to default policy” follows that policy dynamically; explicit enable or disable decisions are preserved. GitHub also describes exclusions from default enablement for open-weight models and models outside its data-retention agreement.

These are attributed descriptions of GitHub's product behavior, checked on September 10. They are not evidence that a particular company's configuration is correct. Together, they expose a distinction worth checking before an administrator tells a team its AI model policy is settled.

Why this matters

If you own a small software business or manage its development team, you may be asked to approve a default model because it works well for the team's routine tasks. That request is reasonable. The problem comes when “we picked the default” becomes shorthand for “we decided everything people can use.”

A default answers what starts selected. Availability answers what can be selected. A team override changes the inherited choice under specified conditions. None of those statements establishes which business actions the resulting assistant may take.

Keeping the decisions separate lets you support different teams without treating every preference as a security exception. It also prevents a change to a global availability policy from being mistaken for a harmless change to the starting model.

Write one default-and-access record

SpinTheBloc's recommendation is a short record for one team and one client application. It is an operating aid, not a GitHub standard or a claim that every platform exposes the same controls.

Decision	What to record
Starting model	Which model opens a new conversation, and why it fits this team's work
Available models	Which models are explicitly enabled, disabled, or inherited
Inheritance	Which enterprise, organization, or team setting controls the effective state
Exceptions	Who may request a different default or access to another model, and who decides
New releases	Whether newly added models can become available through inherited policy
Verification	The client application, account context, date, and observed settings

Do not fill unknown settings with the policy you intended to install. Mark them unverified until the administrator can inspect their effective state. A document showing the desired configuration is different from evidence that a team member receives it.

For task quality and economics, use a separate comparison. Our model-routing guide explains how to test cost per accepted outcome. This article addresses the administration question that comes afterward: how to preserve the chosen default without accidentally changing the available model set.

Test inheritance before broad rollout

Ask the administrator to demonstrate the policy in a bounded test account or permitted test environment. Use public or synthetic inputs, not client-confidential code, to check basic behavior.

1. Start a new conversation as a user who inherits the enterprise default. Record the starting model and available choices.
2. Repeat as a member of a team with an allowed override. Check whether the expected team default appears in the intended client.
3. Inspect an explicitly disabled model. Confirm that choosing a preferred model has not been mistaken for disabling alternatives.
4. Inspect a model that follows the global policy. Record what its inherited state means for current and newly added models.
5. Check the same policy in every client the team actually uses. Do not infer CLI behavior from a screenshot of an IDE.

Changing production policy is not part of an observation test. If a test needs a mutation, obtain the appropriate administrator approval and define restoration first. Where a setting cannot be inspected safely, preserve the existing configuration and record the gap.

Hypothetical example: a team-specific default

Suppose a software company wants one development team to start with Model A and another to start with Model B. These are fictional labels, not recommendations or a customer case.

The administrator can evaluate team defaults while leaving the approved model availability policy unchanged. A request to change the starting model then stays distinct from a request to enable an additional provider or model. The latter may require a separate review of data handling, terms, cost, and permitted work.

The review ends with a record of the effective settings, not a claim that either team became faster. No implementation, savings, incident, or business outcome is asserted in this example.

What to watch next

Recheck this record when the provider changes policy inheritance, adds models, retires a chosen model, or extends support to another client. A previously correct configuration may no longer answer the same question after those changes.

GitHub's August 26 announcement also says it is evaluating changes to make the global policy an explicit decision. That is a stated possibility, not a shipped behavior established by that announcement. Read the current documentation and effective account settings before making a change.

The immediate owner decision should be narrow: approve one team's starting model and exception process, with model availability documented separately. If nobody can explain which settings are inherited, hold the rollout until that ambiguity is resolved.

For help framing that decision, compare SpinTheBloc's working lanes. Bring the current configuration and the job your team needs to complete. This is a route to discuss the work, not a promise of automated compliance certification or a prebuilt Copilot management service.

Sources

• GitHub: Enterprise-managed settings support any default model supports the starting-model, team-override, inheritance, plan, and client-surface statements.
• GitHub: Global model policy generally available supports the separate availability-policy, dynamic inheritance, explicit-choice preservation, and default-exclusion statements. Its future-policy discussion is a proposal, not proof of implementation.

Caveat

These first-party sources document product behavior and vendor intentions. They do not prove that your account has the intended configuration, that every client enforces it identically, or that any model is suitable for confidential work. We did not inspect a private Copilot account or conduct a production enforcement test. The default-and-access record, test sequence, and hypothetical team example are SpinTheBloc synthesis. Setting a model default does not grant approval to send, spend, publish, merge, or change customer records.