GitHub Copilot Enterprise: Complete Guide

GitHub Copilot Enterprise: Complete GuideSecurity, Code Review & Enterprise9Advanced/github-copilot/security-enterprise/enterprise/

Enterprise is not Business with more switches. It is a different administrative model, and the difference is that decisions stop being made once and start being made at a level that then has to propagate — correctly, predictably, and to people who did not make them.

Two things dominate operating it: precedence, because it decides which setting actually applies, and delegation, because an enterprise that routes every decision through one person does not function.

Key takeaways

• AI controls are the surface. Agents, Copilot policies, MCP and clients each have their own section.
• Precedence is asymmetric. Within one enterprise the least restrictive setting usually wins across organisations; across enterprises the most restrictive almost always does.
• Delegation is a first-class control. “Manage enterprise AI controls” exists so policy management does not require enterprise ownership.
• Cloud agent policy has four states, including enabling for selected organisations.
• Third-party agents are governed separately. Restricting the cloud agent does not restrict them.

Where the controls live

The division is worth internalising because it mirrors how the policies actually behave. Agent policy is not a subset of Copilot policy; MCP is not a subset of either. They are separate surfaces with separate defaults, which is the root of most “I thought we had disabled that” conversations.

Who administers, and how to delegate

The delegated permission is the one to know about. Manage enterprise AI controls is a custom role permission, which means policy administration can be given to the people who should hold it — a platform team, a security engineer — without granting enterprise ownership.

AI managers are a distinct role in the agent-adoption context, able to manage those policies alongside enterprise owners.

Precedence, which is not what people assume

Read the first row carefully. Where several organisations inside one enterprise have configured the same policy differently, GitHub documents that the least restrictive setting usually applies, with exceptions.

The across-enterprise rule points the other way and matches intuition — the most restrictive policy across enterprises almost always applies. It is only the within-enterprise case that inverts, which is precisely why it catches people.

Designing the enterprise floor

The central design question is which policies belong at the enterprise level at all. Set too few and precedence resolves in ways nobody chose; set too many and the enterprise becomes a bottleneck that organisations route around.

A policy belongs at enterprise level when at least one of these is true.

A wrong answer is not recoverable by the organisation that gets it wrong. MCP being available with no allowlist is the clearest case — the consequences land outside the organisation that made the choice.

Consistency is the point. A control that means nothing unless it holds everywhere. Client policies frequently fall here: allowing the CLI in one organisation and not another is usually incoherent rather than nuanced.

The decision requires context organisations do not have. Contractual commitments, regulatory scope, what the security team agreed with a customer.

The least-restrictive rule would produce the wrong outcome. If you would be uncomfortable with the most permissive organisation’s setting applying to everyone, the decision belongs upward.

And it belongs to the organisation when the trade-off is genuinely local — which team needs which models, whether draft pull requests get reviewed, which repositories the cloud agent works in. Those decisions are better made by people who know the work.

Verifying that precedence resolved as intended

Because the within-enterprise rule is counterintuitive, intention and outcome diverge quietly. The only reliable check is empirical.

Find a user in more than one organisation. In most enterprises this is common — someone in a platform team plus a product team.

Check what they actually experience. Is the CLI available? Can they start an agent? Does an MCP server they should not have start?

Compare that against what each organisation configured. Where a user has a capability that one of their organisations disabled, you are looking at the least-restrictive rule working as documented.

Decide whether that is what you want. Sometimes it is — the permissive organisation made a deliberate choice and the user benefits. Often it is not, and the remedy is to move the policy to the enterprise level.

Agent governance

The area where Enterprise adds most over Business, and where the defaults deserve the most attention.

Selection by organisation custom property is the feature worth using here. It turns agent adoption from a list somebody maintains into a rule — organisations tagged as pilot participants get the agent, and the list updates itself when the tag changes.

Staging agent adoption properly

The four policy states exist so adoption can be progressive, and the selected- organisations state is what makes a real pilot possible at enterprise scale.

A sequence that works:

Start with one or two organisations that volunteered. Volunteers give better feedback than conscripts and their problems are real rather than resentful.

Tag them with a custom property rather than listing them. The policy then describes a rule — organisations with this property get the agent — and adding the third participant is a tag change rather than a policy change.

Let it run for several weeks. Long enough that the novelty passes and you are observing steady-state behaviour rather than enthusiasm.

Ask what broke. Repositories the agent could not build, tasks that consistently came back wrong, review load that increased more than expected. All of these are fixable and none appear in a dashboard.

