MCP Server Security

What is an MCP server?

An MCP server is a process that makes capabilities available to an agent in a standard shape. It advertises a set of tools, each with a name, a description and a parameter schema, and the agent’s runtime presents those to the model so it can decide which to call. The server executes the call and returns a result.

Servers run in one of two ways, and the distinction matters more for security than it does for function. A local server communicates over stdio as a child process on the same machine, while a remote server is reached over HTTP, which means it is a network service with everything that implies.

The protocol is genuinely useful because it replaces bespoke integrations with one interface, which is why adoption has been fast. That same standardization is what makes the security properties below worth stating precisely, since a weakness in how the protocol is implemented is a weakness that repeats everywhere it is adopted.

Why are MCP tool definitions a security problem?

A tool definition is content the agent reads, and anything an agent reads can function as an instruction. The server supplies the tool’s description and parameter schema, those strings are placed into the model’s context so it knows what the tool does, and a model has no reliable way to distinguish a description written to inform it from one written to steer it.

This is the attack class usually called tool poisoning, and it is prompt injection arriving through the capability layer rather than through a document or a web page. OWASP’s MCP guidance is specific that the whole schema is in scope, so parameter schemas and tool return values carry the same risk as the description field, which means reviewing a server by reading its tool names tells you very little.

The practical consequence is that installing an MCP server is not like adding a dependency that sits inert until called. The definitions are in context from the moment the server is connected, which means a server can influence the agent before any of its tools have been invoked.

What is an MCP rug pull, and does pinning the definitions fix it?

A rug pull is a server that changes its tool definitions after you approved them. You review a server, it does what it says, you allow it, and the version your agents load next week advertises something different. The approval was real, but it described a version that no longer exists.

The recommended mitigation is to pin a hash of the complete tool definition, including annotations, and re-verify it before execution, re-prompting for consent when it changes. That is sound and worth implementing, and it is where most discussion of the problem stops.

It should not stop there, because pinning detects changes to the definition and nothing else. A server whose declared interface stays byte-identical while its implementation changes what it does passes the hash check every time. The useful mental model is the one that applies to agents generally: what a thing declares about itself and what it actually does are separate facts requiring separate evidence, and a control that verifies only the declaration is answering the easier of the two questions. Definition pinning closes the metadata half, while the behavioral half needs observation of what the server and the agent actually did, over time, against what was expected.

What does the MCP specification require for authorization?

The specification requires less than most teams assume, and the gaps are deliberate rather than oversights. In the current specification revision, authorization is optional. HTTP-based transports should conform to the OAuth 2.1 profile; stdio transports explicitly should not, and instead retrieve credentials from the environment they run in.

Where the profile is implemented, the requirements are strict and worth knowing because they are testable. A server must validate that an access token was issued for it specifically as the audience, using resource indicators. It must not accept or transit tokens issued for anything else, which closes the token passthrough path where an MCP credential gets forwarded to an upstream API. It must publish protected resource metadata so clients can discover the right authorization server.

Two things follow for anyone governing a fleet of servers. The first is that “it uses OAuth” is not an answer to the audience-binding question, and the audience-binding question is the one that determines whether a token stolen from one server is useful against another. The second is that a local server has no token story at all: it inherits whatever credentials sit in its environment, which is usually the developer’s, with the developer’s scope.

What’s the difference between a local and a remote MCP server in security terms?

They fail differently, and conflating them is how assessments go wrong.

A local stdio server has no listening endpoint, which removes a whole class of network exposure. In exchange, it is a process running with the user’s privileges, and the protocol does nothing to constrain its access to the file system, the network or stored credentials. Installing one is executing code on an endpoint, and OWASP is blunt that sandboxing is required and that a bare chroot is not sufficient.

A remote server is a network service, so it needs the controls any network service needs: TLS with verified server identity, validated Origin and Host headers, rate limiting, and binding to localhost where it is only meant to be reached locally. It also introduces a direction of risk that gets less attention than it deserves, because a remote server receives whatever the agent sends it, which may include the contents of the context that prompted the call. The question therefore extends beyond whether you trust a server’s outputs to whether you are comfortable with what your agents send it.

What are the main MCP server risk classes?

Risk	What it is	What actually addresses it
Tool poisoning	Instructions hidden in tool descriptions, parameter schemas or return values	Treat the full schema as untrusted input; strict schemas; scan definitions, don’t read names
Rug pull	Definitions change after approval	Pin a hash of the complete definition and re-verify before execution – plus behavioral observation, which pinning does not cover
Confused deputy	The server acts with its own broad privileges rather than the requesting user’s	Per-server credentials, least privilege per tool, authorization enforced in code rather than by the model
Token passthrough	An MCP token is forwarded to an upstream API	Audience-bind every token to the server it was issued for; never transit tokens
Local execution scope	A stdio server runs with the user’s full privileges	Sandboxing, restricted file and network access, separation of sensitive servers
Outbound exposure	The server receives context the agent sends with a call	Treat each server as a data recipient and scope what reaches it
Unknown servers	Servers connected outside any approval path	Discovery that reads agent configuration rather than relying on a registry

The last row is the one that determines whether any of the others are actionable, and it is the row most assessments assume away, because controls applied to the servers you know about say nothing about the ones you do not. A British bank customer had already surveyed its employees and deployed MCP gateways for its developers, and still had significantly more tool connections than either effort had captured.

How do you assess an MCP server, and how often?

Before approval, four things are worth establishing, and all four are answerable: what the complete tool schema contains rather than what the tool names suggest; whether the server runs locally with the user’s privileges or remotely under its own identity; what credentials it holds and whether tokens are audience-bound to it; and what data reaches it as a consequence of ordinary use.

After approval, the question changes from what the server is to whether it is still that. That is a continuous question rather than a periodic one, because the interval between reviews is exactly the window a rug pull operates in. Definition pinning gives you a cheap continuous check on the declared interface, while behavior gives you the other half, which is the half that catches a server whose paperwork never changed.

There is one honest limitation, which is that permission granularity below the server level – allowing a server’s read tools while blocking its write tools – is uneven across the ecosystem and frequently unavailable, so an allow decision is often coarser than a security team would like. That is a real constraint on what server-level approval can achieve, and a reason why controls that operate at the point the agent acts, rather than at the point the server is approved, cover ground that approval cannot.