> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/2.-supply-chain-and-extensibility/2.3-mcp-gateways-and-allowlisting.md).

# 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*

{% hint style="info" %}
An MCP gateway gives security teams one place to decide which servers exist, which tools are exposed, and which users or agents can reach them.
{% endhint %}

## 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

* [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans)
* [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities)
* [When to use desktop and web connectors](https://support.claude.com/en/articles/11725091-when-to-use-desktop-and-web-connectors)
* [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop)
* [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector)
* [Claude Code settings](https://code.claude.com/docs/en/settings)
* [Claude Code permissions](https://code.claude.com/docs/en/permissions)
* [Claude Code security](https://code.claude.com/docs/en/security)
* [Claude Code MCP](https://code.claude.com/docs/en/mcp)
* [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage)
* [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data)

### Applicable Harmonic guides for Anthropic

* [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide)

## 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

* [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt)
* [Admin Controls, Security, and Compliance in apps](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-apps-enterprise-edu-and-business)
* [Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt)
* [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features)
* [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256)
* [Codex MCP](https://developers.openai.com/codex/mcp)
* [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing)
* [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration)
* [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security)
* [Codex governance](https://developers.openai.com/codex/enterprise/governance)
* [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data)
* [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices)
* [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation)

### Applicable Harmonic guides for OpenAI

* [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice)

## 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

| Governance page                                     | Relationship to this article                                                                                      |
| --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| 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

* [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility.md)
* [2.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol.md)
* [1.2 RBAC across AI platforms](/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms.md)
* [6.5 Routing AI telemetry to your SIEM](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem.md)
* [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/handbook/2.-supply-chain-and-extensibility/2.3-mcp-gateways-and-allowlisting.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
