2.3 MCP gateways and allowlisting
How to centralize which MCP servers exist and who can reach them so users cannot freely add unreviewed tools.
Last reviewed: August 18, 2026
MCP gateways and allowlisting: what security teams need to know
MCP adoption often starts locally. A developer adds one server for GitHub, another for tickets, and a third for an internal database. That works for experimentation, but it does not scale as a control model.
A gateway or centrally managed allowlist moves MCP governance from individual configuration files into an owned service or policy layer. The goal is to make unmanaged MCP the exception, not the path of least resistance.
Common MCP gateways and allowlisting security failures
Users can add any MCP server while security believes there is an allowlist.
The allowlist names a server but does not restrict the tools inside it.
Policy exists for laptops but not CI or remote agent runs.
A gateway brokers access but does not log tool inputs and outcomes.
Server updates change tool behavior without a new review.
MCP gateways and allowlisting security controls checklist
Use managed settings or gateway policy to restrict MCP servers to an approved list.
Control tools inside each server, especially tools that write, execute code, or reach sensitive data.
Record server owner, version, scopes, authentication method, and review cadence.
Apply policy consistently to desktop, CLI, IDE, cloud, and CI agent runs.
Export MCP tool-call events to the audit pipeline.
Anthropic
Overview
Anthropic allowlisting is enforced in a different place on each surface, so decide where policy lives before buying or building a gateway. For Claude web, Desktop, mobile, and Cowork, Team and Enterprise owners control which connectors are enabled, and Enterprise connector permissions can require approval for, block, or always allow specific connectors. Desktop extensions have their own controls: owners can enable or disable public extensions, upload custom extensions, and apply enterprise policy that overrides in-app allowlist and blocklist settings.
For Claude Code, managed settings are the enforcement point. They can restrict MCP servers, plugins, hooks, and permission rules, and deny rules take precedence over ask and allow rules. For API-built agents, the MCP connector supports toolset-level enablement, tool allowlists and denylists, and per-tool configuration. A gateway complements these native controls by adding brokered access and centralized logging; it does not replace the review record behind each approval.
Claude Tag channel sessions have another native gateway: every outbound HTTP or HTTPS request crosses Agent Proxy. The proxy injects a stored credential only when a request matches its rule, permits credential-free requests only to allowed hosts, and blocks unmatched destinations. Review the connection's allowed websites, the Access bundle's Domains list, and the session environment's network setting together. A fresh environment can inherit Anthropic's Trusted host set, so default-deny at the proxy does not mean that only organization-added domains are reachable.
Anthropic documentation
Applicable Harmonic guides for Anthropic
OpenAI
Overview
OpenAI allowlisting also splits by surface. In ChatGPT, workspace app controls decide which apps are available, action controls decide whether an app can read only, take actions, or use a custom set of actions, and custom roles gate app access by group. Custom MCP apps require workspace controls and review before their actions are exposed to users.
For Codex, managed configuration is the allowlist mechanism: admin-enforced requirements can constrain approval policies, sandbox behavior, and MCP-related settings. Codex in the ChatGPT desktop app, the CLI, and the IDE extension share MCP settings, so one policy decision covers all three. The API Platform is a separate control plane with its own keys, service accounts, workload identity, and data controls. Wherever a gateway sits, route its allow, deny, and approval decisions into the same audit pipeline as Codex governance exports.
OpenAI documentation
Applicable Harmonic guides for OpenAI
Frequently asked questions about MCP gateways and allowlisting
What is an MCP gateway?
An MCP gateway is a broker that sits between AI clients and MCP servers, centralizing which servers exist, which tools inside them are exposed, and which users or agents can reach them. It turns per-laptop configuration files into an owned policy layer with one audit trail. Native controls such as Claude Code managed settings, the Claude API MCP connector's toolsets, and Codex managed configuration cover much of this without a gateway, so pick the enforcement point deliberately.
Is an allowlist enough to govern MCP?
A list of server names is not. The allowlist needs source, version, owner, transport, authentication method, scopes, and the specific exposed tools, because a server update can change tool behavior while the name stays the same. Pair the list with tool-call logging so you can prove what was actually reached.
Should users be able to add their own MCP servers?
Only in designated sandbox or research groups with no production data access. For production groups, restrict server addition through managed settings in Claude Code, managed configuration in Codex, or a gateway, and route new-server requests through the supply-chain intake instead.
What should be logged for MCP tool calls?
Log the server, tool name, user or agent identity, input classification, target system, result status, and whether the call was allowed, denied, or escalated for approval. Denied and escalated calls are the most valuable signal, because they show where policy and real usage disagree.
How often should MCP allowlists be reviewed?
Review high-risk servers quarterly, after every server update, and whenever scopes or tool behavior change. Treat a tool-description change as a review trigger in its own right, since MCP guidance treats tool metadata as untrusted unless the server is trusted.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports ICT asset, dependency, and third-party risk management.
G.5 SANS Critical AI Security Guidelines mapping
This article implements relevant SANS Deployment Strategies, Inference Security, and GRC guidance.
G.6 Write an AI Acceptable Use Policy that holds up
This article supplies a technical or process control used to enforce the acceptable-use policy.
G.7 Ownership and RACI for AI security
This control depends on the ownership and evidence responsibilities defined in the RACI.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Was this helpful?