MCP Security Risks: What to Check Before You Connect

MCP security risks start from one plain fact: an MCP server is someone else's code that you invite into your AI app, and the model, not you, decides when to call it. Whether that is fine depends on who wrote the server, what it can reach, and what text it feeds back to the model.

If you are about to paste a server into your app's config, here is the short version:

• A local server runs on your machine. It has the same privileges as the app that launched it.
• A remote server runs on someone else's. It sees whatever the model sends it and acts with whatever account access you grant.
• Anything a server returns is input to the model. That is the route for prompt injection.
• MCP does not enforce safety for you. The specification says so itself, and hands most of the work to the app and to you.

This post sticks to primary sources: the MCP specification, Anthropic's documentation, and OWASP. For the basics, start with what MCP is.

What an MCP server can access and run

The specification's own overview opens its security section with a blunt sentence: MCP enables powerful capabilities through arbitrary data access and code execution paths. It adds that tools represent arbitrary code execution and must be treated with caution.

How much that matters depends on where the server runs.

Anthropic's Claude Code documentation describes stdio servers as local processes on your machine, and recommends HTTP for remote ones. The specification's security best practices go further on the local side: they tell client apps to warn that MCP servers run with the same privileges as the client, and they list sandboxing as a mitigation rather than a given.

The spec's own example of a hostile startup command chains an npm package install to a command that uploads ~/.ssh/id_rsa to a remote address. That is what a local server is allowed to do if you let it.

Remote is not automatically safer. The tools section of the spec tells clients to show tool inputs before calling the server, to avoid malicious or accidental data exfiltration. Whatever the model puts in those arguments goes to a third party.

The MCP security risks the spec itself names

The security best practices page is written for people building servers and clients, but each risk maps to something you can check as a user.

Four notes on that table.

Consent is the thread running through it. For the confused deputy case, the spec requires the server's own consent page to name the requesting client, show the requested scopes, and show the redirect address. If a connection flow skips straight to "connected" without showing you any of that, treat it as a reason to slow down.

The session story changed. The current specification revision, dated 2026-07-28 as of October 2026, has no protocol-level sessions, so the old "session hijacking" section became state handle hijacking. The previous revision's version of that page still documents session hijacking. Which one applies depends on which revision a given server speaks, another reason to check that a server is maintained.

Scope has a catch. The authorization specification says that when a server does not hint which scopes a request needs, clients fall back to requesting all the scopes the server lists. The security page recommends the opposite design: start with a minimal set and ask for more only when needed. Look at what the consent screen actually asks for.

Authorization is optional. The same page states that authorization is optional for MCP implementations, that HTTP-based ones should follow the spec, and that stdio ones should instead retrieve credentials from the environment. A server with no authentication at all is within the rules, so find out which kind you are connecting.

Prompt injection through tool output

This is the risk the protocol cannot fix, because it is not a protocol bug.

OWASP defines indirect prompt injection as what happens when a model accepts input from external sources such as websites or files. Its listed impacts include disclosure of sensitive information and executing arbitrary commands in connected systems. An MCP server is an external source by definition. Whatever it returns, whether that is a web page, a ticket, or an email body, lands in the model's context next to your own instructions.

Here is a hypothetical. You connect a web-fetch server and a mail server to the same assistant. You ask it to summarize a page. The page contains hidden text addressed to the assistant, telling it to forward your latest messages somewhere. The model has no reliable way to tell that text from your request, and the mail tool is already connected. No server was hacked. Two ordinary servers and one hostile page were enough.

The combination to watch is three things at once: content you do not control, access to private data, and a way to send data out. Remove any one and that story gets much harder.

What the primary sources actually give you:

• Anthropic's warning is direct: verify you trust each server before connecting it, and note that servers that fetch external content can expose you to prompt injection risk.
• The spec asks clients to help. Tool inputs should be shown to you before the call, results should be validated before they reach the model, and servers must sanitize their outputs.
• OWASP's mitigations apply as they are. They include enforcing least privilege, requiring human approval for high-risk operations, and segregating external content.
• Claude Code's security guidance lists habits for untrusted content: review suggested commands before approving, avoid piping untrusted content directly to Claude, and use virtual machines when interacting with external web services.

Anthropic's own security page is plain about the limit: no system is completely immune to all attacks. Keep a human in the loop for anything that changes state or sends data out.

Untrusted servers and the supply chain

An MCP server is a dependency, and dependencies have a supply chain. OWASP's entry on LLM supply chain risk lists outdated components and weak provenance among the common problems, and its prevention advice starts with vetting suppliers.

