Study guide
12.3 Enterprise Managed Users and Copilot Policy
GitHub Foundations GH-900
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Domains, Scoring, and Candidate Profile 1.3 Official Resources and Hands-On Prep
2 Version Control Fundamentals
2.1 Purpose and Benefits of Version Control 2.2 Git vs GitHub 2.3 Repositories, Commits, and History 2.4 Branches, HEAD, and the Default Branch
3 Working with GitHub
3.1 Accounts, Organizations, and Enterprise Options 3.2 GitHub Flow 3.3 Markdown for Issues and Pull Requests 3.4 GitHub Desktop and GitHub Mobile
4 Repository Structure and Key Files
4.1 Repository Structure and Community Health Files 4.2 Creating Repositories with Templates and Branches 4.3 Adding and Managing Files
5 Repository Insights and Maintenance
5.1 Insights, Stars, Dashboards, and Dependency Insights 5.2 Repository Maintenance and Collaboration Best Practices
6 Issues and Pull Requests
6.1 Issues 6.2 Pull Requests 6.3 Linking PRs, Templates, Filters, and Assignments
7 Discussions, Notifications, and Documentation
7.1 Discussions 7.2 Notifications and Workflow Management 7.3 Gists, Wikis, and GitHub Pages
8 GitHub Actions
8.1 Actions Purpose, Workflows, and Events 8.2 Jobs, Steps, Runners, Secrets, and Reusable Actions
9 GitHub Copilot
9.1 Copilot Suggestions, Agents, Agent Mode, and Multi-Model Support 9.2 Copilot for Individuals, Business, and Enterprise
10 Codespaces and github.dev
10.1 Codespaces, Customization, and Dev Containers 10.2 github.dev vs Codespaces
11 Manage Projects with GitHub
11.1 GitHub Projects and Layout Options 11.2 Configuring Projects, Labels, Milestones, and Workflows 11.3 Saved Replies and Assignees 11.4 Project Insights
12 Account Security and Access
12.1 Two-Factor Authentication and Passkeys 12.2 Access Permissions and Roles 12.3 Enterprise Managed Users and Copilot Policy
13 Privacy, Branch Protection, and Organization Admin
13.1 Privacy, Visibility, and Branch Protection 13.2 Organization Settings, Teams, and Roles
14 Open Source, Sponsors, and InnerSource
14.1 Open Source Benefits and GitHub Sponsors 14.2 How GitHub Supports Open-Source Projects 14.3 InnerSource
15 Marketplace, Discovery, and Collaboration Models
15.1 Following Users and Organizations 15.2 GitHub Marketplace 15.3 Forks, Templates, and Discoverable Repositories
12.3 Enterprise Managed Users and Copilot Policy
Key Takeaways Explain This Topic AI
With Enterprise Managed Users (EMUs), the identity provider provisions accounts (SCIM) and authenticates them (SAML or OIDC); managed users cannot create public content or collaborate outside the enterprise.
A managed user's username, profile name, and email address come from the IdP; the user cannot change name or email on GitHub, and the IdP supplies only one email address.
Partner IdPs are Microsoft Entra ID (SAML, OIDC, and SCIM), Okta (SAML and SCIM), and PingFederate (SAML and SCIM); GitHub recommends one partner IdP for both authentication and provisioning, and mixing Okta with Entra ID for SSO and SCIM is not supported.
Organization and enterprise owners enable Copilot, assign seats to members or teams, and set policies for features such as Agent Mode, models, and file/content exclusions; Copilot is not currently available for GitHub Enterprise Server.
Content exclusion (file exclusions) does not apply to GitHub Copilot CLI or Agent Mode in IDE Chat, so those surfaces need a separate policy decision.
Last updated: August 2026
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:
- Partner IdP SAML OIDC SCIM
- Microsoft Entra ID Yes Yes Yes
- Okta Yes No Yes
- PingFederate Yes No Yes
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.
Loading diagram... EMU identity flow versus Copilot admin controls
- 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:
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.
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.
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.