Claude MCP in the Enterprise: Approve and Secure 2026

TL;DR

Claude MCP connects Claude to your tools through local stdio or remote HTTP servers. In the enterprise, treat every MCP server as code with access to data. Approve servers centrally, enforce them with managed-mcp.json or allowedMcpServers plus allowManagedMcpServersOnly, match by URL or command rather than name, require OAuth with narrow scopes, and log tool calls.

What is Claude MCP, and how do local and remote servers differ?

The Model Context Protocol (MCP) is an open protocol that lets Claude call tools and read data from other systems. A local server runs as a subprocess on the user’s machine and talks over stdio. A remote server runs elsewhere and is reached over Streamable HTTP. Both give Claude real capabilities, which is why both need approval.

Anthropic introduced MCP on 25 November 2024 as a standard for connecting AI assistants to the systems where data lives. On 9 December 2025 it donated MCP to the Agentic AI Foundation under the Linux Foundation. At that point Anthropic counted more than 10,000 active public MCP servers, 97M+ monthly SDK downloads across Python and TypeScript, and over 75 connectors in Claude’s directory. Ten thousand public servers means your developers will find one for almost anything. That is the governance problem.

The current transport specification (revision 2026-07-28) defines two standard transports:

	Local server (stdio)	Remote server (Streamable HTTP)
Where it runs	Subprocess on the user’s laptop	Your host, a vendor’s cloud, or behind a tunnel
Who can reach it	Only the client that launched it	Anyone who can reach the URL, so it needs auth
Credentials	From the environment, per the spec	OAuth 2.1 based authorization
Main risk	Arbitrary code execution with user rights	Over-broad tokens, data leaving to a third party
Allowlist key in Claude Code	serverCommand	serverUrl

The MCP specification states that tools represent arbitrary code execution and that tool descriptions should be considered untrusted unless they come from a trusted server. Read that sentence twice before you approve a community server.

Inside Claude there are two places MCP shows up. Claude Code reads servers from config files. The Claude apps (claude.ai, Desktop, Cowork) use connectors, which are remote MCP servers added by URL. On Team and Enterprise plans, only an Owner adds a custom connector for the organization, and each member then connects with their own account.

How does Claude Code configure MCP servers?

Claude Code knows three scopes. Local scope is the default and stays private to one project on one machine. Project scope writes .mcp.json into the repository so the team shares it. User scope applies to all projects of one user. Organizations add a fourth layer above these through managed configuration.

The Claude Code MCP reference lists where each scope lives:

Scope	Loads in	Shared with team	Stored in
Local (default)	Current project only	No	~/.claude.json
Project	Current project only	Yes, via version control	.mcp.json in project root
User	All your projects	No	~/.claude.json

Adding servers from the CLI:

claude mcp add --transport http tickets --scope project https://mcp.internal.example.com/mcp
claude mcp add --transport stdio pgread --scope project -- npx -y @example/postgres-mcp@1.4.2
claude mcp list

The resulting .mcp.json is the file you review in a pull request. Keep secrets out of it with ${VAR} expansion:

{
  "mcpServers": {
    "tickets": {
      "type": "http",
      "url": "https://mcp.internal.example.com/mcp",
      "headers": { "Authorization": "Bearer ${TICKETS_MCP_TOKEN}" }
    },
    "pgread": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/postgres-mcp@1.4.2"],
      "env": { "DATABASE_URL": "${PGREAD_URL}" }
    }
  }
}

Three behaviours matter for security reviews:

1. In interactive sessions Claude Code asks for approval before it uses project scope servers from .mcp.json. In claude -p runs, Agent SDK sessions and cloud sessions it cannot show that prompt and loads them without asking. A CI job that checks out an untrusted branch therefore runs whatever .mcp.json that branch contains.
2. In a remote server’s url and headers, credential variables such as ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN and AWS_BEARER_TOKEN_BEDROCK read as empty. A malicious .mcp.json cannot ship your Bedrock token to its own server.
3. Claude Code warns when MCP tool output exceeds 10,000 tokens and caps it at 25,000 tokens by default (MAX_MCP_OUTPUT_TOKENS raises the cap). Large tool output costs tokens and is also the channel through which injected text reaches the model.

One EU detail: connectors from claude.ai only load in Claude Code when the user is signed in with a claude.ai subscription. With Bedrock or Google Cloud active, they are not fetched. If you run Claude Code on Bedrock in an EU region as described in our Claude Code Bedrock setup, every MCP server comes from your own config files.

How do you enforce MCP policy across the company?

Use managed configuration, not a wiki page. Claude Code offers a fixed server set through managed-mcp.json, servers provided to everyone through managedMcpServers, and filtering through allowedMcpServers and deniedMcpServers. For a hard allowlist, set allowManagedMcpServersOnly: true, otherwise users can broaden it in their own settings.

