MCP security: threats, audit and hardening for the Model Context Protocol

The Model Context Protocol (MCP) is an open protocol that lets an AI application connect to tools and data sources through standardized servers. MCP security means controlling what those servers can do, what they can make the model believe, and which rights they act with. An MCP server is at once executed code, a supplier of text the model reads, and a holder of credentials, and each of those roles is an attack surface.

What is the Model Context Protocol and why does it raise security questions?

MCP standardizes how a client (an assistant, an IDE, an agent) discovers and calls the tools, resources, and prompts a server exposes. It raises security questions because it puts third-party code, third-party text, and credentials side by side, with a language model deciding what to call.

An MCP server exposes tools (functions the model can call), resources (readable data), and prompts (instruction templates). The client passes tool descriptions to the model; the model picks which to call and with what arguments; the client runs the call, possibly after user confirmation. The specification itself recommends that a human be able to deny tool invocations, which shows that approval is a central security barrier.

Servers run either locally (on the user's machine, with the user's rights) or remotely (with OAuth authentication). Either way, they bridge a manipulable model and real systems. That makes MCP a core topic in any agent audit; see our page on AI agent security for the broader frame.

What is the threat model of an MCP deployment?

The MCP threat model rests on three untrusted parties: the content the model reads, the server itself, and the network or machine hosting it. An attacker can go through any of them to trigger actions the user never intended.

Four boundaries deserve scrutiny:

• Between the model and content: any text returned by a tool or resource can carry a prompt injection.
• Between client and server: tool descriptions, schemas, authentication, tokens, transport.
• Between the server and downstream systems: APIs, databases, files, shell, with whatever rights the server holds.
• Between several servers: one server can influence how the model uses the others, because everything converges in the same context.

The OWASP MCP Top 10 project and the OWASP MCP Security Testing Guide organize these risks into categories. The guide contains 79 tests across nineteen families, from discovery to governance by way of authentication, tools, supply chain, and secrets.

What is tool poisoning?

Tool poisoning hides malicious instructions in the description or schema of an MCP tool. The model reads these descriptions as trusted context, while the interface often shows the user only a summary. Invariant Labs described this attack in 2025: a description can tell the model to read a sensitive file or to append data to its calls, without the user noticing.

The attack works because it needs no interaction with the victim at call time: the instruction is present as soon as the tool is loaded. The fields to inspect go beyond the description: parameter names, default values, schemas, and error messages can also carry hostile text. The OWASP test catalog covers these cases under its "Tool Security" and "Prompt and Instruction" families.

What are a rug pull and tool shadowing?

An MCP rug pull is a server that behaves correctly at installation and later changes the description or behavior of its tools, after the user has approved it. Tool shadowing is a malicious server whose tool description influences how the model uses another server's tools, for example by redirecting the recipients of an email sent through a trusted server.

Invariant Labs documented both variants in its tool poisoning alert. The rug pull exploits the lack of integrity checks between the moment of approval and the moment of use. Shadowing exploits the fact that all servers share one context: a server with no direct access to your data can still steer the use of a server that has it. The countermeasures are pinned versions, detection of tool-definition changes, and strict separation of servers by trust level.

What risks come with over-broad OAuth scopes and token passthrough?

Over-broad OAuth scopes give the server, and therefore any attacker who hijacks it, far more rights than the task needs. Token passthrough is an anti-pattern in which an MCP server accepts tokens that were not issued to it and forwards them to a downstream API. The MCP specification explicitly forbids it: a server must accept only tokens issued for itself.

The MCP security best practices guide devotes a section to each risk: confused deputy, token passthrough, SSRF, session hijacking, local server compromise, and scope minimization. For scopes, the rule is to request the minimum at the start, then raise privileges step by step when a specific operation requires it, instead of granting wildcard "full access" up front.

Token passthrough breaks traceability and controls: the downstream API can no longer tell which client actually acted, and a token stolen from the server becomes usable elsewhere. The MCP authorization specification builds on OAuth 2.1 and resource indicators to bind a token to its intended audience.

What is the confused deputy problem in MCP?

A confused deputy arises when an MCP server acts with its own privileges on a user's behalf without checking that the user is entitled to the action. The typical case is a proxy server that uses a static OAuth client ID with a third-party provider: if consent is not requested for each client, an attacker can obtain an authorization code without the victim's knowledge.

The countermeasure in the MCP documentation is to collect explicit user consent for each registered client before forwarding the request to the third-party provider, to validate redirect URIs strictly, and to bind the OAuth state to the session. In an audit, we also check that the rights the server uses are the user's own rather than those of an all-powerful service account.

Why is command injection in MCP servers so common?

Many MCP servers turn model-chosen arguments into system commands, SQL queries, file paths, or HTTP requests. If those arguments are not validated, a prompt injection becomes a command injection, a path traversal, or an SSRF. The model becomes the vehicle that delivers the payload to a classic flaw.