Anthropic's security guidance on MCP specifically is that it encourages either writing your own servers or using servers from providers you trust. It also states that Anthropic reviews connectors against listing criteria before adding them to its directory, but does not security-audit or manage any MCP server. A directory listing is a filter, not a guarantee.

One more thing makes this harder than it looks: the server you review may not be the only server loaded. In Claude Code, project servers live in .mcp.json, but servers can also come from other scopes, claude.ai connectors, and plugins, so reading that file does not show everything a session can load. And while Claude Code asks for approval before using project-scoped servers in interactive sessions, it documents that claude -p runs, Agent SDK sessions, and cloud sessions cannot show that prompt and load them without asking. A repository you cloned can carry its own server list, so look before you run it unattended.

For a way to size up a server, our guide to the reference servers covers who published it, whether it needs credentials, and whether it is maintained.

A checklist before you connect an MCP server

Each item maps to a source above.

1. Start with the least access that works. OWASP's excessive agency entry names three root causes: too much functionality, too many permissions, and too much autonomy. Connect only the servers the current task needs, and give each narrow credentials. If a filesystem server only needs one project folder, give it that folder and nothing else.
2. Read the server before you install it. For a local server, that means the exact command your app will run, arguments included. The spec asks clients to show that command in full before one-click setup. If the command contains sudo, a download piped to a shell, or a path to your SSH keys, stop.
3. Prefer official servers. A server published by the vendor of the system it wraps beats a community wrapper, especially when it holds credentials. Writing your own is Anthropic's other suggestion.
4. Approve tools one at a time, on purpose. The spec says there should always be a human in the loop with the ability to deny tool calls, but also says the protocol does not mandate any specific interaction model. So the approval behavior is your app's, and you should know what it is. In Claude Code, permission rules cover MCP tools directly: the permissions documentation shows mcp__servername matching a whole server and mcp__servername__toolname matching one tool, with allow, ask, and deny rules.
5. Treat a tool's description of itself as untrusted. The spec says clients must consider tool annotations untrusted unless they come from a trusted server. A name that starts with get_ is a convention, not proof the tool only reads.
6. Keep secrets out of places the model can read. Do not paste API keys into a chat, and do not hard-code them into a config file you might share. Claude Code supports variable expansion in .mcp.json, so the file can reference a variable instead of containing the key.
7. Separate untrusted reading from powerful acting. Avoid giving one assistant both a server that pulls in outside content and a server that can send messages, change records, or run commands. If you need both, keep approvals on for the acting one. Here is what item 4 can look like in a Claude Code settings file. It pre-approves one server's tools whose names start with get_, and blocks another server outright.

{
  "permissions": {
    "allow": ["mcp__github__get_*"],
    "deny": ["mcp__puppeteer"]
  }
}

The server names here are examples, and a name pattern only approves what the server chose to name that way, which is why item 5 matters. Tool-name wildcards in allow rules only work after a literal mcp__servername__ prefix. A bare mcp__* in an allow rule is skipped with a warning and approves nothing.

Where this leaves you

You are not choosing between "safe" and "unsafe" MCP. You are deciding, server by server, how much trust you can justify. Official servers, narrow credentials, a command you read, and approvals left on for anything that acts make a defensible setup. A pile of community servers set to run unattended does not.

Hand-assembling an AI setup from config files means every connection is a trust decision you make alone. If you would rather start from a setup someone already got working, Taku mirrors an app, skill, or workflow into a desktop workspace and runs it. That does not replace the checks above, because you still decide which accounts and folders any setup may touch. Taku is in Beta, and the Mac app is available now.

FAQ

Are MCP servers safe to use?

Some are, and the protocol does not decide which. MCP is a specification, and its own overview says the protocol cannot enforce its security principles. Safety depends on who wrote the server, what credentials it holds, how your app asks for approval, and what content it feeds the model. Official servers with narrow access are a reasonable default.

What is MCP prompt injection?

It is indirect prompt injection delivered through a server: returned content, such as a page or message, carries text meant to steer the model. Because the model reads tool output next to your instructions, it can act on it. OWASP lists least privilege and approval for high-risk actions among its mitigations.

Can a malicious MCP server harm my computer?

A local one can do whatever your user account can, unless your app sandboxes it. The spec lists arbitrary code execution and data exfiltration among the risks of untrusted local servers. Check the exact startup command.

Does MCP have built-in authentication?

Not required. The authorization specification says authorization is optional. HTTP-based servers should follow it, which means OAuth, and stdio servers should instead retrieve credentials from the environment. Ask which kind a server is before you give it anything.

Are remote or local MCP servers safer?

Neither, categorically. A local server's danger is what its code does as you. A remote server's danger is what it receives and what your authorized account lets it do. Apply the checklist either way.