Are MCP Servers Safe? Security Risks & How to Lock Them Down

Before you paste that MCP server into your config: it can read more than you think. I learned this the first time I connected a filesystem server and watched my AI assistant list files I’d forgotten were even on that drive. Nothing went wrong — but it easily could have.

The honest answer to “are MCP servers safe?” is yes, if you connect them deliberately — and most of the scary stories come from people who didn’t. This post shows you exactly what an MCP server can touch, how it actually goes wrong, and the five-minute checklist that keeps you on the safe side.

What MCP servers can actually access#

The risk of any MCP server comes down to one question: what can it reach on your behalf? The answer depends entirely on whether it runs locally or remotely.

A local server is the common case — Claude Desktop or Cursor launches it as a subprocess on your machine using a command in your config. That subprocess runs with your user permissions. A filesystem server can read and write your files; a shell server can run commands; and your API keys sit in the config’s env block in plaintext. There’s no sandbox by default. A local MCP server is exactly as powerful as you are on your own computer.

A remote server runs somewhere else and talks to your client over HTTP. It can’t see your filesystem, but it does hold whatever token you gave it — and if that endpoint is exposed without authentication, anyone can reach it. The diagram above is the whole threat model in one picture: the server is only as safe as what you allow it to touch.

The five-minute MCP hardening checklist#

Most of the safety gap closes with a handful of habits. Run through this list before you connect any new server, and save it — you’ll come back to it.

• Connect only servers you can trace to a real maintainer. Official vendor servers (GitHub, your database) or popular open-source repos with visible commit history — not a random package you found an hour ago.
• Give the smallest token that works. If a GitHub server only needs to read issues, don’t hand it a token that can push to main. Least privilege is the single highest-leverage control here.
• Keep secrets out of plaintext where you can. Reference environment variables instead of pasting raw keys into the config, and make sure the config file is readable only by your user account.
• Prefer local for anything that touches private data. A local server keeps the data on your machine; a remote one sends it across the network.
• Require a human in the loop for write actions. Reading is low-risk. Deleting, sending, and pushing are not — keep approval on.
• Review the tools a server exposes after connecting. Open the tool list once and read what it can do. If a “weather” server also offers read_file, disconnect it.

If you haven’t set one up yet, my Claude MCP setup walkthrough shows where the config lives and how the env block works.

The real risks — and how they actually happen#

Here’s what genuinely catches developers, ranked by how often I see it rather than how scary it sounds.

Tool poisoning is the one most people miss. Malicious instructions are hidden inside a tool’s description — text the model reads but you never see in the UI. Simon Willison flagged this class of prompt-injection problem early, and it’s still the most practical attack on the client side. A poisoned tool can also pull a “rug pull”: it looks benign when you approve it, then silently redefines itself later.

Common mistake: trusting a tool because you read its name. The model reads the full description and schema, not just the label — that’s where the hidden instruction lives.

Unauthenticated remote servers are the systemic problem. The first large-scale measurement of remote MCP servers found that roughly 40% expose their tools with no authentication at all. By early May 2026, Censys counted more than 21,000 internet-accessible MCP services. The protocol was designed for local, trusted use, so every server you put on the public internet without adding auth becomes an open RPC endpoint.

Over-scoped tokens and plaintext secrets turn a small mistake into a big one. Because servers centralize credentials, one compromised server can hand an attacker everything that token unlocks. And the bugs are real: researchers disclosed 40+ CVEs against MCP implementations in early 2026, including CVE-2025-6514, a command-injection flaw in the popular mcp-remote proxy that allowed remote code execution.

What “secure by default” looks like now#

The spec has been catching up fast, and it changes how you should think about remote servers. The June 2025 revision of the Model Context Protocol first classified remote MCP servers as OAuth 2.1 resource servers — a rule that carried into the current stable spec (2025-11-25) and is hardened further in the 2026-07-28 release candidate, which also moves the transport to a stateless core.

In practice that means a properly built remote server no longer invents its own ad-hoc auth. It returns an HTTP 401 with a pointer to its protected-resource metadata, tells the client which authorization server issues tokens, and expects a token scoped to that resource. The upshot for you is simple. When you evaluate a hosted MCP server, “does it speak OAuth 2.1?” is now a fair, concrete question to ask.

Local stdio servers don’t use OAuth — they’re trusted because they run as you — so the lock you control there is least privilege, not tokens. That’s why the checklist leans so hard on token scope: for local servers, scope is your security boundary.

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "fine-grained-read-only-token" }
    }
  }
}

That config is fine because the token is fine-grained and read-only. The security lives in the token scope, not the JSON.

How to vet a third-party MCP server before connecting it#

When a server isn’t from a vendor you already trust, spend two minutes vetting it before you connect. Open the repo and check it has a real maintainer and recent commits — not a single anonymous drop. Skim the tool list and ask whether the permissions match the job; a notes server has no business requesting shell access.

Then weigh the social signals. Prefer servers with more stars and visible open issues, since real problems surface publicly. If it’s remote, confirm it supports authentication rather than sitting open to anyone. None of this is foolproof, but it filters out the obviously risky ones — which is most of the danger. If you want to understand the server side deeply enough to audit one yourself, my Build an MCP Server in Python guide builds an authenticated server from scratch.

So, are they safe?#

Yes — with eyes open. MCP servers are as safe as the permissions you grant, the sources you trust, and whether you keep a human in the loop for anything destructive. The protocol’s 2025 OAuth work and the flood of security research mean the ecosystem is hardening in real time, but the controls that protect you today are the boring ones on the checklist above. Run it once per server and you’ve handled the realistic risks.

Which MCP servers are you running right now — and did you actually check what permissions they have? Tell me in the comments.

Read next: What Is an MCP Server? Complete Guide for Developers (2026) — the protocol explained end to end. Related: GitHub MCP Server: Connect Claude to Your Repos for a real, well-scoped server to start with.