MCP Gateway and MCP Server Governance Guide

Model Context Protocol (MCP) servers give AI agents direct reach into code, mail, chat, tickets, databases and cloud accounts, yet in most organisations anyone can add one with a single line of configuration and nobody keeps a list. Governance means deciding which MCP servers may run, where they come from, which identity and credentials they use, and what they did, and an MCP gateway is the usual place to enforce those decisions at scale. This guide covers the approval process, private registries and allowlists, gateway architecture, authentication through the gateway, client-side policy controls, monitoring and a phased rollout. It is written for security architects, platform teams and identity teams. Protocol-level threats such as tool poisoning are covered in depth in the MCP Security Guide; this guide focuses on the operating model around them.

Key takeaways

An MCP server is third-party code with your credentials. Local servers run with the user's privileges and environment; remote servers receive tokens to your systems. Approve them like any software supplier with privileged access.
Enforce on the client and at the gateway. Client policy (allowlists by URL or exact command) controls what can start on endpoints; a gateway controls what remote traffic can reach and with which identity.
Allowlist by what runs, not by what it is called. A server name is a user-chosen label; match on URL, exact command and package version.
The gateway must not become a token passthrough. The MCP specification forbids servers from accepting or forwarding tokens that were not issued for them; a gateway should authenticate callers and obtain its own audience-bound tokens downstream.
Log tool calls, not just connections. Which server, which tool, which arguments, for which user and agent, is the evidence you need when a server or its output turns hostile.

What needs governing

