MCP Server Security: 10 Protocol-Level Attack Scenarios Behind the “Install and Run” Speed

Installing an MCP server is starting to look and feel like installing a browser extension: quick, convenient, and increasingly normalized across AI developer workflows. But there’s a question most teams don’t ask early enough: what if the MCP server itself is malicious—or becomes malicious later? That question matters because MCP servers aren’t “just integrations.” They can expose tools and resources that operate with real privileges, and the protocol-level trust model can be abused if you treat third-party servers as inherently safe.

What is an MCP Server?

MCP (Model Context Protocol) is a standard that lets AI applications connect to external tools and data sources through a consistent client–server interface. An MCP server is the component that exposes those capabilities—tools (actions), resources (data), and prompts—so an AI client can discover and use them during a session. That design enables fast “plug-and-play” integrations, but it also means the server can influence what the client believes is safe to call and what the tool “means.”

How does it work in practice?

The client connects to one or more MCP Servers, pulls tool definitions and schemas, and then invokes tools during a session as the model decides what to do next. The security challenge is that tool metadata is not automatically trustworthy: the MCP specification explicitly warns clients to treat tool annotations as untrusted unless they come from a trusted server. If your workflow relies on descriptions, shcema fields, or “helpful” tool text to guide the model, that text can become an attack channel.

Why MCP server security is harder than it looks?

A lot of MCP adoption happens in a “plug it in and see if it Works” mode. That Works for prototyping – but it braks down in production because several safety assumpions aren’t enforced by default:

• Tool descriptions aren’t verified. If your agent relies on descriptive text to decide which tool to call (or how), that text can be an attack channel.
• Schemas aren’t inherently signed/pinned. If schemas drift unexpectedly, your client can be tricked into sending different parameters or calling different tools than intended.
• Servers can change behavior mid-session. Without change control, an MCP server can effectively “switch roles” after being approved-turning trust into a vulnerability.
• OAuth and proxies widen the blast radius. MCP’s security guidance calls out risks like token handling mistakes (e.g., “token passthrough”), confused-deputy scenarios, and unsafe metadata discovery patterns that can lead to serious compromise.

MCP adoption often creates new internet-facing touchpoints faster than security teams can track: a freshly published subdomain for an MCP endpoint, a reverse proxy added “temporarily,” an OAuth redirect endpoint left broadly accessible, or a service that’s exposed with default settings. The problem isn’t only “Which MCP servers do we use?”—it’s “What did MCP change in our external reality?” EASM is built for exactly that: identifying the digital assets related to your organization, running recurring risk scans, and alerting when your attack surface changes. 

From an MCP security standpoint, this turns into practical wins: you can catch unknown or newly exposed assets tied to MCP usage, prioritize remediation when misconfigurations appear, and reduce the time window where “plug-and-play” becomes “public-and-abusable.” This is how MCP moves from a developer convenience layer to a governed, continuously monitored part of your external attack surface. 

10 Protocol-level attack patterns to plan for

Even without naming any specific third-party project, the ecosystem has already documented a consistent set of protocol-level abuse patterns. The point isn’t that every server is malicious – the point is that the protocol surface makes these classes of attacks feasible unless you add guardrails.

1. Schema poisoning: Manipulating schema fields to influence tool selection/parameters.
2. Tool poisoning: Weaponizing tool descriptions/outputs to steer the model into risky actions.
3. Rug pull (behavior drift): A server appears safe, then changes tool definitions/behavior after adoption.
4. Cross-server shadowing: A tool in one server mimics or overrides expectations set by another server.
5. Tool name collision/squatting: Using familiar tool names to gain trust and be selected more often.
6. Crendential harvesting: Prompting users/agents to reveal secrets or mishandling token flows.
7. Resource poisoning: Supplying “resources” that embed malicious instructions or unsafe content paths.
8. Exfiltration chains: Combining multiple “normal” tool calls into a data-leak pathway.
9. Denial-of-wallet: Triggering cost-amplifying loops (LLM tokens, API calls, Cloud usage).
10. Permission confusion: Over-broad scopes or unclear user consent leading to unintended privileged actions.

If you want a structured taxonomy to align internal controls and messaging, the OWASP MCP Top 10 is a useful reference point for categorizing risks across the MCP lifecycle.

Real World Signals: CVEs and Supply Chain Incidents

This is not purely hypoyhetical. Reference MCP Componenets and surrounding tooling have already had disclosed vulnerabilities. For example, CVE-2025-53109 in the Filesystem reference server describes unintended file Access via symlinks in affected versions, with an explicit upgrade recommendation. Another example is CVE-2025-49596 in MCP Inspector, where missing authentication between components can lead to remote code execution under certain conditions (With remediation guidance).

More importantly, the ecosystem has seen clear signs of supply-chain abuse. Postmark, an email delivery service, has warned the public about a malicious npm package (“postmark-mcp”) that impersonates them to steal user emails. Multiple independent write-ups covered the same incident and why it matters for MCP adoption: teams are effectively granting high-privilege Access to packages that may bypass traditional vendor risk and asset inventory processes.

A practical security baseline for MCP serves

You don’t need to “ban MCP” to be safe. You need a baseline that separates what a server claims from  what you allow, and that enforces provenance, isolation, change control and monitoring.

Before you install (Provenance + Trust):

• Verify Publisher/maintainer identity, repository lineage, release history and dependency risk.
• Pin versions (no silent auto-upgrades); prefer signed artifacts/attestations where available.
• Define least-privilege scopes for any tokens used by tools.

While it runs (enforcement + containment):

• Sandbox MCP servers (container/VM), restrict filesystem and outbond network (egress) by default.
• Require explicit user approval for high-risk tool categories (write/delete/send/pay/admin).
• Detect and fail-closed on tool/schema drift during a session (re-approval on change).
• Avoid 0Auth anti-patterns like token passthrough; enforce safe authorization flows and storage.

Observe and detect (monitoring):

• Log tool listing/invocation events, permission failures, and anomalous call volumes.
• Alert on high-risk tool usage spikes, repeated failures, or unexpected new tools appearing.
• Track “consent fatigue” patterns (too many prompts leads to blind approval).