2.4.1. Policy Management and Feature Availability
💡 First Principle: Policy management is a single control plane that decides, per organization or enterprise, which Copilot features are available and to whom — so the same plan can present different capabilities depending on what admins allow.
On Copilot Business and Enterprise, owners manage policies that govern feature availability across IDEs and GitHub.com: enabling or disabling specific features, controlling access for members, and managing things like suggestions that match public code or which models are permitted. Enterprise owners can decide which organizations get Copilot; organization owners decide which members do.
This is why two developers on identical plans can see different features (the thread running through 2.1.1 and 2.4): the enforced policy differs. Admins also review usage data to drive adoption and manage seats sensibly.
| Control | Who sets it | Effect |
|---|---|---|
| Feature availability | Org/Enterprise admin | Turns specific Copilot features on/off |
| Member access | Org/Enterprise admin | Grants or revokes Copilot for users/teams |
| Public-code matching | Admin policy | Blocks/flags suggestions matching public code |
| Model availability | Admin policy | Restricts which models developers may use |
⚠️ Exam Trap: Feature availability is set centrally. A developer "missing a feature" is frequently a policy decision, not a bug or a plan limitation — the troubleshooting path leads to the admin console.
Reflection Question: An org admin wants developers to be able to use Chat but not connect arbitrary MCP servers. At what level is that decided, and why can't an individual developer override it?
