Model Context Protocol servers give GitHub Copilot access to tools and data outside the editor. That is useful, but it also turns a developer configuration file into a security boundary. An MCP server may read project context, call an API, or perform an action on a developer's behalf. Teams need a way to decide which servers are allowed before everyone adds their own. GitHub's MCP server access controls provide that starting point with a registry URL and an Allow all or Registry only policy.
What an MCP allowlist actually controls
An enterprise or organization MCP policy decides whether Copilot can use any MCP server or only servers in an approved registry. GitHub calls these choices Allow all and Registry only. The policy applies to supported IDEs and Copilot CLI, and the selected policy takes effect immediately for developers in that organization or enterprise. The enforcement documentation also explains how policy conflicts are resolved when a person has more than one Copilot seat.
- Enterprise policy wins over organization policy.
- Registry only wins over Allow all when policies have the same scope.
- If scope and strictness match, the most recently uploaded registry wins.
Start with a small approved registry
Do not begin with a giant catalog of every server someone might want. Start with the few integrations your teams already need, document the owner and data access for each one, and add a review date. Copilot CLI uses the configured registry as a discovery source, while developers can still have local configuration files. When Registry only is active, only servers permitted by the policy can run. GitHub's Copilot CLI guidance is a useful reminder that the built-in GitHub MCP server is already available; these steps are for additional servers.
Registry review checklist
1. Name the server and its owning team.
2. Record the remote URL or exact local command.
3. List the repositories, APIs, and data it can reach.
4. Test the server with a non-production account.
5. Set an owner and a date for the next review.
6. Add it to the registry only after the review is complete.Treat a registry entry as an approval of a particular server, not an approval of every future version. Keep the server's release process and permissions in the same review. A server that is safe for read-only issue search may not be safe after write tools are added.
Remote and local servers need different matching rules
For a remote server, match the serverUrl. For a local stdio server, match the exact serverCommand and arguments. A friendly server name is useful for people, but it is not a substitute for a precise identity when a URL or command is available. This is especially important for local servers, where changing one argument can change what the process does.
Use managed settings for device-level guardrails
An enterprise registry controls the organization experience. Managed settings are the other layer: they let administrators govern Copilot CLI directly through server-managed settings, MDM, or a file deployed to managed machines. GitHub documents allowedMcpServers and deniedMcpServers for this purpose. The managed settings reference says an unset allowlist permits non-default servers, while an empty allowlist blocks them. A deny rule wins if a server matches both lists, and trusted first-party servers such as the built-in GitHub MCP server are exempt.
{
"allowedMcpServers": [
{ "serverUrl": "https://mcp.example.com/*" },
{ "serverCommand": ["npx", "-y", "@example/mcp-server"] }
],
"deniedMcpServers": [
{ "serverName": "untrusted-server" }
]
}Use an allowlist for the normal policy and a denylist for known exceptions. Keep the matchers narrow. A wildcard remote URL should cover only the path space you own, and a local command should include the arguments that pin the package or configuration. Add a deny rule when a server is known to be unsafe, even if a broad allowlist would otherwise permit it.
Know the current enforcement limits
GitHub's current MCP allowlist enforcement is not a complete software supply chain control. The documented limitation is that enforcement is based on server name or ID matching, which can be bypassed by editing configuration files. Strict enforcement that prevents installation of non-registry servers is not yet available. If you need the strongest available control, GitHub recommends disabling MCP servers until strict enforcement is available.
That limitation should change how you roll this out. A Registry only policy is valuable for discovery, consistency, and reducing accidental access. It should sit alongside endpoint management, trusted package sources, code review for configuration changes, and least-privilege credentials for every server. Do not describe it to developers as a guarantee that an unapproved binary can never run.
A rollout that keeps developers moving
- Inventory the MCP servers already used by your teams.
- Classify each server by data access, write capability, owner, and deployment type.
- Create a registry with a small approved set and publish an owner for every entry.
- Start with Allow all plus documentation if you need a migration period; move to Registry only when the common workflow works.
- Add device-level managed settings where machine policy needs to be stricter than the enterprise default.
- Review blocked-server feedback, add legitimate gaps deliberately, and revisit the registry on a schedule.
MCP governance works best when it is treated as an access review, not a one-time toggle. Keep the approved set understandable, make exceptions visible, and pair the policy with credentials that can do only what the server needs. You get a safer Copilot workflow without making every developer rediscover the same integration decisions.