GitHub made MCP allowlists generally available in enterprise managed settings on 6 August. Two keys in one JSON file decide which MCP servers Copilot clients are allowed to run.
The feature is simple. Rolling it out is not, for one reason: it fails closed. A configuration that is ambiguous or unverifiable blocks the server rather than allowing it, so an allowlist written in an afternoon and pushed to everyone is a way to stop your developers working on a Monday morning. This is the order that avoids that.
Step 1 — Inventory before policy
You cannot write a sensible allowlist for servers you do not know about, and every organization of any size has at least one MCP server nobody remembers approving.
Ask three questions and write down the answers before you open the JSON file:
- Which MCP servers are remote, run by a vendor, reached over a URL?
- Which are local — a process launched on a developer machine, with that machine's access?
- For each one: who set it up, what does it read, and would it be a problem if its contents appeared in a pull request comment?
Step 2 — Decide your posture in one sentence
Write it down before you write config, because the file is easier to argue about than the intent behind it.
There are really only two honest postures. "Everything is allowed except what we have specifically blocked" is a starting posture — cheap, low-friction, and it buys you time to learn what people depend on. "Nothing is allowed except what we have specifically approved" is the destination, and it is the one that actually constrains risk.
Most organizations should start at the first and move to the second within a quarter. Declaring the second on day one and then spending three months granting exceptions is how the whole thing gets abandoned.
Step 3 — Choose how you name each server
You get three matching methods, and they are not interchangeable:
- Remote URL, with wildcards — good for approving or blocking a vendor wholesale, blunt by design
- Local command — the one that covers servers launched on developer machines, which is where the least-audited access usually lives
- Label — you name the server yourself and write policy against the name, so a URL change does not silently break the rule
Step 4 — Stage it, because fail-closed punishes speed
Put the file in `copilot/managed-settings.json` on the default branch of your source organization's `.github-private` repository — but do not put your final policy there first.
Roll out to one organization, ideally one whose developers will tell you loudly and quickly when something breaks. Watch for a week. Every "my MCP server stopped working" report in that week is free information: either it is a server you did not know about, which is the inventory problem you thought you had solved, or it is a typo in your config, which is exactly what fail-closed is designed to surface.
Only then widen it. And when you widen it, tell people it is happening before it happens — a blocked tool with no explanation generates a support ticket, while a blocked tool with a Slack message the week before generates an exception request, which is the conversation you actually want.
Step 5 — Be honest about what it does not cover
Enforcement today covers the Copilot app, the Copilot CLI and VS Code. That is most usage in most organizations and it is not all of it.
If your developers run agents in JetBrains, in another editor, or in a tool that is not Copilot — Cursor, Claude Code, an open-source terminal agent — this policy does not reach them. Write that limitation into the same document as the policy. A control whose gaps are undocumented gets cited in a risk review as though it had none, which is worse than not having it.
Step 6 — Give it an owner and a review date
An allowlist is not a project, it is a living list, and the failure mode is not a breach — it is drift. Six months on, the list contains three servers that no longer exist and is missing five that do.
Name one person accountable for it, put a recurring review in the calendar, and make adding a server to the list part of whatever process already exists for adopting a new tool. If approving an MCP server is easier than filing a ticket, the list will stay accurate; if it is harder, people will route around it.