MCP (Model Context Protocol) Security Cheat Sheet¶

Introduction¶

The Model Context Protocol (MCP), introduced by Anthropic in November 2024, standardizes how AI applications (LLM clients) connect to external tools, data sources, and services. Think of it as a universal interface layer, a "USB-C port for AI", replacing fragmented, custom integrations with a single protocol.

However, MCP introduces a fundamentally new attack surface: AI agents dynamically executing tools based on natural language, with access to sensitive systems. Unlike traditional APIs where developers control every call, MCP lets LLMs decide which tools to invoke, when, and with what parameters. This is creating unique security risks that combine prompt injection, supply chain attacks, and confused deputy problems.

This cheat sheet provides best practices to secure MCP deployments and minimize attack surfaces across clients, servers, and the connections between them.

Architecture Overview¶

User ↔ MCP Host (AI App) ↔ MCP Client ↔ MCP Server(s) ↔ Tools / Data / APIs

MCP Host: The AI application (e.g., Claude Desktop, Cursor, IDE plugins).
MCP Client: Connects to one or more MCP servers, passes tool definitions to the LLM.
MCP Server: Lightweight program exposing tools, resources, and prompts via the protocol.
Transports: stdio (local) or Streamable HTTP (remote). The older HTTP+SSE transport is deprecated. See the Streamable HTTP specification.

The LLM sees all tool descriptions from all connected servers in its context — this is critical to understanding cross-server attacks.

Key Risks¶

Tool Poisoning: Malicious instructions hidden in tool descriptions, parameter schemas, or return values that manipulate the LLM's behavior.
Rug Pull Attacks: A server changes its tool definitions after initial user approval, turning a trusted tool malicious.
Tool Shadowing / Cross-Origin Escalation: A malicious server's tool description manipulates how the agent behaves with tools from other trusted servers.
Confused Deputy Problem: The MCP server executes actions with its own (often broad) privileges, not the requesting user's permissions.
Data Exfiltration via Legitimate Channels: Attackers use prompt injection to encode sensitive data into seemingly normal tool calls (e.g., search queries, email subjects).
Excessive Permissions / Over-Scoped Tokens: MCP servers request broad OAuth scopes (full Gmail access vs. read-only), creating aggregation risk.
Supply Chain Attacks: Untrusted or compromised MCP server packages installed from public registries without review.
Message Tampering and Replay: JSON-RPC payloads modified after TLS termination by compromised proxies or middleware, or captured and re-sent to duplicate actions.
Sandbox Escapes: Local MCP servers running with full host access, enabling file system traversal, credential theft, or arbitrary code execution.

Best Practices¶

1. Principle of Least Privilege¶

Grant each MCP server the minimum permissions needed for its function.
Use scoped, per-server credentials — never share tokens across servers.
Request narrow OAuth scopes (e.g., mail.readonly instead of mail.modify or mail.full_access).
Prefer ephemeral, short-lived tokens over long-lived PATs.

2. Tool Description & Schema Integrity¶

Inspect all tool descriptions, parameter names, types, and return schemas before approval.
Treat the entire tool schema as a potential injection surface — not just the description field.
Pin reviewed tool definitions using cryptographic hashes and require review when they change. This detects metadata changes, not changes to server code or behavior behind an unchanged definition; tool annotations are hints, not enforcement.
Use tools like mcp-scan to automatically detect poisoned descriptions and cross-server shadowing.
Use strict JSON Schema for tool parameters: set additionalProperties: false and use pattern (or similar) on string fields so only declared parameters and valid formats are accepted.

3. Sandbox and Isolate MCP Servers¶

Run local MCP servers in a sandbox that enforces minimal privileges and access to host resources, following the MCP local-server guidance. A bare chroot is not a process sandbox.
Restrict file system access to only required directories.
Disable network access unless explicitly needed.
Use stdio for local MCP communication through the launched process's standard streams. This avoids a listening MCP endpoint; it does not restrict the server process's file system, network, or credential access.
Separate sensitive servers (payment, auth, PII) from general-purpose ones.

4. Human-in-the-Loop for Sensitive Actions¶

Require explicit user confirmation for destructive, financial, or data-sharing operations.
Display full tool call parameters to the user — not just a summary name.
Never auto-approve tool calls, especially in multi-server setups.
Ensure the confirmation UI cannot be bypassed by LLM-crafted responses.
Do not assume that an available MCP tool has the user's consent or approval for a particular invocation. The MCP specification states that hosts must obtain explicit user consent before invoking any tool and that a human should be able to deny tool invocations.
Assess whether tool operations require additional authorization based on their possible effects, including sensitive reads, writes, data disclosure, and irreversible actions; a tool's read/write label alone may not establish the risk, and clients must treat tool annotations as untrusted unless they come from trusted servers.
Choose controls according to that risk, such as explicit user confirmation, narrowly scoped authorization, or policy checks enforced at execution time. For binding approvals to specific actions and arguments and preventing their reuse, follow the AI Agent Security Cheat Sheet.

5. Input and Output Validation¶

Validate all inputs to MCP server tools — treat them as untrusted (they originate from LLM output influenced by potentially malicious context).
Sanitize inputs against injection attacks (SQL, OS command, path traversal).
Validate and sanitize tool outputs before returning them to the LLM context — output is often used as input by other tools and can cause downstream SSRF or command injection if unsanitized.
Never pass raw shell commands or unsanitized file paths.
Protect against SSRF: MCP tools that fetch URLs based on LLM-generated parameters can be manipulated via prompt injection to access internal services (e.g., cloud metadata endpoints). Never fetch arbitrary URLs provided by the LLM without strict allowlist validation.

