The best MCP server security practices are to run only servers from publishers you have verified, sandbox local servers with minimal privileges, give each one the narrowest credentials that work, never forward tokens that were not issued to your server, and keep human approval on tool calls that write data or reach the network.
Safeguard publishes this guide and sells a competing product, so we describe other tools only from their own documentation.
Key takeaways
- A local MCP server runs with the same privileges as the client, so treat install as code execution.
- The MCP specification forbids token passthrough. Servers must accept only tokens issued for them.
- Least privilege applies twice: to the server's own credentials and to the scopes a client requests.
- Prompt injection reaches agents through tool output, so approvals on risky tools stay on.
- Pin versions and review changes, because a clean release can be followed by a bad one.
What are the best practices for people who use MCP servers?
Users should verify the source, restrict credentials, and keep approvals on. Cursor's documentation puts it in four lines: only install servers from trusted developers and repositories, check what data and APIs the server will access, use restricted API keys, and review source code for critical integrations.
Claude Code's documentation gives concrete least privilege examples: a fine grained GitHub token limited to the repositories you need, and a read-only database user in a PostgreSQL connection string. It also says Anthropic does not security-audit or manage any MCP server, so listing in a directory is not an audit.
For the pre-install steps in order, see how to vet an MCP server before installing.
What are the best practices for people who build MCP servers?
Builders should validate token audience, minimise scopes, protect state handles, and avoid sending users through unsafe flows. The MCP specification's security best practices page covers these attacks and fixes:
- Confused deputy: proxy servers that use a static client ID must get consent per client and validate redirect URIs by exact string match.
- Token passthrough: the page states that MCP servers must not accept any tokens that were not explicitly issued for the MCP server.
- State handle hijacking: do not treat possession of a handle as authentication. Use secure random handles bound to the verified user.
- Scope minimization: start with a small scope set and ask for more only when a privileged operation needs it. Avoid wildcard scopes such as
*orfull-access.
How should you run a local MCP server?
Run it sandboxed, with the smallest file and network access it needs. The specification warns that local servers are programs that run on the same machine as the client, so attackers can place a malicious startup command in a configuration or ship a malicious payload inside the server.
Its example of a bad startup command is a package run followed by a command that sends a private SSH key to a remote host. Clients should show the exact command before connecting and require explicit approval.
For servers you build for local use, the specification recommends the stdio transport to limit access to the client. If you use an HTTP transport, require an authorization token or use unix domain sockets with restricted access.
Do you need to worry about SSRF?
If your MCP client runs on a server, yes. A malicious MCP server can supply URLs during OAuth discovery that point at internal addresses or cloud metadata endpoints. The specification advises requiring HTTPS, blocking private and link-local ranges, validating redirect targets, and using an egress proxy. It also warns against writing your own IP validation, because encoding tricks defeat custom parsers.
Which practice stops which problem?
| Practice | Problem it addresses | Who applies it |
|---|---|---|
| Verify publisher and source | Impersonation, malicious packages | User |
| Restricted API keys and read-only users | Large blast radius after a compromise | User and builder |
| Sandbox local servers | Arbitrary code execution on the host | Client and user |
| Audience validation, no passthrough | Confused deputy, token reuse across services | Builder |
| Progressive, minimal scopes | Over-broad tokens | Builder |
| Per-client consent and exact redirect match | Stolen authorization codes | Builder |
| Block private IP ranges, egress proxy | SSRF during discovery | Client operator |
| Approval on tool calls | Prompt injection through tool output | User |
How do guardrails fit in?
A guardrail sits between the agent and the tools, so a policy can allow, block or log calls without trusting each server to behave. Here is an interactive demo of an MCP guardrail.
Click through it at your own pace, or open it full screen.
Safeguard also provides an MCP server, with tool calls unlimited, for working with its own data from an assistant.
How to choose your MCP security controls: a checklist
- Can you name the publisher and confirm it matches the vendor?
- Does each tool have a clear purpose you can describe in one sentence?
- Are credentials scoped to the minimum, and stored in environment variables, not config files?
- Is the server version pinned, with a review step for updates?
- Does the server run in a sandbox or container?
- Do write and network tools require approval?
- Is there a list of approved servers that someone owns?
Frequently asked questions
Is MCP itself insecure?
The protocol has a documented security model, and the specification publishes attacks and mitigations. Most real risk comes from which servers you run and what permissions they hold.
What is token passthrough?
It is when an MCP server accepts a token from a client and forwards it to a downstream API without checking it was issued for the server. The specification forbids it.
Is stdio safer than HTTP for a local server?
The specification recommends stdio for local servers because it limits access to the client. It also notes stdio is not inherently vulnerable, but proxy setups that spawn servers add an escalation path.
Does a directory listing mean a server is audited?
No. Claude Code's documentation says Anthropic reviews connectors against listing criteria but does not security-audit or manage any MCP server.
Where should secrets for an MCP server live?
Cursor's documentation advises environment variables for secrets and says never hardcode them.
Sources
- MCP specification, security best practices: https://modelcontextprotocol.io/specification/draft/basic/security_best_practices
- Cursor MCP documentation: https://cursor.com/docs/mcp
- Claude Code MCP documentation: https://code.claude.com/docs/en/mcp
- Claude Code security documentation: https://code.claude.com/docs/en/security
Last reviewed: 19 October 2026.
