GitHub MCP allowlists: decide which servers your agents reach

Your coding agent is only as trustworthy as the tools it can reach. Every MCP server a developer wires into their editor is a new process with your repo, your tokens, and your customer data in front of it — and until now, most teams had no way to say which ones were allowed. GitHub just shipped that control. MCP allowlists landed in enterprise managed settings on August 6, and the default posture is the part worth reading.

What actually happened

Per GitHub's changelog, enterprise owners get two new configuration keys — allowedMcpServers and deniedMcpServers — set in copilot/managed-settings.json inside the source organization's .github-private repository. The policy applies across the GitHub Copilot app, Copilot CLI, and VS Code.

Three things in the design are worth stealing:

It fails closed. A malformed or unverifiable configuration is blocked, not allowed. Most policy systems fail open, which is how a typo becomes a permission.

Layers intersect, they don't override. Where multiple policy layers apply, a server has to satisfy all of them to run. Enterprise sets a baseline; teams can add their own on top when a key is marked overridable. Nobody widens the surface by accident.

Matchers are honest about what they prove. You can match on serverUrl (remote HTTP/SSE servers, wildcards supported), on serverCommand (exact command and arguments for local servers), or on serverName. GitHub says plainly that serverName matches a user-assigned label and is a convenience, not a security control. That is a rare and useful piece of documentation — the label is whatever the developer typed.

Why MCP allowlists matter for your business

We have watched this problem arrive at small companies faster than the tooling. A developer finds an MCP server on a list somewhere, adds it to their editor, and now an unaudited npm package sits between an agent with repo write access and the open internet. There is no purchase order, no vendor review, no ticket. It took ninety seconds.

The npm ecosystem has already shown what that pipe carries — hundreds of malicious packages published in single campaigns, aimed squarely at developer credentials. An MCP server is that same install with an agent holding the other end.

So do this, Copilot or not. Write down every MCP server anyone on your team has connected, with the exact command or URL. Most teams cannot produce that list today, and producing it is usually the finding. Pin the ones you keep to an exact command and version, not a name — GitHub is right that the label proves nothing. Default to deny for anything that touches production credentials, and make adding a server a change someone reviews.

The larger point: MCP won the interface argument, and the industry is now doing the boring work of deciding who is allowed to plug into it. Configuration keys in a JSON file are how governance actually ships. If your agent tooling has no equivalent — no allowlist, no fail-closed default — that is not a missing feature. That is the answer to a question you have not asked yet.

Sources: GitHub Changelog, Model Context Protocol specification.