Then widen the property, not the policy.

Third-party agents deserve their own decision

Because they are governed independently, they need a deliberate position rather than an inherited one.

The questions to answer, once, and record:

Which third-party agents are permitted? A named list beats an implicit allowance.

What repository access do they get? This is the substantive question. An agent’s usefulness and its risk both scale with what it can read and write.

How are they managed? Where the configuration lives, and who can change it.

What is the review cadence? Third-party agent capabilities change on the vendor’s schedule rather than yours.

MCP at enterprise scale

Enterprise MCP controls

Policy	Enterprise	Organization	Status	Surfaces it governs
MCP servers in CopilotMCP	Yes	Yes	GA	Copilot clients that support MCP
MCP allowlist in managed-settings.jsonMCP	Yes	No	GA	Copilot clients that read enterprise managed settings
MCP private registryMCP	Yes	Yes	Public preview	Copilot CLI and IDEs

What administrators most often get wrong

• MCP allowlist in managed-settings.json. This is the generally available mechanism GitHub recommends. The MCP private registry is a separate public preview feature and GitHub does not present it as the more secure option.
• MCP private registry. GitHub states private registries apply to Copilot CLI and IDEs but not to cloud agents running on GitHub.

Two facts shape the design, and both are easy to get backwards.

Managed settings are the generally available, recommended mechanism. GitHub describes the private registry as public preview and explicitly does not present it as the more secure option, which inverts the usual instinct to prefer the newer and more feature-shaped control.

Private registries do not reach cloud agents. GitHub states they apply to Copilot CLI and IDEs. Enforcement for the cloud agent comes from its own configuration in repository settings, plus whatever managed settings apply — which is a different place to check and easy to forget.

MCP security covers the allowlist format and the approval process.

Audit

What the audit log answers well: who changed which policy, when they changed it, and who holds a seat. That is genuinely most of what an enterprise governance question needs, and it is the part organisations most often fail to check they can retrieve until somebody asks for it.

What it does not contain: IDE prompts and Chat conversations. A governance model assuming prompt-level visibility assumes something that does not exist, and it is better to design around that than to discover it when asked.

Metrics at enterprise scope

Enterprise reporting covers aggregated, repository-level and per-user granularities, with access for enterprise owners, billing managers, and users granted the View Enterprise Copilot Metrics permission.

Two documented limitations to state whenever you publish a number:

Usage dashboard metrics exclude Copilot CLI. Terminal-heavy organisations under-report their own adoption, sometimes dramatically, and an executive summary that does not say so is misleading rather than merely incomplete.

Teams with fewer than five seated users on a given day are excluded from the user-teams report. Small teams simply vanish from team-level views.

Team adoption covers reading these without over-claiming.

Using the API rather than the interface

Policies can be managed through REST endpoints as well as through AI controls, and at enterprise scale that changes what is practical.

Three things become possible that are painful by hand.

Configuration as a reviewed artefact. Policy state expressed in a file, applied by a pipeline, changed through a pull request. The audit trail becomes the repository history, which is richer than an audit event and considerably easier to ask questions of.

Drift detection. A scheduled job comparing intended state against actual state catches the change somebody made during an incident and never reverted. This is the single most valuable thing to automate, because policy drift is silent by nature.

Consistency across organisations. Applying the same baseline to twenty organisations by hand is twenty opportunities to differ.

The reporting question

Enterprises are asked to demonstrate governance, and the request usually arrives without much specificity. What can honestly be produced:

Policy state. What is configured, at which level, and when it last changed. Solid, and the audit log supports it for the retention window.

Seat allocation. Who has access, and when it was granted to them.

Agent adoption. Which organisations, under which policy state.

Usage. From the dashboards and API, with the CLI exclusion stated.

What cannot be produced, and should be said plainly rather than approximated:

What developers asked Copilot. Prompts and Chat conversations are not in the audit log.

Which suggestions were accepted and where they ended up. Acceptance metrics exist in aggregate; a line-level provenance trail does not.

Proof that no confidential content reached a model. The controls are targeting controls with documented gaps, not a boundary that can be evidenced.

An operating rhythm

1. 1Set the enterprise floorHuman judgementPolicies that must hold everywhere. Few, and stable.
2. 2Delegate the restHuman judgementExplicitly, to organisations that should decide.
3. 3Grant the custom roleHuman judgementSo policy changes do not require enterprise ownership.
4. 4Stage agent adoptionSelected organisations, by custom property.
5. 5Define MCP managed settingsHuman judgementBefore anyone needs an allowlist.
6. 6Verify with a real userHuman judgementPrecedence is only observable this way.
7. 7Review quarterlyHuman judgementPolicies, delegation, agents, MCP, audit access.

