Licensing answers who has Copilot. It doesn’t answer what they’re allowed to do with it, and that’s a different question with a different owner: enterprise policy.
Skip this bit and you’ll find out the hard way, usually when someone asks a perfectly reasonable question about what Copilot’s allowed to see or suggest, and nobody in the room has a confident answer.
What enterprise-level policy controls vs org-level
Policy in GHE stacks in layers, and the enterprise level decides how much room the org level actually has. The clearest example of this is model availability.
At enterprise level, each model gets one of three settings. Let organisations decide, which hands control down. Enabled everywhere, which switches it on for every org and can’t be turned off at the org level. Disabled everywhere, same thing in reverse.
That’s the whole relationship in one setting. Two out of three options remove the choice from the org entirely. Only “let organisations decide” actually passes anything down.
What’s actually on the policy screen
At enterprise level, the Copilot policy screen covers a few things at once. Access management, which is licensing, covered in Part 3. Policies for enterprise-assigned users, which decides whether users provisioned at enterprise level get the full feature set or whether that’s left to the org. Content exclusion, for files and repos Copilot shouldn’t be reading. Suggestions matching public code, which is exactly what it sounds like. And the Models section, where the enabled, disabled, or let-orgs-decide pattern from above repeats individually for every model you’ve got access to.
Drop down to an individual org and the equivalent screen looks similar but narrower, because most of the big decisions have already been made one level up. Billing controls whether the org can exceed its included AI credit usage, with a budget you can cap it at. Features covers whether Copilot works in github.com itself, in the IDE, and whether editor preview features, including MCP servers, are switched on.
None of it exists to be reconfigured for its own sake. It exists because the enterprise level specifically left it as a decision for the org to make.
Where governance choices commonly trip teams up
The actual trip-up isn’t any one setting. It’s where you choose to put the decision.
Keep something at enterprise level and there’s exactly one place to look. One screen, one source of truth, one answer to “is this on or off” that doesn’t involve checking anything else first. Push it down to org level and that goes away. Now it’s one screen per org, and if you’ve got more than a couple of orgs, that’s more than a couple of places something can quietly drift without anyone noticing.
It gets more interesting once the admins aren’t the same people. At enterprise level you’re usually looking at the same small group who own the enterprise itself. Devolve a setting to org level and you might be handing it to engineering, giving them genuine control over their own environment. Often that’s the right call. It’s also exactly how sprawl starts. Different orgs make different calls, for good reasons at the time, and a few months later nobody can tell you why org A allows something org B doesn’t.
None of this means centralise everything. Some things genuinely should be an org decision. Just go into it knowing that every setting you devolve is one more place someone has to remember to check.
Closing thought
Access, licensing, policy. Three different layers, three different owners, and it’s easy to get the first two right and still leave the third as an afterthought. Worth treating it as part of the same rollout, not a follow-up task for whenever there’s time.
