# Are MCP Servers Safe? Security Risks & How to Lock Them Down
> A practical, no-FUD security guide for developers connecting MCP servers to their AI assistant — what a local versus remote server can actually access, the real risks (tool poisoning, over-scoped tokens, plaintext secrets, unauthenticated remote servers), what OAuth 2.1 changed in the 2025 spec, and a five-minute hardening checklist plus how to vet a third-party server.
*Source: https://www.infowok.com/are-mcp-servers-safe-security-2026/ · Sukhveer Kaur · Published June 17, 2026 · Updated July 6, 2026*
---
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.
- **An MCP server can touch more than you expect** — a filesystem server can list anything on the drive — so connect deliberately, not casually.
- **Most scary stories come from careless setups.** A five-minute hardening checklist removes most of the risk.
- **The real risks are** over-broad access, prompt injection via tool output, and unvetted third-party servers.
- **Vet a third-party server before connecting:** check the source, the scopes it requests, and whether it authenticates.
## 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](/claude-mcp-setup-fixes-2026/) shows where the config lives and how the `env` block works.
A remote MCP server sees every argument you send it. Under the current spec, remote servers act as **OAuth 2.1 resource servers** — scope tokens narrowly and never point production credentials at a server you don't control.
## 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](https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/) 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](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization) 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](https://blog.modelcontextprotocol.io/posts/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.
```json
{
"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](/build-mcp-server-python-production/) 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)](/what-is-mcp-server-complete-guide-2026/) — the protocol explained end to end. Related: [GitHub MCP Server: Connect Claude to Your Repos](/github-mcp-server-claude-tutorial-2026/) for a real, well-scoped server to start with.