Steps marked Human judgement are the ones that do not get delegated — they are where you decide whether what Copilot produced is actually right.

The enterprise layer should be small. Every policy set here is one that organisations cannot adjust for themselves, and the temptation to centralise everything produces a configuration that blocks legitimate work and generates a stream of exception requests nobody has time to process. An enterprise configuration that fits on one page and is genuinely enforced beats a comprehensive one that is quietly full of exceptions.

The quarterly enterprise review

Shorter than it sounds, and the only reliable defence against drift.

Policy state against intention. Read what is configured and confirm each setting still corresponds to a decision somebody made. Settings changed under pressure and never reverted are the common finding.

Delegation still correct. Who holds AI controls permissions, and whether that list has grown by accident.

Agent policy, both kinds. Cloud agent state, and third-party agents. On the same page, deliberately.

MCP managed settings against reality. What the allowlist says against what is configured in repositories.

Precedence spot-check. One multi-organisation user, checked empirically.

Audit access. At least two people, still.

One new organisation, checked. Anything created since the last review, and whether its defaults loosened anything.

Rolling out enterprise policy without breaking things

Changing an enterprise policy affects everybody at once, which makes the deployment question as important as the decision.

Announce restrictions before applying them. A capability that disappears without warning generates support requests and the belief that the tooling is unreliable. A week’s notice with a reason converts the same change into something people plan around.

Apply permissive changes immediately. Nobody needs notice that something now works.

Stage where the policy allows it. Agent policies support selected organisations, which means a change can reach a subset first. Use that even when the eventual intent is everyone.

Watch for a fortnight. Most problems surface as a question rather than an error, and questions arrive through channels no dashboard monitors — which is why the person who made the change should be reachable and known.

Record what you did and why. Six months later, the difference between a deliberate restriction and an accident is entirely whether somebody wrote a sentence at the time.

Common questions

Is Enterprise required to use agents at all? No — the agent surfaces are available under Business. What Enterprise adds is enterprise-wide governance over them: staged adoption states, selection by organisation property, and a single place the decision lives.

Can organisations override an enterprise policy? Where the enterprise explicitly delegates the decision, yes — that is what delegation means. Where the enterprise sets the policy directly, no, and being able to rely on that is the entire reason for setting anything at this level.

What happens if we set nothing at enterprise level? Organisation settings resolve among themselves, and within one enterprise the least restrictive usually wins. That outcome is a decision whether or not anybody made it deliberately, which is the argument for setting the small number of policies that genuinely matter rather than leaving the whole surface unconfigured.

How do we govern third-party agents? Separately from the cloud agent, and each one individually. There is no single switch.

Who should hold the AI controls permission? The smallest group that can act without becoming a bottleneck — typically a platform or security engineer plus one deputy, rather than every organisation owner. The permission exists precisely so this does not have to be solved by handing out enterprise ownership, which is the path organisations take when nobody knows the custom role exists.

How do we handle an urgent exception? Decide in advance who can grant one, for how long, and where it gets recorded. Emergency policy changes are legitimate; the problem is that they become permanent because nobody wrote down that they were temporary.

Should organisations see the enterprise configuration? Yes. Organisation owners who can see what was decided above them can plan; ones who cannot file support requests to find out. Publishing the enterprise floor removes a large category of confusion at no cost.

Does Enterprise change the data handling? The training and retention commitments GitHub documents cover Copilot Business and Copilot Enterprise. Private repositories covers what those commitments say.

Multi-enterprise organisations

A smaller case, and one where the intuition finally matches the documentation.

Where a user belongs to organisations in more than one enterprise — contractors, joint ventures, an acquisition mid-integration — GitHub documents that the most restrictive policy across enterprises almost always applies.

This is the opposite of the within-enterprise rule, and the practical consequences are worth knowing.

Restrictions compound across enterprises. A contractor working for two clients gets the intersection of what both permit, which can be considerably less than either intended and looks to them like the tool being broken.

You cannot loosen what another enterprise restricted. No amount of configuration on your side overrides it.

Diagnosis is genuinely hard. The user experiences a restriction with no visible source, and neither enterprise’s policy page explains it.

Next

Managing Copilot across an organization takes the view from one level down — the organisation owner who inherited some of these decisions, owns others, and has to explain both to developers.