MCP servers extend Claude Code’s capabilities by connecting it to databases, APIs, and external services. But each MCP server is a potential attack surface. If an attacker compromises your MCP server, they gain access to every tool that server exposes. In this guide, we cover the security best practices that keep your MCP integrations safe.
Understanding the MCP Security Model
MCP runs over stdio or SSE transport. The server exposes a set of tools that Claude can call. When Claude calls an MCP tool, the server executes the underlying action and returns the result. This means the MCP server has whatever permissions the credential or configuration grants it.
The Trust Boundary Problem
The critical security concept with MCP is the trust boundary. Once an MCP server is connected, Claude can invoke any tool it exposes without user confirmation per call. If your MCP server can run arbitrary shell commands or access your database, a compromised or malicious prompt could trigger destructive actions.
Security Best Practices
1. Use Least-Privilege Credentials
Every MCP server needs credentials to access external services. Use credentials with the minimum permissions required. If your MCP server only reads data from a database, use a read-only database user. If it only needs to read files from a specific directory, configure filesystem access to that directory only.
The principle is simple: if the MCP server is compromised, the damage is limited to what its credentials can do. A read-only database user cannot drop tables. A scope-limited API token cannot modify records.
2. Validate and Sanitize Tool Inputs
MCP servers receive inputs from Claude and pass them to underlying tools. Validate every input before executing the action. Check for SQL injection patterns in database queries, path traversal in filesystem operations, and command injection in shell execution.
This is not paranoia. Language models can generate inputs that look valid but contain malicious payloads. Your MCP server must be the security checkpoint that catches these before they reach your systems.
Pro Hint
Treat your MCP server like a public API endpoint. Every input from Claude should be validated, sanitized, and checked against an allowlist of expected values. Do not assume that because Claude generated the input, it is safe to execute. For advanced MCP architecture patterns, see our guide on Claude Code plugins and hooks.
3. Limit the Tools Your MCP Server Exposes
Every tool an MCP server exposes is an attack surface. Only expose the tools that Claude actually needs for its task. A database MCP server might have dozens of available operations, but if Claude only needs SELECT queries, expose only read operations.
4. Audit MCP Server Activity
Log every tool invocation your MCP server handles. Include the timestamp, the tool name, the input parameters, and the result. These logs are invaluable for forensic analysis if something goes wrong. They also help you detect unusual patterns that might indicate misuse.
Securing Common MCP Server Types
Database MCP Servers
Database access is one of the highest-risk MCP integrations. An attacker who can run arbitrary SQL queries can exfiltrate data, modify records, or drop tables. Use read-only credentials where possible. Implement query parameterization to prevent injection. Add row-level security policies in the database itself as a second layer of defense.
Filesystem MCP Servers
Filesystem access lets Claude read and write files on your system. Restrict file access to specific directories using chroot or containerization. Never give an MCP server access to your entire filesystem. A configuration mistake or prompt injection could expose SSH keys, environment files, and source code.
Shell Execution MCP Servers
Shell execution is the most dangerous MCP capability. An MCP server that runs shell commands can do anything the host system user can do. If you must use shell MCP servers, run them in a sandboxed container with no network access and minimal system permissions.
| MCP Server Type | Risk Level | Mitigation Strategy |
|---|---|---|
| Shell execution | Critical | Sandboxed containers, no network, minimal permissions |
| Database access | High | Read-only credentials, parameterized queries, RLS policies |
| Filesystem access | High | Directory restrictions, chroot, no sensitive paths |
| API integrations | Medium | Scoped tokens, input validation, rate limiting |
| Read-only data sources | Low | Standard API key management |
MCP Server Deployment Security
How you deploy your MCP server matters as much as how you write it. A secure MCP server deployed insecurely is still a risk.
Run MCP Servers Locally
Prefer running MCP servers on the same machine as Claude Code. This eliminates network exposure. If you must run a remote MCP server, use mutual TLS authentication and restrict access to specific IP addresses.
Configure Environment Variables Securely
MCP servers often need API keys, database credentials, and other secrets. Store these in environment variables, never in code or configuration files that get committed to version control. Use a secrets manager for production deployments.
Frequently Asked Questions
The biggest risk is that Claude can call any exposed tool without per-call confirmation. If an MCP server exposes destructive tools like database writes or shell execution, a compromised prompt could trigger serious damage. Always follow least-privilege principles.
Yes, always. Language models can generate inputs that contain SQL injection patterns, path traversal sequences, or command injection payloads. Your MCP server must validate and sanitize every input before passing it to underlying tools.
No. Shell execution is the highest-risk MCP capability. A shell-accessible MCP server can do anything your user account can do, including deleting files, installing malware, and exfiltrating data. Use sandboxed containers if shell access is absolutely necessary.
Configure filesystem MCP servers to allow access only to specific directories. Use chroot jails, Docker volume mounts, or OS-level permission restrictions. Never allow access to directories containing SSH keys, environment files, or credentials.
Yes. Log every tool invocation including timestamp, tool name, input parameters, and result. These logs help with forensic analysis if something goes wrong and help detect unusual patterns that indicate misuse.
Store API keys, database credentials, and other secrets in environment variables. Never hardcode them in source files. Use a secrets manager like Vault or AWS Secrets Manager for production deployments, and never commit .env files to version control.