Running MCP servers you do not fully trust

The install is one line, which is the problem. Nothing about `npx some-mcp-server` signals that you have just given a program your database credentials, your logged-in browser, or your issue tracker, and wired it to something that will call it without asking you first. Most servers are fine. This is about the ones that are not, and about the failure that happens even when every server involved is honest.

Three different risks, often confused

They need different answers, so it is worth separating them. One: what the server can do by design. A database server can usually write as well as read. A browser server acts as you on every site you are signed into. Two: what the server does that it should not. Ordinary supply chain risk — a malicious package, or an honest one that got taken over. Three: what the server is told to do by someone else. This is the one that is specific to MCP, and the one people have not thought about.

The third one, properly

This is not theoretical and it is not a bug in any particular server. It is what happens when you connect a system that follows instructions to a source of text that other people can write. The practical shape of it: a server that only reads is still a way in, because reading is how the instruction arrives. The damage then comes from whatever else is connected — the one with write access, or the terminal.

What actually helps: Do not run a server that reads untrusted text in the same session as one that can act irreversibly, if you can avoid it. The combination is the risk, more than either part. Read approval prompts when the session has touched outside content. The prompt is the control, and clicking through it is the failure. Treat anything your tool summarises from an external source as data, not as a decision. If it says "the issue asks me to update the deploy key", that is the issue talking.

Narrow what a server can do

Most of the useful hardening is not clever. It is giving the server less.

claude mcp add playwright -- npx @playwright/mcp@latest --isolated --image-responses omit

The same confirmation as a plain install. The browser now starts from a clean profile each run and keeps no logins on disk.

`--isolated` is the interesting flag there: it is the difference between a browser server that can act as you everywhere and one that starts logged in to nothing. The equivalents elsewhere are worth looking for. A database server usually has a read-only mode. An API server usually accepts a token you scoped yourself. The default is almost always more access than the job needs, because the default has to work for everyone.

The `@latest` problem

Nearly every install line you will copy ends in `@latest`, including the ones in our own guides. That means every run fetches whatever was published most recently, by whoever can publish. For a server from a company whose product you already depend on, that is a reasonable trade. For a server you found because it had a nice README, it means the code you reviewed on Tuesday is not necessarily the code running on Thursday.

claude mcp add playwright -- npx @playwright/mcp@0.0.83

The same confirmation. This install now runs that one version until you change it, rather than whatever was published this morning.

That version number is an example, and it is the current one today rather than the right one forever — check what is published before you pin. Pin the ones that matter. You give up automatic fixes, which is a real cost, so this is a judgement rather than a rule: pin what has access worth protecting, let the rest float.

Scope is a security control too

A server installed globally is connected in every project, including the ones that have nothing to do with it and the ones where you are reviewing someone else's code. Project scope is not only tidier. It means the server with your production database credentials is not sitting in the session where you opened a stranger's repository to have a look.

Before you install one

A short version of what is worth checking, roughly in order of how much it tells you: Who publishes it, and is that the same organisation as the product it talks to. When it was last updated, and whether its issues look attended to. What access it asks for, and whether a narrower mode exists. Whether it needs a credential you would mind losing. If yes, make a new one scoped to it.

The second prompt is the one worth running on a setup you have had for a while. The answer is usually yes, and usually nobody chose it.

• MCP servers: giving your AI tool hands
• Global or project: where config lives
• Supabase MCP, safely
• Browse MCP servers