GitHub Copilot MCP Allowlists: Enterprise Setup Guide

GitHub made enterprise allowlists for Model Context Protocol (MCP) servers generally available on August 6, 2026. Enterprise owners can now use allowedMcpServers and deniedMcpServers in managed Copilot settings to control which remote and local MCP servers developers may run in Visual Studio Code (VS Code), Copilot CLI, the GitHub Copilot app, and JetBrains IDEs. The practical consequence is that enterprises no longer have to rely only on user guidance to limit these tool connections. Administrators can define a central baseline, match remote servers by URL or local servers by exact command, and block anything outside policy. Existing Copilot deployments should inventory current MCP connections before enabling an allowlist, because an empty or incomplete list can stop required tools from running.

Key takeaways

GitHub’s MCP allowlist and denylist controls became generally available on August 6, 2026.
Enforcement currently covers Copilot CLI, VS Code, the GitHub Copilot app, and JetBrains IDEs; the current support matrix marks the Copilot cloud agent as unsupported for these keys.
Use serverUrl for remote HTTP or Server-Sent Events (SSE) servers and serverCommand for local standard input/output (stdio) servers. serverName is not a reliable security identity because users choose the label.
An allowlist blocks every MCP server that does not match. An empty allowlist blocks all except built-in default servers; omitting the key allows all servers unless a deny rule applies.
Deny rules override allow rules. Across multiple policy sources, allowlists intersect and denylists combine.
MCP admission control is only one layer. It does not validate a server’s tools, permissions, data handling, or future updates.

What changed in GitHub Copilot

MCP lets an AI client connect to external tools and data. A server might expose repository operations, a browser, a database, an internal ticketing service, or a local command. That flexibility also creates a governance question: which connections may an enterprise Copilot client start?

GitHub’s August 6 release added two generally available keys to enterprise managed settings:

allowedMcpServers defines the MCP servers that may run. Once the key is present, a server must match at least one entry.
deniedMcpServers defines servers that must not run. A matching denial wins even when the same server also matches the allowlist.

The controls are part of copilot/managed-settings.json, the same enterprise configuration discussed in the GitHub Copilot app enterprise policy guide. They govern MCP server admission rather than deciding whether a user may access a Copilot client.

GitHub documents three matcher types in its enterprise managed settings reference:

Matcher	Use it for	Important limitation
`serverUrl`	Remote MCP servers reached over HTTP or SSE	Patterns support restricted wildcards; review the complete host and path scope
`serverCommand`	Local stdio servers launched by a command and arguments	The command and every argument must match exactly; wildcards and shell expansion are not supported
`serverName`	Any server, including in-memory servers that have no URL or command	The user assigns the label, so GitHub says it is a convenience rather than a security control

This is a meaningful improvement for enterprises adopting tool-using agents. It creates a centrally enforceable admission boundary, but it does not make every admitted server trustworthy. The controls here are specific to managed GitHub Copilot clients and do not replace server authentication, tool-level authorization, or source review.

How allow and deny rules are evaluated

Understanding the default behavior matters more than copying a sample file.

Omitted, empty, and populated allowlists differ

GitHub documents three distinct states for allowedMcpServers:

If the key is omitted, all MCP servers remain eligible unless a deny rule blocks them.
If it is an empty array, all MCP servers are blocked except GitHub’s built-in default servers.
If it contains entries, only matching servers are allowed, subject to denials from every policy layer.

That makes the empty array a useful lockdown state, but also a potentially disruptive change. Inventory required servers first and test representative workflows before moving from an omitted key to an allowlist.

Denials always take priority

GitHub says a server matching deniedMcpServers is blocked even if an allow entry also matches it. First-party Copilot servers, including the built-in GitHub MCP server, are exempt from deny rules and cannot be blocked through this setting. Administrators who require a different boundary should not assume the denylist covers those built-in services.

Multiple policy sources become more restrictive

GitHub’s documented precedence order is mobile device management (MDM), server-managed settings, file-based settings, then user settings. MCP list behavior has an additional composition rule:

Effective allowlists are the intersection of all applicable sources. A server must be allowed everywhere.
Effective denylists are the union of all applicable sources. A denial anywhere blocks the server.

This fail-closed behavior helps prevent a lower policy layer from widening access, but it can make troubleshooting less obvious. When a known server is blocked, inspect every policy source rather than only the .github-private repository.

Configure a central MCP server policy

For server-managed deployment, an enterprise owner stores the policy in a source organization’s private governance repository at:

copilot/managed-settings.json

A minimal policy can combine a remote URL, an exact local command, and a denial:

