MCP Security Best Practices: A Practical Checklist

The short version: authenticate every server, prefer HTTP over stdio for anything that crosses a network boundary, treat every tool result as untrusted input to the model, and scope each credential to the smallest surface that works. The rest of this guide expands each point.

Why it matters, in current numbers: across large public scans, roughly 38–40% of MCP servers run with no authentication at all, about 43% of tested servers showed a command-injection vulnerability, and a command-execution weakness in the stdio transport remains unresolved at the protocol level across all four official SDKs. This is a real, current gap — not a manufactured angle.

The checklist

1. Require authentication on every server

If a server exposes anything beyond fully public, read-only data, it needs auth. For remote servers, that means OAuth 2.1 with short-lived, scoped tokens. For local stdio servers, it means the credential the server itself uses downstream (the database URI, the API key) is scoped and rotated — the "no auth on the MCP endpoint" model is only acceptable when the process is genuinely reachable by nothing but your local client.

2. Choose the transport deliberately

stdio is convenient and avoids network exposure, but the server runs as a child process with your full user permissions and the transport carries no encryption or identity. For anything hosted, shared between machines, or reaching internal services, use streamable HTTP with TLS and auth in front of it.

3. Treat tool output as an injection vector

Anything a tool returns — a row from a database, the text of a web page, a document's contents — enters the model's context and can carry instructions. The defence is not "sanitise the text"; it is: keep high-privilege tools (payments, writes, deploys) behind an explicit human confirmation, and never let one tool's output automatically authorise another tool's high-impact action.

4. Scope credentials to the smallest surface

A database server should get a read-only role on one schema, not an admin connection string. A CRM token should be scoped to the objects the agent actually needs. Assume the credential will end up in a log or a model transcript and scope accordingly.

5. Pin versions and watch the changelog

Roughly one MCP-related CVE has been filed every four days through 2026. Pin the exact server version, subscribe to its releases, and re-review on every bump — especially for community-maintained servers where a new maintainer or a new dependency can change the security posture overnight.

6. Isolate the blast radius

Run untrusted or broad-capability servers (browser automation, shell tools, file converters that shell out) in a container without credentials to anything that matters, on an egress allowlist.

Frequently asked questions

Is MCP secure by default?

No. The protocol defines how a client and server talk; it does not require authentication, does not encrypt stdio, and leaves credential scoping and human confirmation to the implementer. A default npx install of a server is rarely hardened.

What is the biggest MCP security risk right now?

Two, jointly: unauthenticated servers exposed wider than intended, and prompt-injection through tool output triggering a high-privilege action without a human in the loop.

How do I check whether a specific server is safe?

Look at four public signals: does it support authentication, is it actively maintained, does it have known unpatched CVEs, and what transport does it default to. That is exactly what the TrustedMCP directory scores — see how the scoring works.