MCP Security Guide

Bottom line: MCP gives AI agents powerful tools, but that power needs guardrails. This guide covers how to secure MCP servers and clients against the most common risks.

Why MCP security matters

An MCP server can read files, query databases, call APIs, and execute code. If an attacker controls a server, tricks a client into calling it, or injects malicious data through a tool, the impact can be severe. Security is not built into the protocol; it is your responsibility.

1. Secure the transport

MCP supports stdio for local processes and SSE for remote connections. For stdio, the server runs on the same machine as the client, so filesystem and process isolation are critical. For SSE, always use TLS, validate certificates, and pin allowed origins. Avoid exposing MCP servers to the public internet without authentication.

2. Authenticate and authorize

Servers should verify the client and clients should verify the server. Use OAuth, API keys, or mutual TLS where possible. Map each authenticated identity to the smallest set of tools and resources it needs. A read-only user should not be able to invoke write tools.

3. Sandboxing

Run MCP servers with minimal privileges. Containers, virtual machines, and restricted user accounts limit the damage from a compromised server. Never run an MCP server as root. If a server only needs access to one directory, mount only that directory.

4. Tool permissions and allow-lists

Clients should expose only the tools a user actually needs. Support tool allow-lists and block-lists. Require explicit user approval for destructive or high-risk actions such as deletes, writes, purchases, or sending messages. Make the approval UI clear about what will happen.

5. Input validation

Validate every argument a model passes to a tool. Use schemas, type checks, and range limits. Reject unexpected fields. If a tool expects a file path, resolve it and ensure it stays within an allowed directory. Never pass raw tool output into shell commands or SQL without parameterization.

6. Defend against prompt injection

Prompt injection happens when untrusted text inside retrieved data or user input alters the model's behavior. Defenses include:

• Separating instructions from data with clear delimiters.
• Marking tool results as untrusted context.
• Using a smaller model or classifier to flag suspicious inputs.
• Requiring human confirmation for sensitive tool calls.
• Keeping system prompts private and not exposing them to servers.

7. Audit and monitor

Log every tool call, including arguments, results, and the identity that triggered it. Send logs to a centralized system and alert on anomalies such as high failure rates, unusual argument patterns, or access outside normal hours. Regularly review which servers are installed and what permissions they have.

Security checklist

• Use TLS for SSE and validate certificates.
• Run servers in sandboxed environments with least privilege.
• Authenticate clients and servers.
• Enforce tool allow-lists and require approval for risky actions.
• Validate and sanitize all tool inputs and outputs.
• Separate instructions from untrusted data in prompts.
• Log and monitor all tool calls.
• Keep server software and dependencies up to date.

Related resources

• AI Safety Center - test prompts and explore guardrails
• Guardrails Guide - patterns for safe AI outputs
• MCP Server Directory - discover curated servers

Published 2026-06-12