MCP spent the last year becoming the way agents reach the rest of your systems. On 6 August, GitHub shipped the control that was missing: enterprise owners can now declare which MCP servers Copilot clients are permitted to run, and block the rest.
It is generally available, not a preview, and the enforcement behaviour is the part worth reading carefully.
How it works
Two keys go into `copilot/managed-settings.json` on the default branch of your source organization's `.github-private` repository:
- `allowedMcpServers` — the servers you have approved
- `deniedMcpServers` — the servers you want blocked outright
Three ways to name a server
A server can be matched by its remote URL, including wildcards; by the local command used to launch it; or by a label you assign yourself. Those three cover meaningfully different cases and you will probably use all of them.
Remote URLs with wildcards are the blunt instrument: approve a vendor's whole domain, or block one you do not trust. Local command matching is the one that matters most in practice, because a locally launched MCP server is a process on a developer machine with whatever access that machine has. Labels are the maintainable option — you name a server once and write policy against the name, which survives a URL change.
It fails closed, and that is the point
GitHub describes the design as fail closed: a configuration that is ambiguous or cannot be verified is blocked rather than allowed, and where policies stack, a server has to pass every layer.
This is the correct default and it will still surprise people. A policy with a typo does not quietly do nothing — it stops a server from running. Expect the first week of any rollout to produce a few "my MCP server stopped working" reports, and expect most of them to be your own configuration rather than the feature.
Plan for it: roll the file out to one organization first, watch what breaks, and only then widen it.
Know where it is not enforced yet
Enforcement currently covers the Copilot app, the Copilot CLI and VS Code. That is a large share of usage but it is not all of it, and the gap is the part your risk register cares about.
If your developers also run agents in JetBrains, in another editor, or in a tool that is not Copilot at all — Cursor, Claude Code, an open-source agent — an allowlist in GitHub's managed settings does not reach them. This is a control over Copilot clients, not a control over MCP.
The honest framing for a security review is: this closes a real gap on the surfaces most of your team uses, and it does not let you claim you have MCP under control everywhere.
What to do this week
Start with the inventory, not the JSON. You cannot write a sensible allowlist until you know what is actually running, and in most organizations the answer includes at least one server nobody remembers approving.
Then write the file in deny-nothing mode first if you can, learn what your developers depend on, and tighten from there. An allowlist that blocks the team's daily workflow on day one gets switched off on day two.