2.4. Organization-Wide Settings and Policies
💡 First Principle: Organization controls exist because Copilot at scale is a governance problem, not just a developer feature. Admins decide who can use Copilot, which features are available, how code review behaves, and they get audit trails and APIs to manage it all. Individual IDEs only reflect these decisions.
Why this matters: a recognizable share of this domain is administrative. Questions describe an admin who needs to enable or restrict a feature org-wide, track Copilot-related events, or manage seats programmatically. The recurring theme: these are admin powers on Business/Enterprise plans, not user toggles.
The mental model: Copilot policies are the building's facilities management. Individual tenants (developers) use the space, but lighting, access badges, and the security log are controlled centrally.
⚠️ Common Misconception: "Any developer can turn Copilot policies on or off in their IDE." Organization-wide policy management — feature availability, code review policies, public-code matching — is controlled by org/enterprise admins. The IDE enforces the policy; it doesn't override it.
