Github Copilot User Management Guide

• Model type: role-based
• Description: GitHub Copilot uses GitHub's existing enterprise and organization role hierarchy. Access is controlled by enterprise owners setting policies and enabling Copilot per organization, then organization admins assigning seats to members or teams. There are no Copilot-specific custom roles; permissions derive from the user's GitHub enterprise/org role.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Seat assignment is at the individual user or team level within an organization. Feature-level policies (e.g., Copilot Chat, suggestions matching public code, Copilot in the CLI) are set at the enterprise or organization level and apply uniformly to all seat holders in scope.

1. Enterprise owner navigates to the enterprise account → Settings → Copilot → Access and enables Copilot for the target organization(s), or sets policy to 'Allow for all organizations'.
2. Organization admin navigates to the organization → Settings → Copilot → Access.
3. Under 'Access', select one of: 'Allow for all members', 'Allow for selected members and teams', or 'Disabled'.
4. If 'Allow for selected members and teams' is chosen, click 'Add people' or 'Add teams', search for the GitHub username or team name, and confirm.
5. The user receives an email notification and can activate Copilot in their IDE or on GitHub.com immediately.

Required fields: GitHub username or team name of the user(s) to be granted access, Organization must already be enabled for Copilot by the enterprise owner (Business/Enterprise plans)

Watch out for:

• Seats are billed immediately upon assignment; there is no trial period for Business/Enterprise seats.
• If a user is a member of multiple organizations under the same enterprise, they consume only one Copilot seat across all organizations.
• On the Free plan, users self-activate; admins cannot assign Free seats.
• Enabling 'Allow for all members' automatically assigns a seat to every current and future org member, which can cause unexpected billing increases.
• Users must have a GitHub account before a seat can be assigned; there is no way to pre-provision a seat for a non-existent GitHub user.

• Can delete users: No
• Delete/deactivate behavior: GitHub Copilot does not have a 'delete user' concept separate from GitHub account management. Removing Copilot access means revoking the seat assignment (deactivation of Copilot access). The GitHub user account itself is not deleted. On EMU, deprovisioning via SCIM suspends the managed user account enterprise-wide, which also removes Copilot access.

1. Organization admin navigates to the organization → Settings → Copilot → Access.
2. Find the user or team whose access should be removed.
3. Click 'Remove' next to the individual user, or remove the team from the allowed list.
4. Confirm the removal. The user loses Copilot access immediately.
5. Alternatively (enterprise-level): Enterprise owner navigates to enterprise Settings → Copilot → Access and disables Copilot for the entire organization, which removes all seats in that org.

Watch out for:

• Seat billing continues until the end of the current billing cycle after revocation; there are no prorated refunds for mid-cycle removals.
• If 'Allow for all members' is enabled, removing a single user requires switching to 'Allow for selected members and teams' first, then manually re-adding all other users - or removing the user from the organization entirely.
• On EMU, SCIM deprovisioning suspends the entire managed user account, not just Copilot access; this affects all GitHub Enterprise services for that user.
• Revoking access does not clear any locally cached Copilot tokens; the user may have a brief window of continued access until the token expires.

• Where to check usage: Enterprise: github.com/enterprises/{enterprise}/settings/copilot → 'Usage' tab shows seat count, active users, and per-organization breakdown. Organization: github.com/organizations/{org}/settings/copilot → 'Access' shows assigned seats and last-active dates.
• How to identify unused seats: The enterprise and organization Copilot usage pages display the last activity date for each assigned seat. Seats with no recorded activity (no completions or chat interactions) in the past 30 days can be identified and revoked manually. There is no automated idle-seat reclamation; admins must review and remove manually.
• Billing notes: Seats are billed monthly per user assigned, regardless of actual usage. Adding a seat mid-cycle is prorated for the remainder of the cycle. Removing a seat mid-cycle does not generate a prorated credit; the seat is billed through the end of the current cycle. Extra premium requests beyond the plan allowance are billed at $0.04 per request. Business and Enterprise plans are billed at the organization or enterprise level, not per individual. Free and Pro plans are billed to the individual user's GitHub account.

Seat billing starts the moment a seat is assigned and continues through the end of the billing cycle even if access is revoked mid-cycle - no prorated credits are issued. Enabling 'Allow for all members' automatically assigns a seat to every current and future org member, which can produce unexpected billing spikes in growing organizations.

There is no automated idle-seat reclamation; admins must manually review last-activity dates and remove unused seats one by one or by team.

Bulk provisioning without SCIM is limited to team-based assignment or manual individual adds - there is no CSV import path. Switching from 'Allow for all members' back to 'Allow for selected members' requires manually re-adding every user who should retain access, which is operationally expensive at scale.

The most consistent friction point reported by admins is the EMU requirement for SCIM provisioning. EMU forces organizations onto a separate, isolated GitHub enterprise with managed accounts, which is a hard architectural break from existing GitHub organizations using personal accounts.

A related constraint - one GitHub Enterprise Cloud instance per Entra ID tenant when using OIDC - blocks multi-enterprise setups under a single IdP.

Admins also flag the billing behavior on removal: seats stay active and billable until the cycle ends, with no refund mechanism. The manual idle-seat review process compounds this, since there is no automated way to surface or reclaim unused seats.

Common complaints:

• EMU (Enterprise Managed Users) is required for SCIM provisioning of Copilot, which forces organizations to use a separate, isolated GitHub enterprise with managed accounts rather than their existing GitHub organization with personal accounts.
• One GitHub Enterprise Cloud instance per Entra ID (Azure AD) tenant when using OIDC for SSO, which is a hard architectural constraint that blocks multi-enterprise setups under a single IdP tenant.
• Seat billing continues through the end of the billing cycle after a user is removed, with no prorated refund, making it costly to offboard users mid-cycle.
• No automated idle-seat reclamation; admins must manually identify and remove unused seats by reviewing last-activity dates.
• Switching from 'Allow for all members' to 'Allow for selected members' requires manually re-adding every user who should retain access, which is operationally burdensome in large organizations.
• No CSV import for bulk seat assignment; large-scale provisioning requires either SCIM (EMU only) or manual team-based assignment.
• Copilot Free and Pro plans are entirely self-serve and cannot be centrally managed or reported on by enterprise admins, creating a shadow-IT risk.
• Complex licensing model with five tiers (Free, Pro, Pro+, Business, Enterprise) creates confusion about which features are available at each tier and which plan is required for centralized management.

Every app and user in your GitHub org is subject to the same two-layer policy model, so the decision point is really about whether your provisioning volume justifies the EMU migration cost.

GitHub Copilot Business ($19/user/month) covers centralized policy management, audit logs, and org-level seat control - sufficient for most teams that do not need SCIM or knowledge bases. Copilot Enterprise ($39/user/month) is required for SCIM provisioning, and only through EMU, which carries significant IdP and architectural prerequisites.

Teams already on GitHub Enterprise Cloud with EMU configured will find the provisioning path straightforward. Teams on standard GitHub organizations should weigh the EMU migration cost against the operational overhead of manual seat management before committing to the Enterprise tier.

Bottom line

GitHub Copilot's admin model is functional but tightly coupled to GitHub's existing enterprise hierarchy, which means every app and user lifecycle action - provisioning, deprovisioning, idle-seat cleanup - inherits the constraints of that hierarchy.

Manual seat management is viable for smaller organizations but becomes operationally burdensome at scale without SCIM, and SCIM itself requires a full EMU migration that many teams are not positioned to undertake.

The billing model, which charges through the end of the cycle on removal with no proration, raises the cost of any provisioning error and makes accurate, timely offboarding more consequential than in most SaaS tools.