> 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.2-mcp-servers-securing-the-protocol.md). # 2.2 MCP servers: securing the protocol Local and remote MCP servers are both attack surfaces — treat every server like a software dependency with permissions and update risk. *Last reviewed: August 18, 2026* {% hint style="info" %} MCP standardizes how AI tools reach external systems. Treat every MCP server as a software dependency, an access grant, and a prompt-injection surface. {% endhint %} ## MCP servers: what security teams need to know MCP lets AI clients connect to tools, resources, prompts, and workflows exposed by servers. That standardization is useful because teams can reuse integrations across clients. It also makes MCP a supply-chain boundary. Local MCP servers can run with the user's local privileges. Remote MCP servers shift the risk to authorization, token handling, network exposure, and server ownership. In both cases, tool metadata and tool results become part of the agent's decision context. ## Common MCP servers security failures * A developer adds a local MCP server from a repository without reviewing what it executes. * A remote MCP server receives broad OAuth scopes and has no owner. * Tool descriptions are trusted even though MCP guidance treats them as untrusted unless the server is trusted. * MCP servers are allowed by name but not by version, source, or scope. * Logs show the agent called a tool, but not what external system was reached. ## MCP servers security controls checklist * Maintain an MCP allowlist with owner, source, version, transport, scopes, and review date. * Prefer remote servers with explicit authorization and narrow tokens when local process access is not required. * Review server source, package provenance, and update behavior before approval. * Restrict tool calls by server and tool name, rather than relying on whether MCP is enabled. * Log tool name, server, input parameters, target system, and result status. ## Anthropic ### Overview For MCP protocol review, Anthropic-specific implementation depends on where the MCP server is reached from. Claude web, Claude Desktop, Claude Mobile, Cowork, Claude Code, and the Claude API do not all use the same MCP path. Remote connectors are the default for cloud services and can work across Claude surfaces. Claude Desktop extensions and local MCP run locally and are specific to Claude Desktop and Claude Code. The Claude API MCP connector reaches remote HTTP MCP servers from the Messages API and supports toolset-level enablement, allowlisting, denylisting, per-tool configuration, and OAuth bearer tokens. Treat those as separate review paths, because local STDIO access, remote OAuth access, and API-hosted tool calls have different logs and enforcement points. ### Anthropic documentation * [Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) * [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) * [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) * [Claude Code MCP](https://code.claude.com/docs/en/mcp) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Code permissions](https://code.claude.com/docs/en/permissions) ### 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-specific MCP review spans ChatGPT apps, custom MCP apps, the Apps SDK, Codex, and direct API tool use. ChatGPT exposes user-facing integrations as apps. Custom ChatGPT apps are MCP-backed, while Apps SDK apps expose tools and optional UI components through an MCP server. Codex can use MCP through plugins or direct MCP configuration shared across Codex in the ChatGPT desktop app, the CLI, and the IDE extension. The OpenAI API also exposes remote MCP servers and other tools through the `tools` parameter. Review should separate ChatGPT app governance, plugin packaging, Codex MCP governance, and API tool governance because each surface has different enablement, authentication, sandboxing, and audit paths. ### 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) * [Apps SDK MCP](https://developers.openai.com/apps-sdk/concepts/mcp-server) * [Using tools](https://developers.openai.com/api/docs/guides/tools) * [Codex MCP](https://developers.openai.com/codex/mcp) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about MCP servers ### What is an MCP server? An MCP server exposes tools, resources, and prompts to AI clients through the Model Context Protocol, the open standard used by Claude, ChatGPT, Codex, and many other AI tools. Because one server can be reused across clients, it acts as a shared integration layer, which also makes it a shared supply-chain and access boundary. Treat each server as a software dependency, an access grant, and a prompt-injection surface at the same time. ### Are local MCP servers more dangerous than remote MCP servers? They carry different risks rather than strictly more or less. A local server runs on the user's machine and can inherit local file, process, and network access, so a malicious package compromises the endpoint. A remote server shifts the risk to authorization: OAuth scopes, token handling, server ownership, and network exposure. Review local servers like installed software and remote servers like SaaS integrations. ### Can MCP tool descriptions be trusted? Only when the server itself is trusted. The MCP specification treats tool descriptions and annotations as untrusted unless they come from a trusted server, because a malicious server can embed instructions in the metadata the model reads. Pin tool definitions at review time and alert when they change. ### What should an MCP security review include? At minimum: the server's owner, source repository, version, transport (local STDIO or remote HTTP), requested scopes and secrets, logging behavior, update path, and the exact tools it exposes, including which ones write or execute code. The review should end with an allowlist entry, not just an approval email. ### What tools help with MCP server review? Static analysis, dependency and package-provenance scanning, Semgrep rules, and MCP-specific scanners can surface obvious problems such as credential harvesting or dangerous shell calls. They are a floor, not a substitute: ownership, scope, and update review still decide whether a server belongs on the allowlist. ## 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.3 MCP gateways and allowlisting](/handbook/2.-supply-chain-and-extensibility/2.3-mcp-gateways-and-allowlisting.md) * [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone.md) * [5.4 Agent-specific threats: tool poisoning and confused deputy](/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy.md) * [5.3 Supply chain attacks and notable CVEs](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves.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.2-mcp-servers-securing-the-protocol.md?ask=&goal= ``` `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.