The managed MCP page describes these patterns. The ones we see in practice:

Pattern	What it does	Configure
Disable MCP	Nothing loads except built-ins	managed-mcp.json with "mcpServers": {}
Fixed deployment	Everyone gets the same servers, nothing else	managed-mcp.json with your servers
Approved catalog	Users add servers from an approved list	allowedMcpServers plus allowManagedMcpServersOnly: true
Denylist only	Block known bad servers	deniedMcpServers

managed-mcp.json sits at /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux and WSL, and C:\Program Files\ClaudeCode\ on Windows. Any user on the machine can read it, so never put API keys in its env blocks. A managed settings file for the approved catalog pattern:

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.internal.example.com/*" },
    { "serverCommand": ["npx", "-y", "@example/postgres-mcp@1.4.2"] }
  ],
  "deniedMcpServers": [
    { "serverUrl": "https://*.untrusted.example.com/*" }
  ]
}

The rules behind it:

• A denylist match blocks the server, and nothing overrides it.
• serverCommand matches exactly, every argument in order. Pinning the package version in the command means the allowlist approves a version, not a name.
• A serverName entry is not a security control. Anyone can call any server github. Anthropic’s docs say so explicitly.
• managedMcpServers (remote servers only, https:// only, no commands) requires Claude Code v2.1.259 or later.

The trap for EU deployments: setting CLAUDE_CODE_USE_BEDROCK or another third-party provider bypasses server-managed settings from the claude.ai console. On Bedrock, ship the allowlist as managed-settings.json or an MDM profile, or through a self-hosted Claude apps gateway. For Cowork on a third-party provider, Claude Desktop supplies and locks MCP servers itself; our Cowork enterprise guide covers that setup.

For monitoring, set OTEL_LOG_TOOL_DETAILS=1 with OpenTelemetry export. Tool events then carry MCP server and tool names, so you can see which servers people actually use.

Which MCP security risks matter, and how do you mitigate them?

Four risks dominate: prompt injection through tool output, poisoned or silently changed tool descriptions, over-broad or passed-through tokens, and local servers that run arbitrary code. Each has a concrete control in the MCP spec or in Claude’s admin settings. None is solved by trusting a directory label.

Risk	What happens	Control
Prompt injection	A server that fetches external content returns text with instructions	Approve only servers you trust, keep per-call approval for write tools, block unneeded tools
Tool poisoning	A tool description hides instructions or changes after approval	Treat descriptions as untrusted, pin versions, re-review on change
Token passthrough	A server forwards a token not issued for it	Spec: servers MUST NOT accept such tokens
Over-broad scopes	One leaked token opens files, database and admin	Minimal scopes, step-up on privileged calls
Local server compromise	A startup command exfiltrates keys	Sandbox, exact command allowlist, no npx without a version

Anthropic’s connector review checklist rejects tool descriptions with hidden, obfuscated or encoded instructions, or ones that tell Claude to call tools the user didn’t request. Use the same list for your internal review. The connector verification page is blunt: a Verified label isn’t a security audit, and the developer can change tools after review.

The MCP security best practices add two rules for servers you build. MCP servers must not accept tokens that were not explicitly issued for them. And scopes should start minimal, with elevation only when a privileged tool is first called, instead of wildcard scopes like files:* or admin:*. The authorization spec requires Resource Indicators (RFC 8707) so a token is bound to one server.

Inside Claude Code, permission rules give a second line: mcp__github__get_* allows only the get_ tools of one server, and "mcp__*" in a deny rule removes every MCP tool. In the Claude apps, an admin can set individual connector tools to Blocked.

GDPR angle: a remote MCP server operated by a vendor receives whatever the tool call sends, often personal data. That makes the vendor a processor or a separate controller, and it belongs in your record of processing like any other SaaS. Custom connectors in claude.ai are called from Anthropic’s infrastructure, so the server must be reachable from there. For servers that must stay inside your network, Enterprise plans can request MCP tunnels, a research preview with up to 10 active tunnels per organization and Cloudflare as a subprocessor.

What does a workable MCP approval process look like?

Run MCP servers through the same gate as any software with data access: a request, a security and data protection review, a pinned and allowlisted configuration, and a re-review when the server changes. The approval is only real if the allowlist enforces it on every machine.

1. Request: the team names the server, transport, URL or exact command, the tools it needs and the data it touches.
2. Review: security reads the tool descriptions and source (for stdio), data protection classifies the data flow and checks the vendor contract.
3. Configure: pin the version, choose OAuth with the narrowest scopes, mark write tools as ask.
4. Enforce: add the serverUrl or serverCommand entry to managed settings and roll it out.
5. Monitor and re-review: track tool usage through OpenTelemetry, re-review on every version bump or tool change.

Gate	Owner	Evidence you keep
Request	Requesting team	Server, tools, data categories, business reason
Security review	Security	Tool descriptions read, source or vendor reviewed, auth model
Data protection	DPO	Processor status, DPA, transfer basis, record of processing
Enforcement	Platform team	Commit to managed settings, pinned version
Re-review	Platform team plus security	Changelog check on each update

Servers that only read public documentation can take a fast lane. Servers with write access to production data, HR or customer records always go through the full gate.

Run it yourself or outsource?

Running MCP in-house is a platform job, not a one-time setup. Someone has to keep the server inventory, patch pinned versions, rotate secrets and read the logs. For a handful of read-only servers, an internal team handles that easily. For dozens of servers with write access, the recurring work is where outsourcing can pay off.

The recurring tasks, in our view:

Task	What it involves	Cadence (our estimate)
Server inventory	One list of approved servers, owners, versions, data categories	Updated on each approval
Patching	Bump pinned versions, re-review changed tools, update the allowlist	Weekly check, ad hoc for advisories
Secret rotation	OAuth clients, static headers, tunnel token and TLS keys	Per your policy, immediately after exposure
Logging	OpenTelemetry pipeline, alerts on unknown servers or new tools	Continuous
Policy rollout	MDM or managed settings, user communication when servers are blocked	Per change

Our rough estimate for a mid-size engineering organization: a fraction of one platform engineer plus a few security review hours per new server. That is an estimate, not a benchmark.

Outsourcing makes sense when you lack a platform team that already runs MDM and secrets management, or when you want someone else to host remote MCP servers with an SLA. It makes little sense if you only use two or three vendor connectors; then the vendor is already the operator.

What to demand from a provider for MCP specifically:

• SLA for hosted MCP servers, including how fast they patch after a security advisory.
• A GDPR data processing agreement (DPA) that names MCP tool calls as processing, plus the subprocessor list, including any tunnel or hosting provider.
• An access model where tokens are issued per server, with minimal scopes and no token passthrough, and your IdP stays the source of identity.
• Logs you can export to your own SIEM.
• Exit: server definitions, allowlists and the inventory live in your repository, not only in the provider’s console.

If you also run a gateway for model traffic, the same ownership questions apply; our LiteLLM EU gateway guide covers that side.

FAQ

What does Claude MCP cost?

The protocol itself is open and has no licence fee. Costs come from operating the servers, from vendor subscriptions for hosted connectors, and from tokens: tool output counts as input to the model. Claude Code caps MCP output at 25,000 tokens per tool call by default and warns above 10,000.

managed-mcp.json or allowedMcpServers: which should I use?

Use managed-mcp.json when everyone should get exactly the same servers and nothing else; it takes exclusive control. Use allowedMcpServers with allowManagedMcpServersOnly: true when teams pick from an approved catalog. Both are enforced; the first is stricter.

Are connectors in the Anthropic directory security-audited?

No. Anthropic reviews connectors against its listing criteria, but it does not security-audit or manage any MCP server. A Verified label means closer review for quality and compatibility, not a guarantee. The developer can change tools after review.

Do claude.ai connectors work in Claude Code on Bedrock?

No. Claude Code fetches claude.ai connectors only when the active login is a claude.ai subscription. With Bedrock, Google Cloud or an API key active, they are not loaded. You configure servers through .mcp.json, user scope or managed files instead.

Can I block a server by its name?

You can, but it is not a security control. The name is a label the user chooses, so a user can rename any server. Block or allow by serverUrl for remote servers and by exact serverCommand for stdio servers.

Does OAuth make a remote MCP server safe?

It makes access attributable and revocable, which static keys do not. It does not stop prompt injection or a malicious tool. Combine OAuth with minimal scopes, tokens bound to one server, a reviewed tool list and per-call approval for write actions.

Sources

1. Claude Code docs: Connect Claude Code to tools via MCP (1 October 2026)
2. Claude Code docs: Control MCP server access for your organization (1 October 2026)
3. Claude Code docs: Security (1 October 2026)
4. Claude Code docs: Server-managed settings (1 October 2026)
5. Claude Code docs: Permissions (1 October 2026)
6. Claude docs: Add a connector that isn't in the directory (1 October 2026)
7. Claude docs: Connector verification (1 October 2026)
8. Claude docs: MCP tunnels (1 October 2026)
9. Claude docs: Connector pre-submission checklist (1 October 2026)
10. MCP specification 2026-07-28 (1 October 2026)
11. MCP specification: Transports (1 October 2026)
12. MCP specification: Authorization (1 October 2026)
13. MCP: Security best practices (1 October 2026)
14. Anthropic: Introducing the Model Context Protocol (1 October 2026)
15. Anthropic: Donating MCP to the Agentic AI Foundation (1 October 2026)