MCP Security Best Practices: Keep Your AI Tools Safe

MCP Security Best Practices: Keep Your AI Tools Safe

MCP gives your AI powerful access to real systems — databases, code repos, cloud infrastructure, and more. That power comes with real security risks.

In 2025 and early 2026, researchers from Palo Alto Networks, Pillar Security, Red Hat, and others uncovered serious vulnerabilities in the MCP ecosystem: prompt injection attacks, tool poisoning, command injection in server code, and cross-server data leaks. A dedicated security project (modelcontextprotocol-security.io) now tracks the top 10 MCP security risks.

This guide covers what you need to know to use MCP safely — whether you're an individual developer or deploying MCP across a team.

The Real Risks

Before diving into best practices, understand what can actually go wrong:

1. Prompt Injection Through MCP Tools

An MCP server returns data to your AI client. If that data contains instructions (like "ignore previous instructions and..."), the AI might follow them. This is called indirect prompt injection.

Example: You ask your AI to summarize a GitHub issue. The issue description contains hidden instructions that tell the AI to exfiltrate your API keys through another MCP tool. Why it's dangerous: MCP servers can access multiple tools. A compromised response from one server can trigger actions through another.

2. Tool Poisoning

A malicious MCP server advertises a tool with a harmless name (like read_file) but actually does something else (like uploading your files to a remote server).

Why it's dangerous: Most users approve tool calls based on the name without reading the full description or source code.

3. Tool Redefinition Attacks

When multiple MCP servers run in the same environment, a malicious server can redefine tools from legitimate servers. It intercepts requests meant for the real tool and manipulates the data.

Why it's dangerous: You think you're using the trusted GitHub server, but a rogue server has hijacked that tool name.

4. Command Injection in Server Code

Many community MCP servers have basic security flaws. A server that passes user input directly to shell commands without sanitization is vulnerable to command injection.

Example from real code:

python
VULNERABLE - never do this
def convert_file(filepath, format):
    os.system(f"convert {filepath} output.{format}")

If filepath is "image.jpg; cat /etc/passwd > leaked.txt", the server runs arbitrary commands.

5. Excessive Permissions

MCP servers often request more access than they need. A file server with full disk access, a database server with write permissions, or a GitHub server with admin scope — these are "keys to the kingdom" scenarios.

Best Practices for Individual Developers

1. Audit Every Server Before Installing

Before adding any MCP server to your config:

• Check the source code. MCP servers are typically open source. Read the code, especially how they handle inputs and what system calls they make.
• Check the GitHub stars and activity. A server with 5 stars and no recent commits is riskier than one maintained by a major company.
• Look for security advisories. Search "[server name] vulnerability" or "[server name] CVE" before installing.
• Prefer official servers. Anthropic's reference implementations and servers maintained by the tool vendor (MongoDB's MongoDB server, GitHub's GitHub server) are safer than random community servers.

2. Use Read-Only Credentials

Always create dedicated, minimal-permission credentials for MCP:

Database access:

sql
-- PostgreSQL: Create a read-only user
CREATE USER mcpreader WITH PASSWORD 'strongpassword';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_reader;
-- Set a query timeout to prevent runaway queries
ALTER USER mcpreader SET statementtimeout = '30s';

GitHub tokens:

• Use fine-grained personal access tokens
• Grant only the specific repository access needed
• Never use tokens with admin or delete permissions for MCP

Cloud credentials:

• Create dedicated IAM roles/users for MCP with read-only policies
• Never use root or admin credentials

3. Review Every Tool Call

All major MCP clients show you what each tool will do before running it. Actually read these confirmations. Check:

• Is this the server you expect?
• Do the parameters look right?
• For database queries: Does the SQL access only expected tables?
• For file operations: Is the path within the expected directory?
• For API calls: Is the endpoint and payload what you'd expect?

4. Restrict File System Access

When configuring the Filesystem MCP server, only grant access to specific directories:

json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/me/projects/my-app"
      ]
    }
  }
}

Never use / or your home directory as the root. Only expose the folders the AI actually needs.

5. Run Servers in Docker

Docker containers provide isolation. If a server is compromised, the damage is contained:

json
{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "--network=none",
        "-e", "GITHUBPERSONALACCESSTOKEN=ghptoken",
        "ghcr.io/github/github-mcp-server"
      ]
    }
  }
}

The --network=none flag is especially useful for servers that shouldn't need internet access (like local file servers).

6. Limit the Number of Active Servers

More servers = more attack surface. Only install servers you actively use. If you haven't used a server in a month, remove it from your config.

Also, more servers means more tools for the AI to consider, which increases the risk of tool confusion (the AI picking the wrong tool).

Best Practices for Teams and Enterprise

7. Maintain an MCP Server Allowlist

Create an approved list of MCP servers for your organization. Developers should only use servers from this list.

What to include in your allowlist policy:

• Server name and version
• Source (official vs community)
• Security review date
• Approved permissions/scopes
• Approved transport type (stdio vs HTTP)

8. Use an MCP Gateway (Proxy Layer)

For enterprise deployments, route all MCP traffic through a gateway proxy. This gives you:

• Centralized logging — See every tool call across your org
• Access control — Enforce per-user and per-team permissions
• Rate limiting — Prevent abuse or runaway automation
• Content filtering — Scan tool responses for sensitive data before passing to the AI

Several companies now offer MCP gateway products. Check our directory for current options.

9. Separate Dev and Production MCP Configs

Never use the same MCP configuration for development and production:

• Dev config: Can include more servers, use dev database credentials
• Production config: Minimal servers, read-only credentials, restricted permissions

Store production MCP configs in your secrets manager, not in plain text files.

10. Implement Runtime Security Enforcement

As recommended by Palo Alto Networks, implement guaranteed runtime security enforcement:

• Input validation — Sanitize all parameters before passing to MCP servers
• Output filtering — Scan server responses for injection attempts
• Behavioral monitoring — Alert on unusual tool call patterns (e.g., a database server suddenly accessing 50 tables when it normally accesses 3)

11. Regular Security Audits

Schedule monthly reviews of your MCP setup:

1. Inventory check — Which servers are installed? Are any unnecessary?
2. Permission review — Do credentials have minimal required access?
3. Version check — Are servers up to date? Are there known vulnerabilities?
4. Token rotation — Rotate API keys and tokens used by MCP servers
5. Log review — Check for unusual tool call patterns

The MCP Security Top 10

The modelcontextprotocol-security.io project maintains a list of the top 10 MCP security risks, similar to OWASP. The key categories:

1. Server-side risks: API security, infrastructure hardening, input validation
2. Client-side risks: Tool approval bypasses, prompt injection, data leakage
3. Protocol-level risks: Transport security, authentication, authorization

Review this list regularly — it's updated as new attack vectors are discovered.

Security Checklist

Before deploying any MCP server, run through this checklist:

• [ ] Source code reviewed (or server is from a trusted vendor)
• [ ] Credentials are read-only and scoped to minimum required access
• [ ] File system access is restricted to specific directories
• [ ] API tokens use fine-grained permissions (not admin/root)
• [ ] Server is running in Docker or sandboxed environment
• [ ] Tool approval is enabled (not auto-approved)
• [ ] No sensitive data (passwords, PII) is accessible through exposed tables/files
• [ ] Token/credential rotation is scheduled
• [ ] Team has an approved MCP server allowlist (for enterprise)
• [ ] Monitoring/logging is in place for tool calls

Staying Current

MCP security is evolving rapidly. The protocol itself is adding new security features, and the ecosystem is maturing. Resources to follow:

• Official MCP security spec: modelcontextprotocol.io/specification/draft/basic/securitybestpractices
• MCP Security Top 10: modelcontextprotocol-security.io/top10
• Vendor advisories: Follow security blogs from Palo Alto Networks, Red Hat, Pillar Security for MCP-specific research

We track MCP support and security features across 500+ tools in our directory. Browse MCP-compatible tools and check each tool's security documentation before deploying.

What's Next

• Get started with MCP: Beginner's tutorial
• Choose your MCP client: Client comparison
• Find safe, well-maintained servers: Best MCP servers in 2026

Security isn't a one-time setup — it's an ongoing practice. The power of MCP is worth the effort to use it safely.