Server type	Where it runs	Main risks	Primary control point
Local stdio server from a public package (npm, PyPI, container image)	User's workstation or CI runner, started by the MCP client	Malicious or compromised package, arbitrary code with user privileges, inherited credentials	Client policy allowlisting exact commands and versions; sandboxing
Repository-defined server (project config such as `.mcp.json`)	Workstation, started when a project is opened	Attacker-controlled configuration in a cloned repo or pull request	Client approval prompts, managed denial of project servers
Vendor-hosted remote server (SaaS vendor's own MCP endpoint)	Vendor infrastructure	Over-broad OAuth scopes, data leaving to the vendor, vendor compromise	Gateway routing, OAuth scope review, supplier assessment
Third-party hosted server (marketplace or hosting platform)	Hosting provider's infrastructure	Host compromise exposing every key passed to the server	Prefer vendor-hosted or self-hosted; never send long-lived keys
Internal server built by your teams	Your infrastructure	Weak authentication, excessive tool scope, missing audit	Secure development standard, gateway registration, identity per server
Shadow server	Anywhere	Not in inventory; unknown data flows and credentials	Discovery from endpoints, proxies and egress logs

The hosting row is not theoretical. In the Smithery.ai MCP Hosting Breach 2025, researchers used a path traversal in the build configuration to reach a single deployment token that controlled more than 3,000 hosted apps, mostly MCP servers, and captured a client's API key from traffic. Any key a customer had given a hosted server had in effect been shared with the host. See the Unsanctioned AI Agents and MCP Servers Guide for discovery of the shadow row.

An approval process for MCP servers

Treat each server as a supplier integration with privileged access. A lightweight but consistent review beats an exhaustive one that teams route around.

Request: requester names the server, the source (package and version, or remote URL), the business use, the agents and users that need it, and the systems and data it will touch.
Provenance: confirm the publisher. The official MCP Registry ties server names to verified GitHub accounts or domains in reverse DNS form (for example io.github.username/server), but it stores metadata only and delegates security scanning of code to package registries and downstream aggregators. Registry presence proves who published, not that the code is safe.
Code and dependency review: for local servers, pin a version, review the start command and dependencies, and generate an SBOM. See the AI Supply Chain and AI-BOM Guide.
Tool review: list every tool the server exposes and classify each as read, write or destructive. Disable tools not needed for the use case where the client or gateway allows tool filtering. OWASP LLM06 Excessive Agency recommends minimising both the extensions and the functionality within them.
Identity and credential review: which credential does the server use, is it per user or shared, what scopes does it request, and can those be narrowed? Reject servers that require a static, broadly scoped key when an OAuth option exists.
Data review: where does data go, is the server vendor-hosted, third-party hosted or self-hosted, and is that acceptable for the data classification?
Decision and record: approve with conditions (scopes, users, tools), reject, or approve for sandbox only. Record the owner and a review date, typically 6 or 12 months, and re-review on any major version change.

Risk tier	Typical server	Approval	Conditions
Low	Read-only documentation or public data search	Platform team, fast track	Pinned version or approved URL
Medium	Read access to internal tickets, wiki or code	Platform and security	Per-user OAuth, read scopes only, gateway routing
High	Write to code, chat, email or CRM; database queries	Security and data owner	Per-user OAuth, write tools filtered, approval for sensitive tools, full call logging
Critical	Cloud administration, production databases, payments, identity systems	Security leadership and system owner	Self-hosted or vendor-hosted only, gateway mandatory, human approval for destructive tools, short-lived credentials

Private registries and allowlists

The approval decision has to become machine-enforceable policy. Two building blocks do that.

Private registry or catalogue: the official MCP Registry does not accept private servers and recommends hosting your own private registry for them. It publishes an OpenAPI specification that other registries can implement, so a private registry can serve both internal and approved public servers to host applications that support it.
Client allowlists and denylists: major MCP clients now expose managed policy. VS Code documents enterprise policies including ChatMCP (controls access to installed MCP servers), ChatAllowedMcpServers, ChatDeniedMcpServers (deny rules take precedence), ChatAllowManagedMcpServersOnly, McpGalleryServiceUrl (points the client at a gallery service) and McpEnterpriseManagedAuthIdp. Claude Code documents a system-wide managed-mcp.json for exclusive control (for example /etc/claude-code/managed-mcp.json on Linux), plus allowedMcpServers, deniedMcpServers and allowManagedMcpServersOnly in managed settings.
Match on URL and exact command: Claude Code's documentation warns that a serverName entry is not a security control because users choose the name, and recommends serverUrl entries for remote servers and serverCommand entries, matched argument by argument, for stdio servers. Pin package versions in the command (for example a specific @scope/[email protected]) so an approved name cannot silently pull a new release.
Lock the allowlist to managed scope: without the managed-only switch, user-level allowlists merge with yours and can broaden it. Denylists merge from every scope, so users can always block more but never less.
Repository-defined servers: decide whether project configuration files may start servers at all. In the Amazon Q MCP Config Vulnerability 2026, servers defined in a repository's .amazonq/mcp.json started without a consent prompt and inherited the developer's AWS session. Note too that non-interactive and SDK runs of some clients load project servers without prompting, so a consent dialog is not a control for CI.

Deliver client policy through your device management tooling (Intune, Group Policy, Jamf or configuration profiles) so it is not user-editable, and tell users which servers are blocked: some clients simply drop a blocked server from the list without saying why.

MCP gateway architecture

An MCP gateway is a proxy that MCP clients connect to instead of connecting to each server directly. It aggregates approved servers behind one endpoint and applies policy to every request. Products differ, but the functions to look for are consistent.

Gateway function	What it does	Design note
Inbound authentication	Authenticates the user and agent calling the gateway (OAuth 2.1, mTLS, workload identity)	Fail closed; no default or shared keys
Server registry and routing	Exposes only approved servers, per user group or agent	Sourced from the private registry; unknown servers unreachable
Tool filtering	Hides or blocks individual tools, for example delete or admin tools	Filter by tool name and by argument patterns where supported
Outbound credential brokering	Obtains a separate, audience-bound token or credential for each downstream server	Never forward the caller's token; keep downstream secrets out of clients
Isolation for local-style servers	Runs stdio servers in containers with restricted file system, network and resources	Docker's MCP Gateway, for example, runs servers as containers with restricted privileges and network access
Egress control	Restricts where servers can connect, including blocking private ranges and cloud metadata endpoints	The MCP specification recommends egress proxies against SSRF
Content inspection	Scans tool output for secrets and suspicious instructions before it reaches the model	Detection aid, not a guarantee against prompt injection
Rate limits and approvals	Throttles tool calls and routes high-risk tools to human approval	Bind approvals to the exact call and arguments
Audit logging	Records every session, tool call, arguments, result size and identity	Redact secrets in arguments; export to the SIEM

Gateway versus client policy: client policy is essential for stdio servers that run on the endpoint; a gateway cannot see a local server the client started directly. A gateway is essential for remote servers, central credential handling and consistent logging. Most organisations need both.
Gateway versus AI gateway: an AI or LLM gateway brokers calls to model providers; an MCP gateway brokers calls to tools. Some products do both, which concentrates very high-value credentials in one place. See the AI Gateway and LLM Gateway Guide.
The gateway is a crown jewel: in the LiteLLM MCP Auth Bypass 2026, CVE-2026-59822 (listed in the CISA Known Exploited Vulnerabilities catalogue) let any bearer token open a full MCP session on affected versions, and attackers chained it to steal provider keys. Keep gateways off the public internet, patch them as priority assets, and replace example or default keys.
Small organisations: client allowlists plus vendor-hosted servers with per-user OAuth may be enough at first. Add a gateway when you have internal servers, shared credentials to broker or a logging requirement the clients cannot meet.

Identity and authentication through the gateway

The MCP authorization specification applies to HTTP-based transports; stdio servers are expected to take credentials from their environment. For HTTP, the specification sets requirements a gateway should honour on both sides.

Discovery: MCP servers must publish OAuth 2.0 Protected Resource Metadata (RFC 9728) and return 401 with a WWW-Authenticate header pointing to it; clients must use Authorization Server Metadata (RFC 8414).
Audience binding: clients must send the RFC 8707 resource parameter naming the server's canonical URI in both authorization and token requests, and servers must validate that tokens were issued for them. Tokens go in the Authorization: Bearer header on every request and never in the query string.
No passthrough: the specification states that MCP servers must not accept or transit any other tokens. A gateway that forwards the user's token to every downstream server breaks audit, bypasses downstream controls and lets one compromised server reuse the token elsewhere.
Confused deputy: a gateway or proxy that uses a static OAuth client ID with a third-party API while letting MCP clients register dynamically must obtain consent per client before forwarding, validate redirect URIs by exact match, and use single-use state values. These are MUST requirements in the MCP security best practices.
Sessions: servers must not use MCP session IDs for authentication and should bind session data to the authenticated user, for example keyed as <user_id>:<session_id>.
Scopes: avoid publishing every scope in scopes_supported and avoid omnibus scopes; start with minimal scopes and step up with targeted WWW-Authenticate challenges when a privileged tool is first used.
Per-user versus shared credentials: per-user OAuth keeps the downstream system's own access controls in force. Shared service credentials in the gateway are sometimes unavoidable for systems without OAuth, but scope them to the server's approved tools, vault them and log the end user on every call. See the Credential Vaulting for AI Agents Guide and the AI Agent Authorisation Guide.

Monitoring MCP activity

Collect from three places: client telemetry (which servers and tools users invoke; Claude Code, for example, can include MCP server and tool names in OpenTelemetry events when OTEL_LOG_TOOL_DETAILS=1 is set), gateway logs (every routed call with identity) and egress or proxy logs (connections to MCP endpoints that bypass the gateway).

Unapproved servers: connections to MCP endpoints or launches of server packages not in the registry, which is the main shadow MCP signal.
Tool list changes: an approved server that starts exposing new tools or changed descriptions (a notifications/tools/list_changed event or a diff against the approved list), which can indicate a compromised update (ATLAS AML.T0099 AI Agent Tool Data Poisoning).
Suspicious tool chains: a read from an external-content tool (issue tracker, email, error monitor) followed by shell, package install or outbound network calls. This was the shape of the Sentry MCP Agentjacking 2026 research, where fake error events read through an MCP server led agents to run a package.
Credential misuse: downstream tokens issued to the gateway being presented from elsewhere (ATT&CK T1550.001 Application Access Token), and server processes calling cloud metadata endpoints (T1552.005).
Volume and data anomalies: unusual call rates per agent, large result sizes or bulk exports through a single tool (T1567 Exfiltration Over Web Service).

Metric	What it shows	Target direction
MCP servers in use that are in the approved registry	Coverage of governance	Above 95%, rising
Remote MCP traffic routed through the gateway	Enforcement coverage	Close to 100% for managed devices
Approved servers using per-user OAuth or brokered short-lived credentials	Credential hygiene	Rising; static shared keys trending to zero
Median days from request to decision	Whether the process is usable	Days, not weeks, for low and medium tiers
Approved servers past their review date	Drift in the catalogue	Zero
High-risk tool calls without a recorded approval	Policy bypass	Zero

Rollout plan

Discover (weeks 1 to 4): collect MCP configuration from managed endpoints, CI runners and agent platforms; review proxy logs for MCP endpoints; interview teams building agents. Build the first inventory.
Triage: classify discovered servers by risk tier. Revoke and reissue any static credential found in shared or committed MCP configuration.
Publish the catalogue: approve the servers already in legitimate use with conditions, stand up the private registry and publish the request process.
Audit-mode client policy: deploy allowlists to a pilot group that already uses MCP. Where a client has no audit mode, use a denylist of known-bad servers first and measure what an allowlist would block from inventory data.
Introduce the gateway for remote servers: route one high-value integration through the gateway with per-user OAuth and full logging, then migrate the rest by tier.
Enforce: switch to managed-only allowlists across the fleet, block repository-defined servers or require approval, and restrict CI and SDK agents to explicit server configuration.
Rollback: keep the previous policy version in device management so a broken allowlist can be reverted fleet-wide in one change, and keep an emergency exception route for business-critical servers with a 30-day expiry.
Operate: review tool list changes on every server update, run the review calendar, and feed incidents back into the approval criteria.

Common failure patterns

Allowlisting by name: a policy that allows anything called github lets a user point that name at any server.
Unpinned packages: approving npx -y some-server without a version approves whatever is published next, including a malicious update. The postmark-mcp Malicious MCP Server 2025 showed how one changed line in a package made agents copy every email to an attacker.
Gateway as token passthrough: forwarding the user's token downstream instead of obtaining audience-bound tokens, which the specification forbids.
Trusting repository configuration: letting project files start servers without review, as in the Amazon Q case.
Static keys sent to hosted servers: pasting long-lived API keys into third-party hosted servers, which shares them with the host, as Smithery showed.
Logging connections but not tool calls: knowing a server was used but not which tool ran with which arguments for which user leaves investigations blind.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	CM-7 Least Functionality; CM-8 System Component Inventory	Allowlists, tool filtering, MCP inventory
NIST SP 800-53 Rev. 5	SR-3 Supply Chain Controls and Processes; SA-9 External System Services	Approval of third-party and hosted servers
NIST SP 800-53 Rev. 5	AC-4 Information Flow Enforcement; SC-7 Boundary Protection; IA-9; AU-12	Gateway routing, egress control, server authentication, logging
NIST CSF 2.0	ID.AM-02, GV.SC-07, PR.AA-05, DE.CM-09	Software inventory, supplier risk, least privilege, monitoring
OWASP Top 10 for LLM Applications 2025	LLM03 Supply Chain; LLM06 Excessive Agency	Server provenance; tool and permission minimisation
MITRE ATT&CK v20	T1195.002 Compromise Software Supply Chain; T1550.001; T1567	Malicious server packages, token reuse, exfiltration
MITRE ATLAS	AML.T0010 AI Supply Chain Compromise; AML.T0051 LLM Prompt Injection; AML.T0053 AI Agent Tool Invocation; AML.T0098 AI Agent Tool Credential Harvesting	Detection use cases for MCP abuse

Practitioner checklist

An inventory of MCP servers across endpoints, CI and agent platforms exists and is refreshed from telemetry.
Every approved server has an owner, risk tier, pinned version or URL, approved tools and a review date.
Client allowlists match on URL and exact command, are delivered by device management and are locked to managed scope.
Repository-defined servers are blocked or require approval, and CI and SDK agents use explicit server configuration.
Remote MCP traffic goes through a gateway that authenticates callers and fails closed.
The gateway obtains its own audience-bound downstream tokens and never passes caller tokens through.
Destructive and admin tools are filtered or require approval bound to the exact call.
Tool calls are logged with user, agent, server, tool and redacted arguments, and exported to the SIEM.
Gateways are not internet-exposed, have no default keys and are patched as priority assets.
No long-lived keys are given to third-party hosted servers.

MCP Gateway and MCP Server Governance Guide: Approving, Brokering and Monitoring MCP