GitHub Copilot MCP Allowlist: What Enterprise Devs Must Know

GitHub introduced two new enterprise managed-settings keys, `allowedMcpServers` and `deniedMcpServers`, on August 6 to let organizations centrally control which MCP servers GitHub Copilot can run. The allowlist enforcement is fully supported only in the GitHub Copilot app, Copilot CLI v1.0.11+, and VS Code v1.109.3+, with JetBrains, Eclipse, and Xcode in public preview and Copilot Cloud Agent unsupported. GitHub's documentation explicitly states that the `serverName` matcher is not a security control, and the move follows a 2026 disclosure of approximately 200,000 vulnerable MCP instances and the postmark-mcp backdoor in September 2025 that reached around 300 organizations.

GitHub shipped something enterprise developers have been asking for since MCP servers started appearing in every team’s IDE config: centralized control over which ones Copilot can actually run. Two new keys — allowedMcpServers and deniedMcpServers — landed in the enterprise managed-settings file on August 6 https://github.blog/changelog/2026-08-06-mcp-allowlists-in-enterprise-managed-settings/ . Policy changes go through a git-reviewable workflow, configs fail closed, and one of the three matching methods is explicitly documented as not being a security control. That last part is the one to watch. What the Two Keys Do The configuration lives in your organization’s .github-private repository under copilot/managed-settings.json . allowedMcpServers works as an allowlist: only servers matching at least one entry are permitted to run. deniedMcpServers blocks specific servers, and deny rules always win — even if a server also appears in the allowlist. First-party Copilot servers are exempt from denial rules. A minimal configuration looks like this: { "allowedMcpServers": { "serverUrl": "https://mcp.example.com/ " }, { "serverCommand": "uvx", "args": "approved-mcp-tool" } , "deniedMcpServers": { "serverUrl": "https://untrusted-mcp.example.com/ " } } When settings come from multiple layers — enterprise, organizational, team — a server must pass every layer. The overridable flag lets individual teams add approved servers on top of your enterprise baseline without overriding the whole policy. Three Matchers, Two Real Security Boundaries GitHub supports three ways to identify MCP servers in your policy. This is where teams who skim the docs will make mistakes. serverUrl — matches remote HTTP/SSE endpoints. Supports wildcards. URLs are canonicalized to prevent bypass attempts. This is a real security control. serverCommand — matches local stdio servers by exact command and arguments. Highest-risk scenario, since these run local processes. Also a real security control. serverName — matches user-assigned labels. GitHub’s own documentation https://docs.github.com/en/copilot/reference/mcp-allowlist-enforcement states this is “only supplied as a convenience, not a security control, since users can rename servers.” Do not build enforcement policy on serverName . If a developer renames a blocked server, your allowlist becomes a suggestion. The Coverage Gap Here is what the announcement does not lead with: MCP allowlist enforcement is not available on every client your developers might be using. Fully enforced: GitHub Copilot app, Copilot CLI v1.0.11+ , VS Code v1.109.3+ Public preview only — pre-release builds: JetBrains v1.5.64+ , Eclipse v4.38+ , Xcode v0.47.0+ Not supported: Copilot Cloud Agent If your engineering team runs JetBrains on the production Copilot release, your allowlist is not enforced. JetBrains is one of the most common enterprise IDE choices — check which clients your teams are actually running before declaring your MCP governance posture complete. Why This Shipped Now The MCP ecosystem grew faster than anyone’s threat models. A 2026 disclosure found approximately 200,000 vulnerable MCP instances across IDEs, internal tools, and cloud services. The attack patterns are not theoretical: tool poisoning embeds hidden instructions in tool descriptions that large language models read as trusted directives — silently, on every invocation, until someone investigates. The postmark-mcp backdoor in September 2025 https://pipelab.org/blog/state-of-mcp-security-2026/ was the first publicly documented in-the-wild malicious MCP server and reached around 300 organizations before anyone flagged it. GitHub is not shipping this feature because the MCP ecosystem matured. They are shipping it because security teams started asking hard questions about what these agents can reach. How to Roll This Out Before enabling allowlists, do the groundwork first. Enumerate existing MCP servers. Get a list of every URL and local command your developers are currently running through Copilot. You cannot write a useful allowlist from imagination. Write rules using serverUrl and serverCommand only. Leave serverName out of any enforcement-critical rules. Document your coverage gaps. Note which clients on your team are not yet enforced and treat those as open risks until JetBrains, Eclipse, and Xcode graduate from public preview. Use overridable for team flexibility. Let teams add approved servers on top of the enterprise baseline rather than routing every request through a central approval queue. The configuration’s best feature is also its simplest: it lives in a git repository. An allowlist you can review in a pull request — and revert with a single commit — beats a policy buried in a settings console that nobody checks. What Is Still Missing This feature answers which servers Copilot can reach. It does not answer what those servers can do once connected. Tool-level allowlisting — restricting specific operations within an approved server — is the next frontier. Community discussions have requested it, but GitHub has not committed to a timeline https://docs.github.com/en/copilot/reference/enterprise-administrators/enterprise-managed-settings . The cloud agent surface remains entirely outside enforcement scope. Both gaps matter in regulated environments where blast radius needs to be bounded at the tool level, not just the server level. MCP governance in enterprise development tools is moving from opt-in curiosity to mandatory control surface. Deploy this, document the gaps, and track when the preview clients reach general availability.