MCP security

An MCP server is code that acts with your credentials. That single sentence is most of MCP security — everything below is about deciding which code deserves that, and limiting what happens when you're wrong.

The trust model

When you connect a server, you give it two things: credentials (an API key, or an OAuth grant) and a channel into your AI assistant's context. The server sees every request the assistant routes to it and returns text the model will read and act on. There is no sandbox between a local MCP server and your machine — it's a process you launched, with your filesystem and network access.

For an official server, that's the same trust you already extend to the vendor whose API key you're using. For a community server, it's trust in an unaudited third party — which is why every verdict on this site leads with that distinction.

Scope the credentials

The cheapest security win: never hand a server more than the task needs.

• Issue a dedicated key per server — revoking it later shouldn't break anything else.
• Prefer read-only scopes until the server has earned write access.
• Scope to the project, not the account — a repo-level token, not an org-level one.
• Keep secrets in environment variables, not pasted into config files that end up in dotfile repos and screenshots.
• Revoke on removal. Deleting a server from your config doesn't delete the key it was using.

Remote servers: OAuth 2.1

Remote servers are the better-governed half of the ecosystem. The MCP specification's authorization model is built on OAuth 2.1: your client registers with the server, sends you through the vendor's own consent screen, and receives short-lived, per-client tokens with PKCE protecting the exchange. What that buys you in practice:

• Your password never passes through the MCP client or server config.
• The consent screen tells you exactly which scopes the server gets — read it.
• The grant is revocable from the vendor's dashboard, independent of the client.
• The vendor runs the server, so patching is their job, not yours.

A remote server that instead asks you to paste a long-lived API key into a URL or header works, but you lose the consent screen and easy revocation — one more reason to prefer endpoints the vendor documents. Our remote-server guide lists every vendor-hosted endpoint we've verified.

Local servers: supply-chain hygiene

A local server is an npm or PyPI package you execute with npx -y or uvx — the same trust decision as curl | sh, dressed better. Before running one:

• Read the source, or at least skim every place it makes a network call. An MCP server has no business phoning anywhere except the API it wraps.
• Check the maintainer and the commit history. A server abandoned for a year wraps a year-old API and a year of unpatched dependencies.
• Pin the version. @vendor/mcp-server@1.4.2, not a bare name that silently picks up whatever gets published next — npx -y re-resolves on every launch.
• Watch for install scripts. npm packages can run arbitrary code at install time, before the server even starts.
• Prefer the official package where one exists — check the brand's verdict page here; 212 of 234 brands have one.

{
  "mcpServers": {
    "example": {
      "command": "npx",
      "args": ["-y", "@vendor/mcp-server@1.4.2"],
      "env": { "VENDOR_API_KEY": "${VENDOR_API_KEY}" }
    }
  }
}

Prompt injection via tool results

The least intuitive risk: the server can be perfectly honest and still hurt you. Whatever a tool returns — a webpage, a Jira ticket, an email — lands in the model's context as text, and text can contain instructions. A hostile document can tell the assistant to exfiltrate whatever else its tools can reach, and models sometimes comply.

You can't filter your way out of this; the defense is blast-radius control. Connect servers that fetch untrusted content (web, email, tickets) in sessions that don't also hold write access to anything precious, keep approval prompts on consequential actions, and treat "the agent did something I didn't ask for" as the expected failure — not an exotic one.

The checklist

1. Does an official server exist? Use it. Check the verdict first.
2. Community only? Read the source, check the maintainer, pin the version.
3. Issue a dedicated, scoped, revocable credential — read-only until proven.
4. Remote server? Prefer OAuth over pasted keys; read the consent screen.
5. Keep approval prompts on writes; never auto-approve alongside untrusted content.
6. Removing a server? Revoke its key too.

Questions