6. Authentication, Authorization & Transport Security¶

Require authentication when remote endpoints expose non-public tools or data. Authorization is optional in the protocol; see the MCP authorization specification.
When using OAuth over HTTP, follow the MCP OAuth 2.1 profile. Clients must identify the intended MCP server with the resource parameter. See resource indicators.
Validate that each access token was issued for this MCP server as its intended audience. Reject invalid tokens and never pass an MCP access token to an upstream API. See token handling.
Validate authorization on every protected request. The current Streamable HTTP transport has no protocol-level sessions. If supporting older session-based revisions, use random session IDs, bind them to the authenticated user, and never treat an ID as authentication; see the legacy session guidance.
Use TLS for remote Streamable HTTP connections.
Verify server identity via certificate pinning or cryptographic server verification for remote servers.
Apply resource controls (rate limits, quotas, timeouts) per session or tenant to resist DoS and limit impact of abuse; combine with sandboxing to contain local escape impact.
Use OS-native secure credential storage (macOS Keychain, Windows Credential Manager, Linux Secret Service) for OAuth access and refresh tokens.
Never store OAuth tokens in plaintext in MCP config files or application settings.
Bind local Streamable HTTP servers to localhost unless network access is explicitly needed. See the transport security rules.
Validate the Origin header on incoming Streamable HTTP requests. Reject a present but invalid Origin with HTTP 403. Do not reject non-browser clients solely because they send no Origin header. See the transport security rules.
Validate the Host header on incoming requests; reject unexpected hostnames.

7. Optional Message-Level Integrity¶

TLS protects messages in transit, but a component that changes data after TLS termination is a separate threat. The core MCP transport specification does not require every JSON-RPC message to be signed. The MCPS Internet-Draft proposes a separate signing and replay-protection layer; it is an individual work in progress, not an adopted MCP standard.

If the threat model calls for integrity after TLS termination, choose a reviewed mechanism supported by both endpoints. Define how keys are trusted, what is signed, how replay is rejected, and what happens when verification fails. Do not present optional signing as a requirement for ordinary MCP deployments.

8. Multi-Server Isolation & Cross-Origin Protection¶

Treat each MCP server as an untrusted, independent security domain.
Prevent tool descriptions from one server from referencing or modifying the behavior of tools from another server.
Monitor for cross-server data flows (e.g., credentials from server A appearing in calls to server B).
Use an MCP proxy or gateway to enforce isolation policies between servers.

9. Supply Chain Security¶

Only install MCP servers from trusted, verified sources.
Review server source code and tool definitions before installation.
Verify package integrity with checksums or code signing.
Scan MCP server dependencies for known vulnerabilities.
Monitor for changes to tool descriptions post-installation (rug pull detection).
Carefully verify package names before installation — typosquatting (e.g., mcp-server-filesystem vs mcp-server-filesytem) is a common attack vector.
Use tools like mcp-scan to automatically analyze and monitor installed servers for malicious behavior or changes.

10. Monitoring, Logging & Auditing¶

Log all MCP tool invocations with full parameters, user context, and timestamps.
Feed MCP logs into SIEM for anomaly detection.
Alert on unusual patterns: new tools being called, admin-level queries, abnormal call frequency.
Redact secrets and PII from logs.
Conduct regular security audits and simulated attacks against MCP setups.
When the logs come from a component you did not build, see the Verifying Third-Party Agent Execution Evidence Cheat Sheet for how to judge what such a record establishes.

Display a clear consent dialog before connecting any new MCP server.
Show the exact command that will be executed (for local servers), without truncation.
Clearly identify the source and publisher of the MCP server.
Re-prompt for consent when tool definitions change.
Never allow web content or untrusted data to trigger MCP server installation.

12. Prompt Injection via Tool Return Values¶

Treat every tool response as untrusted data, including responses from approved servers.
Separate and clearly label tool data in the model context, and instruct the model to treat it as data rather than instructions.
Use tag stripping and instruction-pattern detection only as additional filtering or alerting measures. They cannot establish that the remaining text is safe; OWASP describes encoded and multilingual prompt injections that evade filters.
Enforce authorization and validate subsequent tool calls in trusted application code, independently of the model's interpretation. Apply least privilege and human approval for sensitive actions.
For web-scraping and retrieval tools, extract the required structured data instead of passing raw HTML. Text inside structured fields remains untrusted.

Do's and Don'ts¶

Do:

Enforce least privilege per MCP server and per tool.
Inspect and pin all tool descriptions and schemas.
Sandbox local MCP servers in containers or restricted environments.
Require human approval for sensitive or destructive tool calls.
Apply risk-appropriate authorization to sensitive tool calls and enforce its scope at execution time.
Validate all inputs and outputs at the MCP server layer.
Use mcp-scan or equivalent tooling to detect poisoned tools.
Log and monitor all tool invocations centrally.
Verify MCP server sources and scan dependencies.
Validate the Origin of Streamable HTTP requests and the audience of OAuth access tokens.
Pin tool definitions with cryptographic hashes and verify before each execution.

Don't:

Auto-approve tool calls without showing full parameters to the user.
Trust tool descriptions blindly — they are a prompt injection vector.
Share OAuth tokens or credentials across MCP servers.
Run MCP servers with full host access or * permissions.
Install MCP servers from unverified public registries without review.
Assume a tool approved yesterday is the same tool today (rug pulls).
Ignore cross-server interactions — shadowing attacks are real.
Store secrets in source code, plaintext config files, or logs.
Treat optional message signing as a core MCP requirement.
Accept server public keys from unverified first-contact responses (TOFU without pinning).