← All guides

Locus product guide · Updated

MCP security: risks, attacks and a checklist

MCP security covers three risks. Code you run: a local server inherits your files, keys and network. Text the model reads: tool descriptions and results can carry prompt injection or tool poisoning. Tokens: confused deputy and token passthrough attacks. The spec requires audience-bound OAuth tokens, per-client consent in proxies, and a human able to deny tool calls. Run third-party servers in containers, pin versions and scope credentials.

What are the main MCP security risks?

The MCP security guides name these attacks. The fix column shows the main defense from the spec or its best practices.

What are the main MCP security risks?
RiskWhat happensMain defense
Malicious or compromised local serverA typosquatted package or a bad dependency reads your SSH keys, cloud credentials or filesCheck the publisher, pin versions, run it in a container
Tool poisoning and rug pullsHidden instructions in tool descriptions steer the agent, or a server changes its tools after you approved itRead tool lists, use a client that re-prompts when definitions change
Prompt injection in resultsA web page or document returned by a tool tells the agent to do something elseConfirm sensitive actions, validate results before the model sees them
Confused deputyAn attacker reuses a consent cookie on an MCP proxy to steal an authorization codePer-client consent in proxies, exact redirect URI matching
Token passthroughA server accepts or forwards a token issued for another serviceAccept only tokens issued for this server
Malicious authorization URLA server returns a javascript: URL that runs code in the clientAllow only https, or http on loopback
State handle hijackingAn attacker guesses a cart or workflow ID and acts on another user’s stateRandom handles bound to the signed-in user
Over-broad scopesOne stolen token opens every tool and data setMinimal scopes first, step-up when a tool needs more
DNS rebindingA website reaches a local HTTP server through your browserValidate the Origin header, bind to 127.0.0.1, require auth

What does the MCP spec require?

The 2026-07-28 spec states these as MUST or SHOULD rules. They apply to anyone who builds a client, server or proxy.

  • Servers must validate that a token was issued for them, and must not accept or pass on any other token.
  • Tokens go in the Authorization header on every request, never in the URL.
  • HTTP servers must validate the Origin header. Local servers should bind to localhost only.
  • Tool servers must validate inputs, enforce access controls, rate limit calls and sanitize outputs.
  • Clients should show tool inputs before a call, confirm sensitive operations, time out slow calls and log tool use.
  • Clients must treat tool annotations as untrusted unless the server is trusted.
  • A client with one-click local install must show the full command and get explicit approval before it runs.
  • There should always be a human in the loop who can deny a tool call.

How do I run local MCP servers safely?

A local server is an ordinary process with your user’s rights. The stdio transport is not a sandbox. The MCP local server security guide gives these defaults.

  • Remove servers you do not use, and know where each remaining one came from.
  • Pin versions. Pinning with npx or uvx fixes only the top package. Pinning a container image by digest freezes the whole dependency tree.
  • Run third-party servers in a container with nothing mounted except the folder they need.
  • Pass each server only its own narrowly scoped token through per-server config, not your shell profile.
  • Limit outbound network access for servers that do not need it.
  • Read each server’s tool descriptions once, for example in MCP Inspector, and remove any server whose descriptions carry unrelated instructions.

How do I secure a remote MCP server I run?

Follow the authorization spec and treat every tool call as untrusted input from the network.

  • Use OAuth 2.1 with PKCE, and check the token audience on every request.
  • Start with a small scope set. Return 403 insufficient_scope with the extra scopes when a tool needs more.
  • Bind any state handle to the user ID in the verified token, and generate it with a secure random source.
  • Rate limit per user and per tool.
  • Do not mark passwords, keys or personal data with x-mcp-header. Header values are visible to proxies.
  • Log each tool call with the user, tool, arguments summary and result status.

Can an agent overspend through a paid MCP server?

Yes. A prompt-injected or looping agent can call a paid tool again and again. Rate limits slow the loss but do not stop it.

Worked example on Locus Pro: the Free plan allows 5 billable calls a minute. A loop on Brave web search, at 30.3 credits a call, can spend 151.5 credits a minute, or $9.09 an hour. On Plus, at 15 calls a minute, the same loop costs $27.27 an hour. Prices checked November 10, 2026.

Locus Pro gives you hard stops for that case. The spend caps are off until you set them, so set them before you let an agent run alone.

  • Prepaid balance: when credits run out, calls fail with 402 before they run, unless you turned on auto-recharge.
  • Price ceiling: each call can carry max_credits. A call priced above it fails and nothing is charged.
  • Workspace monthly hard limit: new calls stop once the month’s charges and holds reach it.
  • Monthly budget per agent key or connected app.
  • Approval for any call over a set amount, sent to an admin.
  • Read-only connections: an OAuth grant with only mcp:read can search but cannot spend.
  • Call history: list_calls shows each call, its status and the credits charged.

What should an MCP security checklist include?

Use this list before you add a server to a team’s agents.

  • The publisher is known and the version is pinned.
  • Third-party local servers run in a container, VM or sandbox.
  • Each server has its own scoped credential, stored in the client or an OS keychain.
  • Remote servers use OAuth, not shared API keys in config files.
  • Tool descriptions were read, and the client warns when they change.
  • Writes, deletes, sends and payments need human approval.
  • Paid tools have a per-call price ceiling and a monthly cap.
  • Tool calls are logged with user, tool and result.

Frequently asked questions

What is tool poisoning in MCP?

Tool names and descriptions are text the model reads as instructions. A malicious server can hide directives there, even ones aimed at other servers’ tools. The tool does not have to be called for the attack to work.

Is stdio safer than Streamable HTTP?

Stdio limits who can talk to the server to the client that launched it. It does not limit what the server can do on your machine. Isolation has to come from a container or sandbox.

Are remote MCP servers safer than local ones?

They cannot read your machine, which removes the biggest local risk. You do trust the operator with the data you send and with your OAuth grant. Check the requested scopes before you approve.

Should I approve every MCP tool call?

Approve calls that write, delete, send or spend. Read-only calls such as search can usually run without a prompt. The spec asks clients to keep a human able to deny any call.

Implementation references

Use these first-party references for current request contracts and account requirements. Tool availability, prices, and negotiated terms can change.

Sources

Third-party details were checked on November 10, 2026. Vendors change pricing and features often, so confirm on their site before you decide.

Related guides