MCP Security Best Practices

Is MCP safe?

MCP is as safe as the servers you connect and the permissions you grant them. If the term is new, start with what an MCP server is.

The protocol's auth rules are strict. Remote servers use OAuth 2.1 with PKCE, and a server must check that each token was issued for it. MCP OAuth explained walks through that flow.

The spec's security best practices page covers attacks on that layer: confused deputy, token passthrough, SSRF, mix-up attacks and compromised local servers. It does not mention prompt injection or tool poisoning. Those risks sit above the protocol, in what the model reads and which packages you install:

• The model can be steered by text that a tool returns.
• A community server can be malicious, or turn malicious in a later version.
• A local server runs code on your machine with your permissions.
• A host that runs servers for many customers is one large target.

OWASP tracks these in its MCP Top 10, which is still a beta release.

The main MCP security risks

Prompt injection through tool output

This one has no complete fix. OWASP lists prompt injection first among its LLM risks, as LLM01:2025, and its own entry says no prevention method is known to be fool-proof.

MCP makes the indirect kind easy to hit. An email, a support ticket or a web page comes back from a tool, and it carries instructions.

In May 2025, Invariant Labs showed this with the official GitHub MCP server. A user asked an agent to look at the issues on a public repo. One issue held planted instructions, and the agent copied details of the user's private repos into a public pull request. Invariant noted that the server code had no bug. The agent held private data, read untrusted text and could publish, all in one session.

Simon Willison calls that combination the lethal trifecta: access to private data, exposure to untrusted content, and a way to send data out. He advises keeping the three apart, because no filter catches every attack.

Tool poisoning and rug pulls

In April 2025, Invariant Labs showed that a tool description works as a prompt the user rarely reads in full. Their example was an add tool. Its description told the model to read ~/.cursor/mcp.json and ~/.ssh/id_rsa and pass the contents along in a spare parameter. They ran it in Cursor.

The same write-up describes two variants:

• Shadowing. One server's description changes how the model uses another server's tool. In the demo, a trusted send_email tool began sending every message to the attacker's address.
• Rug pull. A server changes its tool descriptions after you approved it.

postmark-mcp is the rug pull in package form. Postmark's own notice says someone published an npm package under its name and shipped 15 versions to build trust. Version 1.0.16 then added a backdoor that BCC'd email to an external server. Postmark had not published an MCP server on npm at all before the incident.

Token passthrough and confused deputy

Two spec rules apply here. An MCP server must reject any token that was not issued for it. It also must not pass the client's token on to an upstream API. Upstream, it uses its own separately issued token.

Passthrough lets a caller skip the server's rate limits and request validation. It also muddies the audit trail, because the upstream API's logs show the wrong caller.

The confused deputy case affects proxy servers that use one static client ID with a third-party API. If the third party sets a consent cookie, an attacker can register a new client and send the user a link. Consent is skipped, and the authorization code lands with the attacker. The spec's fix is per-client consent on the MCP server, before it forwards anyone to the third party.

Local server exposure

A local server runs with your user permissions, so two things can go wrong.

The first is the install. A one-click setup can run any command. The spec requires clients to show the full command and ask before running it.

The second is exposure. A local server that listens on HTTP can be reached by other processes. Through DNS rebinding, a website you visit can reach it too.

CVE-2025-49596 shows the second case. MCP Inspector is a developer tool published as @modelcontextprotocol/inspector. Before version 0.14.1 it had no authentication between the Inspector client and its proxy. An unauthenticated request could launch MCP commands over stdio, which means remote code execution. GitHub rates it 9.4, critical.

Hosted servers concentrate risk

Hosting removes the local risks and adds a concentrated one.

In June 2025, GitGuardian found a path traversal flaw in Smithery's build configuration. The dockerBuildPath setting accepted paths outside the repo, which exposed a Docker config file holding a Fly.io token. That token reached an organization with more than 3,000 apps, most of them hosted MCP servers. With it, an attacker could have run code on those servers and captured the API keys their users sent.

GitGuardian reported the flaw on 13 June. Smithery rotated the key the next day and shipped the full fix on 15 June. No evidence of exploitation was found.

Ask every host, PopMCP included, how it isolates builds, where it stores secrets and what its internal tokens can reach.

MCP security checklist

Copy this into your review doc and adapt it.

Choosing servers

• Take the server from the vendor's own docs or a host you have vetted. A brand name on a package proves nothing: the fake postmark-mcp was on npm while Postmark's real server was not.
• Read each tool description in full, not only the name.
• Pin versions, and read the diff before you update.
• Remove servers nobody uses. OWASP lists unapproved "shadow MCP servers" as MCP09.

Scopes and tokens

• Grant the smallest scope set that does the job. The spec lets a server ask for more later through a step-up challenge.
• Prefer servers whose access tokens expire quickly. The spec tells auth servers to issue short-lived tokens and to rotate refresh tokens for public clients.
• Confirm that the server validates token audience and calls upstream APIs with its own credential.
• Keep secrets out of config files you sync or commit. Token and secret exposure is OWASP's MCP01.

Agent behaviour

• Try a read first, and check the model picked the right account.
• Leave your client's confirmation prompts on for writes. This is a client feature, and the MCP spec says a human should be able to deny any tool call. ChatGPT developer mode asks before write actions by default, and treats a tool as a write unless it carries the readOnlyHint annotation. Cursor asks before using MCP tools by default. Claude shows an approval request, and Anthropic says to pick "Allow always" only for a server and tool you trust.
• Keep the lethal trifecta out of a single session. A session that reads inbound support email should not also hold a tool that sends mail.
• Give each session only the accounts and repos the task needs.

Local servers

• Prefer stdio to an HTTP port.
• If you must use HTTP locally, require a token and bind to 127.0.0.1, not 0.0.0.0.
• Read the exact launch command before you approve a one-click install.
• Run the server in a container or sandbox with limited file and network access.
• Keep developer tools patched. For MCP Inspector that means 0.14.1 or later.

Monitoring

• Log every tool call with the user, the tool and the time. The MCP tools spec asks clients to log tool usage for audit.
• Know how to cut off one client's access, and test that it works.

What PopMCP covers and what it leaves to you

PopMCP hosts MCP servers for 100+ business tools behind one URL. As a host, it carries the concentration risk described above. These are its controls as they stand.

Provider credentials stay in PopMCP, encrypted at rest with AES-256-GCM. They are never passed to the AI client. The client signs in to PopMCP with OAuth, so there is no API key to paste into a config file. On the consent screen you tick which connectors that client may reach.

Access limits depend on the plan:

• Free is read-only for everyone. Write tools are not exposed.
• Starter and Studio: teammates other than the owner are read-only.
• Scale and Enterprise: the owner sets each teammate to read-only or full access, per connection. These plans also get an account-level IP allowlist of up to 50 IPv4 or IPv6 entries, CIDR ranges included.

Workspaces keep each client's or brand's connections apart. The FAQ has more on credentials and access.

What it leaves to you:

• PopMCP has no approval step of its own. A write runs when the model calls it, and the owner cannot set their own connection to read-only. The confirmation prompt is your AI client's job.
• It cannot stop a model from being steered by a malicious email or ticket that a tool returns.
• There is no screen for withdrawing one AI client's grant. You remove the member, disconnect the connector, or run consent again with fewer connectors ticked. Removing a member or disconnecting a connector takes effect on the next request.
• PopMCP makes no SOC 2 claim. SSO is on request for Enterprise, not self-serve. Data is hosted in the United States.