Between August 26 and September 2, 2026, GitHub evolved several Copilot governance mechanisms: a global model availability policy, the removal of selected models, the handling of content exclusions in the application and CLI, and the definition of a default model at enterprise or team level. Taken separately, these changes look like administration settings. Together, they show that model selection is becoming a matter of portfolio, data, and operational continuity.
Key takeaway: authorizing “Copilot” is no longer enough. An organization must decide which models are available, for which teams, on which data, with which safeguards, and until what date. Inherited default values must be distinguished from explicit decisions, and every model retirement must trigger regression testing.
1. Why multi-model changes governance
A coding assistant was initially seen as a relatively homogeneous product: one interface, one provider, and one central policy. Platforms now offer several models, sometimes from different vendors, with distinct cost, performance, licensing, and data-processing characteristics.
The model is used in a range of contexts: local completion, conversation, multi-file editing, autonomous agents, code review, or CLI. A permission suited to writing a test is not necessarily suited to an agent that explores a repository, runs commands, and proposes a pull request.
This diversity brings flexibility. A team can use a fast model for everyday interactions and a more advanced model for a complex migration. But it also creates implicit decisions. A new model may become accessible because it inherits a global policy; a preferred model may disappear; a privacy setting may be applied in the IDE but not yet in another surface.
Governance must therefore cover the combination of model + feature + data + team + version, rather than the product name alone.
2. Understanding GitHub’s four policy states
On August 26, GitHub announced the general availability of its global policy for Copilot models, with a phased rollout through September 1. Generally available models that had not been explicitly configured could follow the state of this policy.
Administration distinguishes four situations: explicitly enabled, explicitly disabled, delegated to a team or organization, and delegated to the default policy. The latter value is dynamic: if the global policy changes, all models that follow it change with it.
The nuance is essential for auditing. Two models shown as available may result from very different decisions. The first was assessed and enabled; the second appeared through inheritance. The decision’s origin must therefore be recorded, and the effective state must not be treated as proof of approval.
GitHub specifies that explicit choices are preserved. It also indicates that open-weight models and those not covered by its data-retention agreement are disabled by default in this mechanism. This protection is a starting point, not a complete policy: the organization must still verify the applicable conditions, regions, features, and its own customer commitments.
A good practice is to disable automatic activation in sensitive scopes and require an explicit decision for each new model. In less critical environments, inheritance can remain allowed with automatic review and notification to owners.
3. Addressing confidentiality at content level
On September 2, GitHub announced that the Copilot application and Copilot CLI now respected content-exclusion policies configured at enterprise, organization, and repository levels for Business and Enterprise plans. Excluded files must not be used as context in these workflows.
This feature helps protect secrets, contractually restricted code, proprietary data, or directories whose use by an assistant is not authorized. However, it does not replace access controls. A developer or agent who can read a file may still copy it into another surface, summarize it manually, or expose it to an external tool.
Exclusion must therefore be part of a broader strategy: repository classification, secret separation, DLP rules, least-privilege permissions, and logging. It must also be tested on each interface. A policy announced for the application and CLI must not be assumed to be identical across all extensions, integrations, or APIs.
Document what “excluded” means. The question is not only whether the content enters the prompt. Check suggestions, indexes, caches, logs, evaluation traces, and any memory features. Vendor contracts and documentation remain the source of truth.
Our article on Zero Data Retention and Private Safety Processing details this distinction between retention, training, logging, and security controls.
4. Preparing deprecations as migrations
On August 31, GitHub announced the deprecation of several models effective September 1 in most Copilot experiences. The list notably included Gemini, Claude, and Raptor Mini versions, with suggested alternatives.
The very short notice shows that a model name must not be hard-coded without a replacement strategy. A team using a model in instructions, automations, evaluations, or enterprise settings may experience an outage or a silent behavior change.
Treat every retirement as an application migration. Inventory uses, choose a candidate, rerun evaluations, measure quality, and check costs. Prompts may depend on a reasoning style, context window, or output format. Replacing a model with “the closest one” does not guarantee equivalence.
Add a logical layer between the use case and the commercial name. For example, the code-review-standard profile points to an approved model with a given configuration. The provider or version change is made in the registry, without modifying every workflow.
Monitor schedules, but also prepare for unplanned replacement. A model may be retired for security, licensing, or availability reasons. Every critical use must have a tested fallback and an explicit degraded mode.
5. Defining team models without fragmenting the organization
On September 2, GitHub announced the ability to define a default model in enterprise-managed settings, with different values by team, for the Copilot application, CLI, and Visual Studio Code on Business and Enterprise plans.
This granularity is useful. A PHP team may favor a model that performs well on its repositories and tasks; a support team may seek speed and cost efficiency; a security team may require a more restrictive model and policy.
The risk is fragmentation. If every team chooses without a framework, the company no longer knows which models process its data, evaluations multiply, and incidents become difficult to reproduce.
Define a short catalog. Two or three profiles generally cover most needs: fast interaction, complex reasoning, and sensitive context. Teams request an exception when they demonstrate a measurable need. The exception has an owner, an expiration date, and an evaluation set.
The default model is not necessarily the only permitted one. It represents the recommended choice. Whether users can override it depends on the risk level. On a public repository, freedom may be broad; on a regulated product, the model and surface may be imposed.
6. Building a model and use-case registry
The registry is the source of truth. For each model, retain the provider, version, GitHub status, available surfaces, data policy, regions, cost, introduction date, review date, and internal owner.
Then link the use cases: completion, chat, agent, CLI, review, test generation, or migration. Add data classification, autonomy level, accessible tools, default model, and fallback model.
A registry entry could read: “automatic review of non-regulated internal repositories; model A; suggestions only; secret content excluded; human approval required; monthly evaluation; fallback to model B.”
This registry must be versioned. A machine-readable file can generate managed settings, audit tables, and deprecation alerts. Changes go through a pull request approved by platform, security, and business owners when necessary.
Avoid turning the registry into a theoretical catalog, however. Every active entry must correspond to an observed use. Unused models increase the governance surface without creating value.
7. Testing quality, cost, and risk before activation
A general benchmark is not enough to choose a development model. Build an evaluation set from real, anonymized tasks: targeted fixes, module understanding, test generation, migration, security review, and adherence to conventions.
Measure success rate, defects introduced, explanation quality, tool calls, cost, and latency. Check behavior when faced with an instruction present in the repository, an excluded file, a dummy secret, and an out-of-scope request.
For agents, add action criteria: does it respect the branch, authorized files, commands, and limits? The best model at code generation is not necessarily the most controllable in an autonomous workflow.
Rerun the set for every new version or surface change. A GitHub update can change the orchestration around the model, even when the model itself remains the same. Keep results and configurations so that a change in quality can be explained.
Activation follows a phased rollout: pilot team, selected repositories, observation, then generalization. Incidents and user feedback feed the registry and may lead to a return to the previous model.
8. Establishing a quarterly governance cycle
Each quarter, review the list of available models, inherited decisions, exclusions, actual uses, costs, and announced retirement dates. Disable unused models and renew only justified exceptions.
Each month, monitor provider and GitHub changelogs. A material change triggers an analysis without waiting for the quarterly review. Automation can open a ticket when a registry name appears in a deprecation announcement.
Before every activation, require a short form: need, data, surfaces, evaluation, cost, fallback, and owner. After activation, verify that the effective settings match the registry. The gap between declared policy and actual configuration is a priority indicator.
Finally, communicate with developers. Explain why certain models are available, how to report a problem, and what information must never be provided to the assistant. Understandable governance gains more support than a list of restrictions without context.
Conclusion
The proliferation of models in GitHub Copilot provides useful adaptability, but turns a productivity setting into a system that must be governed. Global policies, content exclusions, team-level defaults, and deprecations must be handled together.
A robust organization keeps a versioned registry, makes the origin of decisions explicit, evaluates models on its own tasks, prepares replacements, and verifies data protections on every surface. Partitech supports the design of this governance, the automation of controls, and the integration of Copilot into a measurable DevSecOps approach.
References verified on September 3, 2026
- GitHub — “Global model policy generally available”, August 26, 2026: https://github.blog/changelog/2026-08-26-global-model-policy-generally-available/
- GitHub — “Selected GitHub Copilot models deprecated”, August 31, 2026: https://github.blog/changelog/2026-08-31-selected-github-copilot-models-deprecated/
- GitHub — “Content exclusions generally available in Copilot app and CLI”, September 2, 2026: https://github.blog/changelog/2026-09-02-content-exclusions-generally-available-in-copilot-app-and-cli/
- GitHub — “Enterprise-managed settings support any default model”, September 2, 2026: https://github.blog/changelog/2026-09-02-enterprise-managed-settings-support-any-default-model/