Our threat watch documents this path: see the article on command injection through MCP in LiteLLM and the one on an OAuth flaw in the MCP Python SDK. The test catalog covers parameter validation, path traversal, output rendering, and SSRF protections for tools that make HTTP requests. A server must treat every argument as hostile, even when it comes from the model.

How is the supply chain of MCP servers attacked?

An MCP server installed from a public registry is third-party code run with your rights, so it carries the same risks as any dependency, plus one more: it also earns the model's trust. OWASP covers LLM application supply chain risk in LLM03:2025.

The scenarios to cover are name squatting (typosquatting), a compromised maintainer, an auto-update that introduces malicious code, and servers published without verifiable provenance. Our watch documents a concrete case with the npm worm tied to the postmark-mcp package. The baseline measures are an inventory of approved servers, pinned versions, provenance checks, code review before approval, and disabling silent updates. Our article on auditing an MCP-connected database shows these controls on a practical case.

How do you audit an MCP server?

Auditing an MCP server means walking through its tools, rights, and authentication chain while trying to misuse them in a controlled way. The list below follows the OWASP test guide families, which we mapped to our method; it summarizes the catalog rather than reproducing it.

1. Discovery. Identify servers, enumerate tools, resources, and prompts, map trust boundaries and sensitive context flows.
2. Configuration and deployment. Exposure of a local server (listening on all interfaces), debug mode, verbose errors, file permissions, unencrypted transport.
3. Authentication. Server reachable without authentication, weak tokens, credential reuse across tools, expired or revoked tokens still accepted.
4. Authorization. Excessive tool rights, bypass of user approval, cross-user access, escalation through tool chaining, workspace boundary escape.
5. Tool security. Description poisoning, schema manipulation, unsafe execution, command injection in parameters, dangerous tool chaining, human approval for sensitive tools.
6. Resources and data. Exposure of sensitive resources, enumeration, secret leakage, unauthorized file access.
7. Instructions and context. Direct and indirect prompt injection through resources, memory poisoning, priority given to untrusted context, context over-sharing.
8. Inputs and outputs. Parameter validation, path traversal, unsafe rendering, sensitive data in outputs.
9. Gateway and egress. Destination allowlists, SSRF protection, rate limiting.
10. Secrets. Secrets in configuration and environment, token storage and rotation, redaction in logs.
11. Logging and detection. Traceability of tool calls, approval logs, detection of injection attempts, incident reconstruction.
12. Supply chain and governance. Provenance, vulnerable dependencies, malicious server installation, automatic updates, inventory and registry of approved servers.

The top-priority tests for an agent are those that link the model to an action: approval bypass, description poisoning, dangerous tool chaining, indirect injection, exfiltration through network egress. That is where our Agent Red Team Express concentrates its effort.

How do you audit an MCP client setup?

On the client side, the audit covers what the user or organization has plugged in and the application's safeguards. A poorly configured client cancels out the security of a well-built server.

• Inventory. Which servers are connected, by whom, with which credentials, local or remote?
• Approval. Do tools with side effects ask for a confirmation that shows the real arguments? Is "allow everything" mode disabled?
• Changes. Does the client flag it when a tool description changes after approval?
• Isolation. Do servers of different trust levels share the same context? Can an untrusted server be paired with one that reaches sensitive data?
• Machine rights. Do local servers run in a container or sandbox with minimal rights, rather than with the user's full rights?
• Organization policy. Is there a list of approved servers, a documented exception process, and compliance evidence?

How do you harden an MCP deployment?

Hardening relies on reducing rights, correct authentication, and human control. The measures below follow the MCP best practices guide and our engagements.

• Apply least privilege: one tool, one narrow scope, one separate credential.
• Use OAuth as the specification describes, validate token audience, and refuse any token passthrough.
• Run local servers in a sandbox with restricted file system and network access.
• Validate every parameter on the server side with strict schemas, and filter network egress with an allowlist.
• Require human approval for any irreversible or outbound action, displaying the real arguments.
• Pin versions, verify provenance, and track changes to tool definitions.
• Log calls and approvals without writing secrets into the logs.
• Separate servers by trust level and avoid combining private data, untrusted content, and an outbound channel.

Our upcoming Shield, a software layer between the agent and its tools that will enforce a policy of authorized actions, targets that last point. It is under development and is not available today.

How does CleanIssue audit an MCP scope?

We test MCP servers and clients under real conditions, from untrusted inputs to the actions and data that come out, with replayable evidence. The Agent Red Team Express costs €1,900 for 5 days and covers one agent; a broader MCP scope falls under the Custom Red Team, quoted individually.

First contact is a free 30-minute discovery call. For the method, see our approach and our page on AI agent red teaming. To understand how a hostile instruction reaches your tools, read our page on prompt injection, along with the article on hijacking an agent through a pull request comment and an MCP server.