MCP Security Best Practices for Running Servers Safely

MCP security best practices start with one rule: treat every MCP server as untrusted code that can inject instructions into your agent. The five practices that matter most are using least-privilege tokens, vetting servers before you install them, sandboxing execution, requiring human approval for destructive actions, and auditing every tool call. These directly address the biggest real-world MCP risks: tool poisoning, prompt injection through tool results, over-broad permissions, credential exposure, and untrusted supply-chain servers.

The Real MCP Security Risks

The most dangerous MCP risk is tool poisoning, an indirect prompt injection that OWASP defines as an attack "targeting AI agents that connect to external tool servers via the Model Context Protocol." The root cause is a trust gap: tool descriptions are vetted once at connection time, but tool responses "go straight into the LLM context with no equivalent check," per the OWASP MCP Tool Poisoning entry. A malicious server returns data with hidden instructions, the model treats it as trusted, and the agent takes actions it should not.

The five risks worth threat-modeling before you run any server in production:

• Tool poisoning: a server's tool description or response embeds instructions that hijack the agent.
• Prompt injection via tool results: even a trusted server can relay attacker-controlled content, for example a poisoned web page or email, straight into context.
• Over-broad permissions: a token or server scoped to more than it needs turns one compromised tool into full account access.
• Credential exposure: API keys and secrets passed to a server, or logged by it, can leak. Never paste live keys into prompts or configs shared in chat.
• Untrusted supply chain: installing a server from a public registry runs its code with your local permissions, so a typosquatted or backdoored package is arbitrary code execution.

The NSA flags this last risk directly, warning that MCP implementations "can allow malicious actor-controlled inputs to reach execution environments," creating high-severity Arbitrary Code Execution vulnerabilities. For the broader agent picture, see our AI agent security risks guide.

MCP Security Best Practices

The best practices below map one-to-one to the risks above and are drawn from OWASP, the NSA, and the MCP specification. Apply them in order; the first three block the majority of real attacks.

1. Use least-privilege tokens

Scope every credential to the minimum resources a server actually needs, and never reuse an admin token for a tool that only reads. Prefer read-only modes where a server offers them, and isolate high-privilege tools (file access, databases, internal APIs) in a separate agent context that external MCP servers cannot reach. Rotate and revoke tokens on a schedule; our companion guide on securing your MCP server connections covers rotation, OAuth, and transport hardening in depth.

2. Vet servers before you install them

Maintain an allowlist of approved servers and block arbitrary connections. Before adding a server, read its source or release notes, pin an exact version rather than tracking latest, and confirm the publisher is who you think it is. This is the single strongest defense against supply-chain and tool-poisoning attacks, because an unvetted server is untrusted code running with your permissions. The best MCP servers for security teams roundup favors maintained, widely-reviewed servers for exactly this reason.

3. Sandbox execution

Run servers in an isolated environment, such as a container or a restricted user account, so a compromised server cannot reach your host, other projects, or the wider network. The NSA recommends a filtering outgoing proxy or enterprise data-loss-prevention for external MCP connections, with resource URLs pinned tightly to reduce leakage. Sandboxing also contains the blast radius of the Arbitrary Code Execution class of bug.

4. Require human approval for destructive actions

Gate any irreversible or high-risk operation (deleting data, sending money, pushing code, emailing customers) behind explicit human confirmation outside the model's control. The MCP specification acknowledges that there should always be a human in the loop with the ability to deny tool invocations, and annotating tools with risk classifications makes those gates enforceable rather than optional.

5. Audit and log every tool call

Log which server was called, with what arguments, and what it returned, so you can detect anomalies and reconstruct incidents. Enforce restrictions server-side rather than relying on system-prompt instructions, because injected text can override a prompt but not a backend access control. Constrain tool responses to a fixed JSON schema and reject anything that does not match, which blunts the free-text injection that tool poisoning depends on.

Risk-to-Practice Checklist

The table below maps each MCP security risk to its primary best practice and the fastest way to act on it.

What the NSA and OWASP Recommend

In May 2026, the NSA's Artificial Intelligence Security Center published a Cybersecurity Information Sheet titled "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation," its first dedicated MCP guidance. The NSA press release stresses that MCP does not define how a session maps to a verifiable identity, that authentication is optional rather than required, and that role-based access control is not part of the protocol, so those controls must be added at the deployment layer.

OWASP's guidance is narrower and tactical: validate structured output, isolate privileged tools, enforce access controls server-side, allowlist approved servers, and require user confirmation for sensitive operations. The Cloud Security Alliance's Agentic MCP Security Best Practices reaches the same conclusions from an enterprise angle. When three independent bodies converge on least privilege, vetting, and human oversight, that consensus is the checklist to follow.

When These Practices Are Not Enough

These practices reduce risk but do not eliminate it, and pretending otherwise is the mistake. A perfectly sandboxed server can still relay a poisoned tool result, and a least-privilege token still grants some access an attacker can abuse. Defense in depth is the goal, not a single silver bullet.

Skip the higher-effort controls only when the stakes are genuinely low, for example a keyless, read-only, local documentation server on a throwaway machine. The moment a server touches production data, credentials, or write actions, apply the full checklist. If you are building your own server rather than installing one, our guide on how to build your own MCP server covers where to bake these controls in from the start.

Related Guides

• Securing Your MCP Server Connections
• AI Agent Security Risks: The Complete Guide
• Best MCP Servers for Security Teams
• OpenClaw MCP Servers Explained