GitHub Copilot Enterprise Model Policies: August 2026 Checklist

GitHub is changing how enterprises govern Copilot models, and administrators have two near-term decisions to make. A team-based model-access preview begins reaching most enterprise customers on August 3, 2026, while a separate default-availability policy starts affecting unconfigured generally available models on August 26, 2026.

This guide explains how to set a safe baseline, pilot model access by job role, avoid unexpected availability changes, and connect model policy to AI-credit budgets. It is written for GitHub Enterprise Cloud owners using Copilot Business or Copilot Enterprise.

What changed in GitHub Copilot model governance?

GitHub announced the enterprise teams model policy preview on July 31, 2026. Previously, granular model decisions were primarily tied to organizations. The preview lets an enterprise owner grant additional models to enterprise teams instead, so access can follow a person's role, training, or function rather than the organization containing a repository.

The preview introduces three enterprise-level states:

This is not just a new grouping option. When enterprise teams mode is enabled, organization-level model settings stop applying. Model access is then controlled by the enterprise baseline plus team assignments.

GitHub says the rollout is gradual, with most enterprise customers gaining access to the preview opt-in on August 3. If the toggle is not visible on that date, do not redesign permissions around an assumed rollout; wait until the control appears in the enterprise's AI controls.

The August 26 default-enablement deadline

A second change needs attention even if you do not join the teams preview. GitHub's default availability policy is configurable now but does not affect model access as of August 2, 2026.

On August 26, 2026, unconfigured generally available models will be relabeled inherits default and will follow the policy:

• If default availability is enabled, eligible unconfigured models become available.
• If it is disabled, those models remain unavailable until an administrator approves them.
• An explicit enabled or disabled choice for an individual model is preserved.

Pre-GA models are excluded. GitHub also excludes open-weight models such as DeepSeek and Kimi K2.7 Code, models outside GitHub's data-retention agreement such as Claude Fable 5, and models that conflict with applicable data-residency or FedRAMP restrictions.

For a regulated or tightly controlled environment, the safest default is disabled. That preserves an approval gate for future models. A less regulated product organization may prefer enabled for faster access, but only after documenting who monitors new releases, data terms, model cost, and incident notices.

Choose organization mode or enterprise teams mode

The strongest choice depends on how users are organized.

Stay with organization-based controls when

• Organizations already map cleanly to legal entities, data boundaries, or business units.
• Organization owners are expected to approve models locally.
• Your access review and audit process is built around organizations.
• You cannot yet validate the preview in a noncritical cohort.

In the default mode, an enterprise can make a model optional and let organization owners decide. Enterprise owners can also create targeted model rules for selected organizations.

Pilot enterprise teams mode when

• Developers work across several organizations but need the same model set.
• Model access should follow roles such as security reviewer, mobile engineer, or AI pilot participant.
• Training completion should determine access to higher-capability or higher-cost models.
• Central AI administrators need control without delegating every decision to organization owners.

The most important trade-off is role precision versus preview risk. Enterprise teams better reflect how people work across repositories, but this is still an opt-in preview. GitHub may change behavior, controls, or availability before general release.

A safe migration plan

Do not turn on enterprise teams mode before staging the replacement policy. GitHub lets administrators create enterprise teams and assign optional models before enabling the preview, while those assignments remain inactive.

1. Export the current policy map

Record every model and its enterprise status. For optional models, record which organizations currently enable them. Also list any organization-level targeted model rules.

The objective is to identify permissions that will disappear when organization-level settings are deactivated. Pay special attention to models that are optional or unconfigured: after switching modes, they are unavailable unless a team explicitly receives them.

2. Define a small enterprise baseline

At AI controls → Copilot → Configure models, explicitly classify the models that should apply everywhere:

• Enable models approved for normal, low-risk work.
• Disable models prohibited by compliance, retention terms, residency, or internal policy.
• Mark specialized models optional.

Avoid making every model optional. A clear baseline reduces team-level administration and prevents accidental differences between similar roles.

3. Create role-based enterprise teams

GitHub's enterprise team documentation supports manual membership, REST-based membership, and identity-provider group synchronization for Enterprise Managed Users.

Use durable role names rather than temporary project names. Practical examples include:

