12.3 Enterprise Managed Users and Copilot Policy

Why GH-900 pairs EMUs with Copilot policy

The third Domain 6 bullet is explain Enterprise Managed Users (EMUs) and organization-wide Copilot policy management. Both topics are enterprise administration, not personal Free-plan features. EMUs answer “who is this GitHub user, and can they touch the public internet?” Copilot policy answers “which licensed members may use which AI surfaces, on which files?” GH-900 does not ask you to click every SCIM attribute; it asks you to recognize the control plane.

What Enterprise Managed Users are

With Enterprise Managed Users, the enterprise manages the lifecycle and authentication of users on GitHub.com or GHE.com from an external identity provider (IdP):

• The IdP provisions new user accounts on GitHub with access to the enterprise (SCIM—System for Cross-domain Identity Management).
• Users authenticate at the IdP to reach enterprise resources (SAML or OIDC). They have no GitHub password and no 2FA methods stored on GitHub, so they do not see GitHub's sudo prompt. 2FA, if any, lives on the IdP (except the enterprise setup user).
• You control usernames, profile data, organization membership, and repository access from the IdP.
• With OIDC SSO, GitHub can honor the IdP's Conditional Access Policy (CAP).
• Managed user accounts cannot create public content or collaborate outside the enterprise.

EMU is not the default for every GitHub Enterprise Cloud customer. GitHub tells admins to choose an enterprise type first. On the exam, if the company needs IdP-owned accounts that cannot leak to public GitHub, pick EMU—not “invite personal GitHub.com accounts and hope SAML is enough.”

GitHub automatically builds each username by normalizing an IdP identifier. If normalization strips the unique part, usernames can collide. The profile name and email come from the IdP. Managed users cannot change them on GitHub. The IdP can send only one email. Changing email in the IdP unlinks contribution history tied to the old address.

Partner IdPs and the “do not mix” rule

GitHub partners with identity products for a paved-path EMU integration. Use a single partner IdP for both authentication and provisioning if you want GitHub's full support:

Entra ID is the partner that supports OIDC in that table. Okta and PingFederate authenticate EMUs with SAML, not OIDC.

You may use another IdP or combination if it speaks SAML 2.0 and SCIM 2.0 to GitHub's REST API, but GitHub does not test every mix and Support may not help. The combination of Okta and Entra ID for SSO and SCIM, in either order, is explicitly not supported; GitHub's SCIM API returns an error on provisioning attempts.

Roles such as enterprise member, owner, or guest collaborator can be assigned in the IdP. Organization membership can be manual or synced from IdP groups. Guest collaborators cannot access internal repositories except in organizations where they are added as members.

By default, an unauthenticated visitor hitting the enterprise sees a 404. Admins can optionally redirect to SSO instead.

What managed users cannot do, and how Copilot policy is administered

Abilities and restrictions of managed user accounts

Managed users may contribute only to private and internal repositories in the enterprise and to their own private repositories. On GitHub.com they have read-only access to the wider community. The wall applies to the API as well as the UI.

They cannot, outside the enterprise: push, open issues or pull requests, create or comment on discussions, comment or react, star, watch, or fork, or follow users. They cannot be invited to orgs, repos, or enterprises outside their own. Other GitHub users cannot see, mention, or invite them. They cannot create gists or personalized profiles. User-owned repos, if policy allows creation at all, are private only and may invite only other enterprise members. They cannot fork repositories from outside the enterprise.

Copilot-specific EMU facts:

• Managed users cannot sign up for Copilot Pro or Copilot Free. An admin must grant a Copilot Business or Copilot Enterprise seat.
• Copilot cloud agent is not available in personal repositories owned by managed users, because it needs GitHub-hosted runners, which those personal repos do not get.

EMU is a collaboration boundary, not merely “SSO is on.” A personal GitHub.com account with SAML to an ordinary enterprise can still have public repos and outside work. A managed user cannot.

Organization-wide Copilot policy: seats, features, Agent Mode, exclusions

GitHub Copilot is not currently available for GitHub Enterprise Server. Policy questions assume GitHub.com / GitHub Enterprise Cloud Copilot Business or Enterprise seats. Personal Free/Pro/Pro+/Max plans from Domain 4 are not the org policy surface. When a user is added to a Business or Enterprise plan, their individual Copilot plan is cancelled, so personal settings cannot override the company.

Who enables what:

1. Enterprise owners (on the enterprise AI controls tab) decide whether Copilot is on for organizations, and they set enterprise policies: enable everywhere, disable everywhere, or let organizations decide. For Copilot cloud agent, enterprises can pick exactly which organizations receive it. Users licensed directly from the enterprise follow Policies for enterprise-assigned users, not the “let orgs decide” default.
2. Organization owners then open Settings → Copilot. Policies control privacy and feature availability (including agentic surfaces such as Agent Mode). Models control catalogs beyond included models (extra AI-credit cost). Access grants seats.
3. If the enterprise already locked a policy, the organization cannot override it.

Member assignment is how seats become people. After Copilot is enabled for the org, owners go to Copilot → Access and either purchase for all current and future members or purchase for selected members (users, teams, or a CSV of usernames/emails). Billing starts when you grant access, not when the developer first types a completion; mid-cycle grants are prorated. You can also assign via the REST API. Outside collaborators can receive a Copilot seat without an org-membership invite. GitHub notes that successful rollouts often let developers claim a license self-service.

File exclusions (content exclusion) hide paths from Copilot. Repository administrators, organization owners, and enterprise owners manage the lists; people with the Maintain role can view but not edit a repository's exclusions. Organization exclusions apply to users assigned a Copilot seat by that organization; enterprise exclusions apply to all Copilot users in the enterprise. Paths use fnmatch patterns (secrets.json, *.cfg, /scripts/**). Changes can take up to 30 minutes to reach IDEs already running.

The documented hole GH-900 can test: GitHub Copilot CLI and Agent Mode in Copilot Chat in IDEs do not support content exclusion. An org can hide .env files from ordinary completions and Chat and still need a separate policy for Agent Mode and the CLI. Do not tell the exam that a path exclusion is a universal kill switch for every Copilot surface.

Policy conflicts: inside one enterprise, if two organizations grant the same person a seat and disagree, the least restrictive setting usually wins (with documented exceptions). If the person has seats from different enterprises, the most restrictive enterprise policy almost always wins.

Exam traps for D6.3

• EMU ≠ ordinary SAML SSO on personal accounts. EMU accounts are IdP-provisioned and cannot publish public content or work outside the enterprise.
• Profile and email are IdP-owned. Users cannot edit them on GitHub.
• Entra ID / Okta / PingFederate are the partner IdPs. Only Entra ID has OIDC in the partner table. Do not mix Okta and Entra ID for SSO and SCIM.
• Managed users cannot self-serve Copilot Free or Pro. Grant a Business or Enterprise seat.
• Copilot is not on GitHub Enterprise Server.
• Seats are assigned; features are policy. Enabling Copilot for the org is not the same as turning on Agent Mode or cloud agent for everyone.
• Content exclusion does not cover Agent Mode or Copilot CLI.
• Enterprise policy beats organization policy when the enterprise already chose enable or disable.