Govern MCP servers at the client first: an enterprise allowlist that matches on the server's URL or its exact, version-pinned launch command, pushed through Claude Code and GitHub Copilot managed settings. Both cost nothing beyond the licences you already pay for. Put a gateway (Kong if you already run Kong, Docker's if you can get an invite) in front only of the remote servers that hold shared credentials. A registry is a catalogue, not a control. GitHub's own docs say its registry-only policy matches on server name or ID and "can be bypassed by editing configuration files", and Azure API Center describes itself as design-time governance, not a runtime gateway.
Here is the workload the comparison below is measured against, so every row is like for like. 300 developers across VS Code with Copilot and Claude Code, 25 approved MCP servers (15 remote, 10 local stdio), four of which hold a shared service credential such as a Jira bot token or a read replica password. Prices were checked on the vendors' live pages on 2026-09-25.
| Option | What it actually controls | Blocks an unapproved server at runtime? | Price (checked 2026-09-25) | Verdict |
|---|---|---|---|---|
Claude Code managed settings (allowedMcpServers + allowManagedMcpServersOnly) |
Which servers the Claude Code client may load, by URL or exact command | Yes, when the allowlist uses serverUrl/serverCommand |
No separate price; a config file | Buy (default) |
| GitHub Copilot enterprise managed settings (GA 2026-08-06) | Which servers the Copilot app, Copilot CLI and VS Code may run | Yes, and fails closed on a malformed file | No separate price listed | Buy (default) |
| Docker MCP Enterprise Gateway | Server, tool, transport and call-level policy; secrets held in your store | Yes, for traffic routed through it | Contact sales; invite-only | Buy if container-first |
| Kong Konnect MCP Registry + AI Gateway | Registry plus per-consumer tool ACLs at the gateway | Yes, for traffic routed through it | Plus from $25/serverless control plane/month; Enterprise custom | Buy if you already run Kong |
| MintMCP | Hosted MCP gateway with audit logs and SSO | Yes, for traffic routed through it | Custom per-user pricing | Shortlist only |
| Azure API Center (MCP registry) | Inventory and discovery; feeds Copilot's registry list | No, it is design-time | Free plan; Standard included with linked APIM Standard/Premium | Loser as a control |
What Can an MCP Server Actually Reach?
An MCP server reaches whatever its process or its token can reach. There is no protocol-level sandbox between the agent's intent and that authority. A local stdio server is a program running with the developer's own privileges. The MCP project's own security guidance lists what goes wrong: arbitrary code execution with MCP client privileges, data exfiltration, and irrecoverable data loss when a local server is untrusted or unsandboxed. A remote server reaches whatever its OAuth scopes or API key allow, across every tenant it serves.
Three public incidents mark out the blast radius, and each one needs a different control:
- The malicious update. An npm package called
postmark-mcpimpersonated Postmark. Postmark says the actor "built trust over 15 versions, then added a backdoor in version 1.0.16" that silently BCC'd every outgoing email. Snyk's analysis traced the copies to an attacker-controlled domain. An allowlist that approved the package name would have approved the backdoor too. - The vendor bug. Asana's own hosted MCP server had a tenant-isolation flaw that potentially exposed data to other organisations, affecting about 1,000 customers. It was a first-party server, the kind every allowlist approves.
- The toxic flow. Invariant Labs showed a malicious issue in a public repository steering an agent into reading a private repository through the GitHub MCP server and leaking it. Nothing malfunctioned. The server did what its token permitted.
The client itself is attack surface as well. mcp-remote, a widely used bridge, carried CVE-2025-6514, a CVSS 9.6 OS command injection triggered simply by connecting to an untrusted server.
So governance has three separate jobs. Decide what runs (the allowlist), decide what it can touch (credential scope), and be able to stop it fast (revocation). No single product does all three. Any vendor that claims it does is selling you the first job.
Claude Code Managed Settings: The Strongest Free Control
The managed MCP policy in Claude Code is the most precise allowlist on this list, and it costs nothing. You can deploy managed-mcp.json (at /etc/claude-code/managed-mcp.json on Linux) to pin a fixed server set with exclusive control. Or you can publish an approved catalogue with allowedMcpServers plus allowManagedMcpServersOnly: true, which makes the managed list authoritative. Without that flag, a user's own ~/.claude/settings.json can broaden it. Denylists always merge from every scope, and a deny always wins.
The detail that matters most is in Anthropic's own docs: "A serverName entry, in either list, is not a security control." A name is the label a user types, so anyone can call any server github. Real enforcement comes from serverUrl entries (wildcards allowed) for remote servers and serverCommand entries, which must match the exact command and arguments, for stdio servers. Once a single serverUrl entry exists, every remote server has to match a URL.
Pin the version inside serverCommand. An entry of ["npx", "-y", "some-mcp"] matches whatever npm resolves today, and that is exactly how postmark-mcp 1.0.16 would have walked through. ["npx", "-y", "some-mcp@1.0.15"] would not.
The caveat, dated. An open bug filed on 2026-09-23, issue #96408, reports that when remote managed settings load slowly and nothing is cached on disk, MCP servers can connect before the allowlist applies, and they are not re-checked afterwards. Until it is fixed, deploy the managed settings as a file through your device management tool for ephemeral containers and slow-proxy environments, rather than relying on the remote fetch alone. That mitigation is our inference from the bug's reproduction steps, not a vendor statement.
Who should not rely on it alone: any team where agents run somewhere other than Claude Code (CI bots, in-house agents, other IDEs). Its enforcement stops at its own process.
GitHub Copilot Enterprise Managed Settings: GA, and It Fails Closed
GitHub's enterprise allowlist, generally available since 6 August 2026, is the right control for GitHub Copilot, and it is a different feature from GitHub's registry policy. You commit allowedMcpServers and deniedMcpServers to copilot/managed-settings.json in your source organisation's .github-private repository. It uses the same three matchers as Claude Code. serverUrl canonicalises URLs "to prevent evasion", serverCommand matches exactly, and serverName is flagged as convenience only. The changelog says it is enforced on the GitHub Copilot app, Copilot CLI and VS Code.
Two design choices earn it a default slot. According to GitHub's configuration docs, invalid JSON is treated as an empty allowlist, which blocks everything except built-in servers. And a server with an unresolved ${VARIABLE} is blocked rather than guessed. That is failing closed, and it is the behaviour you want from a security control.
Who should not rely on it alone: shops with a large JetBrains, Eclipse or Xcode population. The changelog names only three enforced surfaces, so check your IDE mix against it before you call the rollout done.
Docker MCP Enterprise Gateway: The Most Complete Runtime Control, If You Can Get It
Docker's gateway covers all three jobs in one place: approval, credential custody and revocation. Docker says unvetted servers are denied by default, policy is evaluated at server, tool, transport and call level, credentials sit in your approved secret store and are "supplied at call time", every decision is logged against a user identity to your SIEM, and a revocation takes effect on the next session with no client reconfiguration. It lists Claude Code, Cursor, VS Code and ChatGPT Enterprise as supported clients. Deployment options are managed-in-your-cloud and an air-gapped appliance; the Docker-managed SaaS is "coming soon".
The server supply chain is Docker's strongest point. Its catalogue ships servers as container images versioned with provenance and SBOM metadata, with locally run servers digitally signed. That is the direct answer to the postmark-mcp pattern. The underlying docker/mcp-gateway is MIT-licensed, so the core is inspectable.
Who should not buy it: anyone who needs a quote this quarter. The docs state the MCP Gateway inside Docker AI Governance is "an invite-only feature", and pricing is contact-sales. It is also the wrong fit if your developers don't run containers locally.
Kong Konnect MCP Registry + AI Gateway: Buy It Only If Kong Is Already Your API Gateway
Kong is the sensible gateway choice for a team that already routes its APIs through Kong, and an expensive new platform for anyone else. Kong announced its MCP Registry in Konnect on 2 February 2026 as a tech preview, built as an extension of its existing API catalogue. The enforcement half lives in Kong AI Gateway: MCP Tool ACLs in version 3.13, published 14 January 2026, where "different consumers receive different subsets of available tools based on their authenticated identity". That is tool-level least privilege: the support team's agent never sees delete_issue.
Pricing is public at the entry tier. Konnect Plus charges $25/month per serverless gateway control plane, $200/month per hybrid gateway control plane and $500/month per dedicated cloud gateway control plane, with 1M API requests/month included and $200 per additional million. SSO and audit logging sit in Enterprise, which is custom-priced and billed annually. For our 300-developer workload, audit logging is not optional, so plan on the Enterprise conversation.
Who should not buy it: teams without Kong today, and anyone who needs a GA registry. The registry is still labelled tech preview.
MintMCP: A Credible Hosted Gateway, Priced Behind a Sales Call
MintMCP bundles a managed MCP gateway, an LLM proxy and audit logs with SOC 2 Type II, but it publishes no prices, only "custom pricing based on team size and needs" with per-user licensing and platform fees. SSO/SAML and SCIM are listed as add-ons for larger deployments. It suits a team that wants hosted gateway servers without running Kong or Docker infrastructure.
Who should not buy it: regulated teams that need the gateway inside their own network boundary. A hosted gateway puts a third party in the path of every tool call and every credential it brokers. Shortlist it, get the data-residency answer in writing, and compare the per-user quote against a Kong Plus bill.
Why Azure API Center, and Registry-Only Policies, Lose
A registry answers "what exists?", and buyers keep mistaking it for "what is allowed?". Azure API Center is a good inventory. It registers remote servers by URL and local servers by package, version and runtime command, and exposes a v0.1/servers endpoint that Copilot can consume. The Free plan costs nothing, but Microsoft support is not available on it, and Standard is included at no extra cost when linked to API Management Standard, Standard v2, Premium or Premium v2. Microsoft's own overview calls it "design-time API governance" and points to API Management for runtime. It blocks nothing.
The trap is pairing it with GitHub's "Registry only" policy and calling the job done. GitHub's configuration page says that feature is "in public preview and is not the recommended method for restricting access to MCP servers". Its enforcement reference says matching is by name/ID and bypassable by editing config, and that the Copilot cloud agent is not covered. The public MCP Registry itself is still a preview that verifies namespace ownership through GitHub or DNS. That proves who published a server, not what the server does.
Use a registry for discovery. Never cite it to your auditor as a control.
Review Criteria for a Third-Party MCP Server
Approve a server when you can name its owner, pin its version, bound its credential and turn it off. Reject it if any one of those fails. The checklist that predicts regret:
- Publisher identity. Is it the vendor's own server? Postmark had not published an MCP server on npm when the impersonator appeared. Check the vendor's own docs link, not the registry listing.
- Pinnable artefact. An exact npm/PyPI version or an image digest you can put in
serverCommand. No pin, no approval. - Tool surface. List every tool and flag the ones that write, delete, send or execute. Prefer servers that let you switch writes off. The GitHub MCP server, for example, skips write tools entirely under
--read-onlyand lets you enable only the toolsets you need. - Auth model. Remote servers should use per-user OAuth with narrow scopes. The MCP spec is blunt: servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server". A server that forwards your token straight to the downstream API is doing forbidden token passthrough. Ask the vendor.
- Untrusted input. Does the server read content that anyone can write (public issues, inbound email, web pages)? If yes, the Invariant pattern applies, and its credential must not reach anything private.
- A named owner inside your company who reviews its updates and answers the page when it breaks.
Credential Scoping and Rotation
Every approved server gets its own credential, scoped to the minimum toolset and rotated on a fixed schedule and on every incident. The spec's scope-minimisation guidance names the anti-patterns: wildcard scopes, bundled privileges and publishing every scope up front. For the four shared-credential servers in our workload, move the secret out of developer configs entirely. That is the concrete case for a gateway: Docker's keeps credentials in your secret store and injects them at call time, so no developer laptop holds the Jira bot token.
For per-user servers, use fine-grained tokens bound to specific repositories or projects, never a developer's broad personal token. Rotate on a calendar (90 days is a reasonable default) and immediately when any server that touched the credential is revoked. Postmark's incident advice was exactly that: remove the package, review logs, rotate credentials.
Revocation When a Server Turns Malicious
Revocation has to work in minutes, across every client, without asking 300 developers to edit a file. Here is how each option does it:
- Claude Code: add a
serverUrlorserverCommandentry todeniedMcpServersin managed settings. Denies merge from every scope and nothing overrides them. - Copilot: commit the deny to
copilot/managed-settings.json. - Gateways (Docker, Kong, MintMCP): revoke centrally. Docker says the change is picked up on the next session.
- Vendor-side: you don't control it. Asana's fix involved taking its server offline, and it came back online on 17 June 2025. Your runbook has to cover a first-party server going dark as well as one going bad.
Then the unglamorous half: rotate every credential the server held, search logs for its tool calls during the exposure window, and notify its owner. Rehearse it once with a harmless server before you need it.
How to Decide: The Criteria That Actually Predict Regret
Choose by where your agents run and where your credentials live, not by feature count.
- All agents run in Claude Code and Copilot? Managed settings alone, pinned by URL and versioned command. Spend nothing, and spend the effort on the review process.
- Shared service credentials, or agents in CI and custom code? Add a gateway for those servers only. Pick Kong if it's already your API gateway, Docker if you're container-first and can get the invite, and MintMCP if you want it hosted and can accept a third party in the path.
- Need a catalogue developers can browse? Azure API Center or the gateway's registry, labelled as discovery, never as enforcement.
What changes the answer: a client without a managed allowlist. If a big slice of your developers use one, the gateway stops being optional, because it is the only enforcement point left.
This Week: Pull every MCP config from a sample of 20 developer machines and list what is actually running. Assign an owner to each server or mark it for removal.
This Month: Ship allowedMcpServers with serverUrl/serverCommand entries (versions pinned) to Claude Code and Copilot, with allowManagedMcpServersOnly: true on the Claude Code side. Move the shared credentials behind a gateway or into per-user OAuth.
Before Q4 Close: Run a revocation drill end to end, including credential rotation, and put the time it took on paper.
The Bottom Line
This is the browser-extension problem again. A decade ago, enterprises learned that an approved-extensions page changed nothing, and that the control was the managed browser policy that refused to load anything else. MCP is repeating that lesson, faster and with real credentials attached. The registry is the page. The managed allowlist is the policy.
Name the owner, pin the version, bound the token, rehearse the kill. The catalogue can come later.
Continue Reading
- Your Agent Allowlist Says Python. It Means Any Command.
- 150 MCP Servers Never Started. No Benchmark Shows That.
- Okta vs Entra Agent ID vs SailPoint: Two Issue, One Governs
- 9,400 MCP Servers, 18% Trust: Why Snowflake Bought Natoma
- One Fake Bug Report Hijacked a $250B Company's AI Agent
- The 2026 Agentic AI Stack: 8 Layers, 3 You Can Skip