• Standard engineering
• Advanced coding agents pilot
• Security and compliance review
• Data-sensitive development
• AI platform administrators

A team can contain up to 5,000 users, and an enterprise can create up to 2,500 enterprise teams. Those limits are generous, but a small number of meaningful access tiers is easier to audit than hundreds of narrowly defined groups.

4. Stage optional model assignments

For each team, open its Default models tab and enable only the additional models that role requires. These assignments do not take effect until enterprise teams mode is enabled.

Create a simple matrix with teams as rows and optional models as columns. Have the security owner, engineering owner, and billing owner review it together. A model can be technically safe yet financially inappropriate for broad access.

5. Test overlap before enabling the preview

Team permissions are additive and use a least-restrictive strategy. If one of a user's enterprise teams grants a model, that user receives it everywhere while using the Copilot license from that enterprise. Another team cannot explicitly deny the same model.

This makes group hygiene critical. Search for users in overlapping pilot, contractor, privileged, and restricted teams. Resolve unexpected membership before activation rather than expecting a deny rule to win.

6. Enable, observe, and retain a rollback record

When ready, go to AI controls → Copilot and enable Enterprise teams mode. Validate access with representative users from each tier, including one user in multiple teams and, if applicable, one user licensed by more than one enterprise.

GitHub allows rollback during the preview, restoring the previous policy configuration. However, changes made to enterprise-level model policies after opting in are not preserved after rollback. Save the pre-migration matrix and log every change made during the pilot.

Connect model access to AI-credit budgets

Access policy limits who can select a model; it does not by itself cap usage cost. GitHub's usage-based billing documentation states that one GitHub AI credit equals $0.01 USD.

As of August 2, 2026:

• Copilot Business costs $19 per granted seat per month and normally includes 1,900 AI credits per user per month.
• Copilot Enterprise costs $39 per granted seat per month and normally includes 3,900 AI credits per user per month.
• Existing customers receive promotional monthly allowances of 3,000 Business credits or 7,000 Enterprise credits per user from June 1 through September 1, 2026.
• Credits are pooled at the billing-entity level and do not roll over to the next month.

Additional paid usage is enabled by default for organizations and enterprises. If the shared pool is exhausted, usage can continue at published rates unless an administrator disables paid usage or applies a budget. There is no automatic switch to a cheaper model when a budget is exhausted.

Use three layers of control:

1. Model policy to limit specialized models to approved roles.
2. User-level budgets to constrain individual consumption, including draws from the shared pool.
3. Enterprise, organization, or cost-center budgets to cap additional metered spending after included credits are consumed.

This separation matters. A team grant answers “may this person use the model?” A budget answers “how much usage can the business fund?”

Post-change verification checklist

Run this review immediately after activation and again after August 26:

• Confirm explicit enterprise states for every sensitive model.
• Verify the Default availability for released models policy matches your approval strategy.
• Test a baseline-only user, each optional-access tier, and a user with overlapping teams.
• Confirm organization owners understand that their model settings no longer apply in teams mode.
• Review AI-credit paid usage, user budgets, and enterprise spending limits.
• Check that identity-provider group changes correctly add and remove team access.
• Monitor GitHub audit data and support reports for unexpected model availability.
• Review model policy whenever GitHub announces a new model or changes data-handling terms.

Model permissions are only one part of safe agent deployment. For workloads that can execute tools or modify systems, pair access governance with an AI agent sandbox security checklist.

Limitations to plan around

Enterprise teams model access is a public preview, not a permanent contract. The controls may change, and gradual rollout means availability can differ between enterprises.

The policy is also additive, so it cannot express a team-level denial that overrides another grant. Enterprises needing strict separation must enforce clean group membership and a conservative enterprise baseline. Finally, model availability does not replace repository permissions, content exclusion, data governance, human review, or spending controls.

Conclusion

Before August 26, every Copilot Business or Enterprise administrator should choose an intentional default for future generally available models and explicitly classify sensitive models. Enterprises whose developers span multiple organizations can then stage the team-based preview around stable job roles, test overlapping membership, and activate it with a documented rollback state.

The practical sequence is simple: set the baseline, build teams, stage optional access, inspect overlaps, configure budgets, then enable and verify. That order reduces both access regressions and unexpected AI spending while preserving a controlled path to newer models.