{
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example.com/*" },
    { "serverCommand": ["npx", "-y", "[email protected]"] }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://experimental.example.com/*" }
  ]
}

This example illustrates GitHub’s schema; the sample domains and package must be replaced with reviewed enterprise values. Editorial guidance: pin a local package to an approved version where the runtime and package manager support it. A broad tag such as latest can change what code runs without a policy-file change.

Match remote servers by controlled URL scope

serverUrl accepts * wildcards for subdomains or path prefixes. GitHub normalizes URLs before matching: among other steps, it lowercases the scheme and host, converts internationalized hostnames to Punycode, removes default ports and fragments, and decodes percent-encoded host octets. This reduces simple attempts to evade a rule through alternate URL spelling.

URL normalization is not server assurance. Editorial guidance: approve the operator, authentication method, tenant boundary, data retention terms, and change process separately. Prefer the narrowest stable hostname and path that identifies the intended service. Avoid a wildcard that admits unrelated applications on a shared domain.

Match local servers by the full command

serverCommand compares the executable and every argument exactly. The matcher is appropriate for local stdio servers and does not apply to remote servers, even when their configuration includes a command. If different operating systems launch the same approved server through different commands, each supported form needs its own entry.

Exact matching can reduce accidental substitutions, but it does not verify the contents behind an executable or package name. Editorial guidance: combine the allowlist with package provenance, version pinning, endpoint protection, least-privilege credentials, and the relevant Copilot sandbox controls. The AI agent evaluation security guide explains why network isolation, short-lived credentials, monitoring, and stop controls remain useful for tool-using agents.

Do not use a display name as the trust anchor

GitHub explicitly warns that serverName is user assigned. A developer can rename a server, so the label does not prove which endpoint or executable sits behind it. Reserve name matching for cases where no stronger property exists, such as an in-memory server, and document the residual risk.

Choose a deployment method

GitHub’s configuration guide offers three deployment methods.

Server-managed settings

GitHub describes server-managed settings as the default for most enterprises and the best option for review history. Commit copilot/managed-settings.json to the default branch of the selected .github-private repository. GitHub says supported users normally receive changes within about an hour; restarting the client or signing in again triggers an immediate refresh.

MDM-managed settings

MDM delivery fits managed Windows and macOS device groups. Values are delivered as operating-system-managed strings rather than as a JSON file. Linux does not support native MDM delivery in GitHub’s current documentation. A client checks for new policy hourly.

File-based settings

File-based policy works across macOS, Windows, and Linux, including environments where server delivery is unavailable. Its weakness is coverage: a device that does not receive the file is not restricted by it. GitHub also specifies ownership and permission checks for Copilot CLI files on macOS and Linux.

Server-managed policy is generally the clearest starting point when the enterprise needs reviewable changes and user-linked delivery. MDM or file policy can add device-side resilience. GitHub notes that a Copilot CLI session without a cached server policy may lack that server-managed policy if retrieval fails, so organizations with an offline enforcement requirement should evaluate a device-based layer.

Apply different rules to enterprise teams

GitHub allows allowedMcpServers and deniedMcpServers to be marked overridable in server-managed deployments. An enterprise can then map different files under copilot/teams/ to enterprise team slugs through copilot/team-mappings.json.

This is useful when, for example, a data team requires an approved warehouse connector while most developers do not. The enterprise still defines which settings teams may specialize. GitHub says users who belong to multiple mapped teams receive the least restrictive combined team value, which is then applied beneath the enterprise settings where platform decisions still win.

Editorial guidance: start with a small baseline and add servers only for groups with a documented need. Record an owner, purpose, data classification, credential scope, and review date for each approved connection. Team specialization should not become a way to bypass central vendor or security review.

What this means

For an enterprise already using MCP, the immediate decision is whether it can name every server that should run. If yes, a positive allowlist creates a clearer boundary than guidance alone. If no, begin with discovery and a pilot rather than deploying a guessed list that either blocks work or admits overly broad domains.

For a small team without GitHub Enterprise administration, this release may not change day-to-day setup. Local configuration, permission prompts, credential scope, source review, and code review remain the practical controls.

Official fact: GitHub provides URL and command admission rules and says malformed or unverifiable configurations fail closed. Editorial inference: organizations should treat this as one control in a layered agent-security program, not as certification of the tools exposed by an allowed server.

Rollout decision criteria

Deploy an allowlist now when the enterprise has a complete MCP inventory, stable server identities, a protected policy repository, owners for every exception, and a way to test all supported clients in use.

Pilot first when servers use changing commands, shared hosting makes URL patterns broad, teams have materially different requirements, or administrators cannot explain which policy layer currently wins.

Keep an emergency change path. A compromised server may need to be denied quickly, while a critical server identity change may require a coordinated allowlist update. The response process should specify who can approve and deploy either change.

Verification checklist

Frequently asked questions

Which GitHub Copilot clients enforce MCP allowlists?

As of August 12, 2026, GitHub’s current support matrix lists Copilot CLI, VS Code, the GitHub Copilot app, and JetBrains IDEs as enforcing these keys; it marks the Copilot cloud agent as unsupported.

What happens if `allowedMcpServers` is empty?

GitHub says an empty array blocks all MCP servers except built-in default servers. If the key is omitted instead, servers are allowed unless a deny rule blocks them.

Can a deny rule override an allow rule?

Yes. deniedMcpServers takes precedence. GitHub also says denials from multiple settings sources combine, while allowlists intersect.

Should an enterprise match an MCP server by name?

Not when URL or command identity is available. GitHub says serverName is user assigned and therefore should not be treated as a security control. In-memory servers can only be matched by name, so that case requires an explicit risk decision.

Does an MCP allowlist make an approved server safe?

No. It controls whether a matching server may run in supported Copilot clients. It does not independently verify the server operator, source code, exposed tools, credential scope, data retention, or updates.