Claude Code MCP and Cursor MCP Security

Last updated: November 4, 2026

What is Claude Code MCP security? Claude Code MCP security is the set of controls that decide which Model Context Protocol servers Claude Code can load, what they can do and who approves them. The same questions apply to Cursor MCP. Both tools can run local commands and call remote servers with your credentials. A bad configuration can turn a coding agent into a remote code execution path.

TL;DR: Key Takeaways

• Claude Code stores MCP servers in 3 scopes: local and user in ~/.claude.json, project in a shared .mcp.json (Claude Code docs).
• In 3 session types (claude -p, Agent SDK and cloud sessions outside a project's threads), project servers from .mcp.json load without an approval prompt (Claude Code docs).
• Claude Code Action before 1.0.74 enabled every project MCP server from a pull request branch, so 1 malicious .mcp.json could run code on the runner (NVD, 2026).
• Cursor before 1.3.9 let an indirect prompt injection create .cursor/mcp.json and run code without approval, tracked as CVE-2025-54135 (NVD).
• Claude Code before 1.0.111 could run project code before the user accepted the startup trust dialog, tracked as CVE-2025-59536 (NVD).
• The OWASP 2026 LLM Top 10 ranks Prompt Injection 1st, Excessive Agency 3rd and Supply Chain 4th (Cloud Security Alliance, 2026).

At a glance: Claude Code MCP vs Cursor MCP security controls

Quick Answer

How do you secure Claude Code MCP and Cursor MCP?

Secure Claude Code MCP and Cursor MCP by approving every server, keeping secrets in environment variables and enforcing an organization allowlist. In Claude Code, use managed-mcp.json or allowedMcpServers. In Cursor, use the Enterprise MCP Allowlist. Keep both tools updated, because past bugs allowed code execution.

How we compared

On November 4, 2026 we reread the Claude Code MCP and managed MCP documentation, Cursor's MCP documentation and the NVD entries for four CVEs. We compared configuration files, approval behavior and administrator controls.

How Claude Code MCP configuration and scopes work

Claude Code MCP servers are configured at three scopes that control where a server loads and who shares it. Local scope is private to one project, user scope applies to all your projects and project scope is shared through a .mcp.json file in version control.

The Claude Code documentation (2026) states that local scope is the default. Local and user servers live in ~/.claude.json. Project servers live in .mcp.json at the repository root, so anyone who can commit to the repo can add one.

That is why approval matters. In interactive sessions, Claude Code asks you to approve project servers before using them. You can reset those choices with claude mcp reset-project-choices. In non-interactive runs, the picture changes.

According to Claude Code documentation (2026), project servers load without asking in claude -p runs, Agent SDK sessions and cloud sessions outside a project's threads. The prompt is also skipped in a bypassPermissions session started with skipDangerousModePermissionPrompt set. CI jobs and background agents therefore trust whatever .mcp.json the branch contains. The docs list three ways to keep a server out:

• Add it to disabledMcpjsonServers, which blocks it in every permission mode.
• Exclude project settings with --setting-sources or the SDK's settingSources option.
• Start with --strict-mcp-config, so only servers passed with --mcp-config load.

A cloned repository cannot approve its own servers. The docs say enableAllProjectMcpServers committed to a project's .claude/settings.json is ignored in an untrusted folder, and the server stays pending. Approvals in your user or managed settings still apply.

For OAuth, Claude Code fails a sign-in whose response names an unexpected issuer. It also sends credentials only to HTTPS or localhost token endpoints.

How Cursor MCP configuration works

Cursor MCP servers are configured in .cursor/mcp.json for a project or ~/.cursor/mcp.json for every workspace. Each entry runs a local stdio command or points at a remote server URL. Cursor asks for approval before using MCP tools by default, and teams can manage servers from the dashboard.

According to Cursor's documentation (2026), MCP follows the same Run Modes as terminal commands. In Auto-review mode, allowlisted MCP tools run immediately and the rest go through a classifier.

For secrets, Cursor supports ${env:NAME} interpolation in mcp.json, so keys do not have to sit in the file. Its security advice is short and sound:

• Verify the source and install only from trusted developers.
• Review what data and APIs the server will access.
• Use restricted API keys with minimal permissions.
• Audit the code of critical integrations.

The docs add a reminder that MCP servers "can access external services and execute code on your behalf." That sentence applies to Claude Code just as much. Our Claude Code vs Cursor benchmark compares the tools beyond MCP.

What real vulnerabilities taught: CurXecute, MCPoison and Claude Code Action

Four public CVEs show how MCP configuration becomes an attack path in coding agents. Two hit Cursor, one hit Claude Code and one hit its GitHub Action. Each abused trust: a writable file, a config that changed after approval, code that ran before consent, or a pull request that brought its own servers. All four are fixed.

According to NVD (2025), the CurXecute bug existed because creating a new dotfile did not require approval, while editing one did. An attacker could chain an indirect prompt injection to write the MCP settings file. The agent then launched the attacker's command.

MCPoison targeted approval itself. NVD (2025) reported that once a collaborator accepted a harmless MCP entry, an attacker with write access could swap it for a malicious command. No warning or new prompt appeared. Approval must be tied to the exact configuration, not the server name.

The Claude Code bug required a user to start the tool in an untrusted directory. Users on standard auto-update received the fix automatically. Our analysis of Claude Code RCE risks covers that class of issue.

The newest case moved the problem into CI. According to NVD (2026), the Claude Code GitHub Action checked out the pull request head branch, read .mcp.json from it and enabled every project MCP server. Version 1.0.74 restores .claude/ and .mcp.json from the base branch before the CLI runs.

Four lessons follow:

1. Treat MCP config files as code. Review .mcp.json and .cursor/mcp.json changes in pull requests like any executable.
2. Expect injected writes. Any agent that can write files can try to write its own config.
3. Never let a pull request choose its own servers. In CI, read agent config from the base branch.
4. Patch quickly. Each fix arrived in a routine release, so auto-update closes the window.

How to harden a developer MCP setup

Hardening a developer MCP setup means reducing which servers load, what they can reach and what secrets they hold. Start with an inventory, approve servers by exact configuration, keep secrets out of files and limit network access for local servers. Then add review rules for config changes.

A hardening checklist that works for both tools:

According to the MCP project's Local Server Security guide (2026), a local server is an ordinary process with your files, environment variables and open network access. Run an untrusted stdio server in a container with no network, for example docker run -i --rm --network=none <image>. A server that cannot reach the internet cannot exfiltrate what it reads.

Also check tool descriptions before approval. A malicious server can hide instructions in them, a risk known as tool poisoning. The same guide notes that every configured server shares one model context, so a single bad server can influence how the agent uses the others. Favor a client that re-prompts when a definition changes. Our MCP security 101 guide covers the wider threat model.

How to enforce MCP policy across a team

Enforcing MCP policy means moving decisions from each developer's laptop to an administrator-managed policy. Claude Code offers managed-mcp.json and managed allowlists. Cursor offers an Enterprise MCP Allowlist in its dashboard. Both let you block unapproved servers before they ever run.

Claude Code. The managed MCP documentation (2026) describes several restriction levels. The most common are:

• Disable MCP: deploy managed-mcp.json with an empty server map.
• Fixed deployment: deploy managed-mcp.json with the servers you want; users cannot add others.
• Provided servers: list remote servers in managedMcpServers; users keep their own.
• Approved catalog: use allowedMcpServers with allowManagedMcpServersOnly: true.
• Soft allowlist: use allowedMcpServers alone, which users can broaden.
• Denylist only: use deniedMcpServers to block known-bad servers.

The file lives at /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux and WSL, and C:\Program Files\ClaudeCode\ on Windows. With exclusive control active, claude mcp add fails with an error naming the enterprise configuration.

Cursor. Enterprise admins configure the MCP Allowlist under Team Settings. Command entries approve local servers by pattern. URL entries approve remote servers. Tool allowlists restrict which tools run automatically.

Security and governance: developer MCP in the enterprise

Developer MCP is a governance problem because coding agents hold source code, credentials and shell access at once. Governance means knowing which servers run on which machines, approving them centrally and logging what they do. It also means treating unmanaged MCP use as shadow AI.

Key controls for an enterprise rollout:

• Inventory: track MCP configs across managed devices and repositories.
• Central approval: publish an approved catalog and block everything else.
• Least privilege: give each server scoped tokens, never a developer's personal admin key. See our RBAC for AI agents guide.
• Runtime inspection: scan tool calls and outputs for prompt injection and sensitive data.
• Audit trail: log every tool call with the user, server and arguments.

According to the OWASP Top 10 for LLM Applications 2026, as summarized by the Cloud Security Alliance (2026), Prompt Injection ranks first, Excessive Agency third and Supply Chain fourth. A coding agent that loads third-party MCP servers touches all three. Our guide to the OWASP Top 10 for Agentic Applications 2026 maps the agent side.

NeuralTrust adds the runtime layer with the Agent Gateway (TrustGate). Its MCP gateway lets teams decide which tools each agent can call and tracks which model accessed which tool. Remote MCP traffic from Claude Code and Cursor can route through one policy point. NeuralTrust reports under 100 ms added latency at p95 with PromptGuard and Data Masking enabled, and its split-plane architecture supports data residency requirements.

Which should you choose?

Both Claude Code and Cursor can run MCP safely, so choose by workflow and by the admin controls you need. Claude Code gives file-based managed policy that suits device management. Cursor gives a dashboard allowlist with per-server network modes. Many teams use both, so one central policy matters more than the editor.

Conclusion

Claude Code MCP and Cursor MCP make coding agents far more useful, and far more exposed. Config files act as executable code, and approval prompts cannot appear in headless runs. Four CVEs, the newest from July 2026, show how a poisoned config or pull request becomes code execution. Keep both tools updated, never let a pull request choose its own servers, approve servers centrally and keep secrets out of config. Then route remote MCP traffic through one policy point with logging.

Secure Claude Code and Cursor MCP in Production with NeuralTrust

Start free with 100,000 requests per month and route your coding agents' MCP traffic through one governed gateway.

Related Comparisons

• Best MCP gateways
• Claude Code RCE explained
• MCP security 101
• OWASP Top 10 for LLM Applications 2026

FAQs about Claude Code MCP

1. Where does Claude Code store MCP server configuration?

Claude Code stores local and user scoped servers in ~/.claude.json and project scoped servers in .mcp.json at the repository root. Local is the default scope. Administrators can deploy managed-mcp.json in a system folder for exclusive control. Project files are shared through version control, so review them like code.

2. Does Claude Code ask before running project MCP servers?

In interactive sessions, yes. Claude Code prompts you to approve project servers from .mcp.json before using them. In claude -p runs, Agent SDK sessions and cloud sessions outside a project's threads it cannot show that prompt, so the servers load without asking. A repository cannot approve itself in an untrusted folder. Use --strict-mcp-config or disabledMcpjsonServers to control them.

3. Is Cursor MCP safe to use?

Cursor MCP is reasonably safe when you keep Cursor updated, approve tools and install servers only from trusted sources. Older versions had CVE-2025-54135 and CVE-2025-54136, both of which allowed code execution through MCP configuration. Enterprise admins can add an MCP Allowlist.

4. How do I keep API keys out of MCP config files?

Use environment variable references instead of literal keys. Claude Code supports ${VAR} expansion in its MCP configuration, and Cursor supports ${env:NAME} interpolation in mcp.json. Give each server a restricted key with only the permissions it needs, and rotate keys if a config file was ever committed with secrets.

5. Can I block all MCP servers in Claude Code for my company?

Yes. Deploy a managed-mcp.json file with an empty server map to the system path for each operating system. Claude Code then loads no MCP servers except the few that load under exclusive control. To allow an approved catalog instead, use allowedMcpServers with allowManagedMcpServersOnly set to true.

6. What was the CurXecute vulnerability?

CurXecute is the name given to CVE-2025-54135 in Cursor below version 1.3.9. Creating a new dotfile did not require approval, so an indirect prompt injection could write .cursor/mcp.json and trigger remote code execution. Cursor fixed it in 1.3.9. Keep the editor updated and review MCP config changes.

7. Is it safe to run Claude Code on pull requests in CI?

It is safe only if the workflow does not trust the pull request's own configuration. CVE-2026-47751 let a malicious .mcp.json in a pull request run code on the GitHub Actions runner in Claude Code Action before 1.0.74. Update to 1.0.74 or later, read MCP config from the base branch and pass only approved servers with --strict-mcp-config.

About the Author

Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, and SEM. Connect on LinkedIn.

NeuralTrust is the leading platform for securing and scaling AI agents. Named a Pioneer in the Gartner Emerging Market Quadrant for AI Application Security 2026, recognized across four Gartner Hype Cycle reports in 2026, and featured in the Gartner Market Guide for Guardian Agents 2026, the Gartner Market Guide for AI Gateways 2025 and the KuppingerCole Leadership Compass for Generative AI Defense 2025. Headquartered in Barcelona with offices in London and New York. ISO 27001 certified.

Sources

1. Anthropic, "Connect Claude Code to tools via MCP", Claude Code documentation, accessed November 4, 2026.
2. Anthropic, "Control MCP server access for your organization", Claude Code documentation, accessed November 4, 2026.
3. Cursor, "Model Context Protocol (MCP)", Cursor documentation, accessed November 4, 2026.
4. NIST National Vulnerability Database, "CVE-2025-54135", published August 5, 2025.
5. NIST National Vulnerability Database, "CVE-2025-54136", published August 2, 2025.
6. NIST National Vulnerability Database, "CVE-2025-59536", published October 3, 2025.
7. NIST National Vulnerability Database, "CVE-2026-47751", published July 16, 2026.
8. Model Context Protocol, "Local Server Security", accessed November 4, 2026.
9. OWASP Gen AI Security Project, "OWASP Top 10 for LLM Applications 2026", published August 3, 2026.
10. Cloud Security Alliance, "The OWASP Top 10 for LLM Applications 2026: What Changed and Why It Matters", October 21, 2026.