The MCP Security Problem Nobody's Talking About

Published March 28, 2026

17,000+ MCP servers deployed. 118 known vulnerabilities found across the ecosystem. And most agent developers have no idea their agents are passing raw PII directly to tool servers with zero filtering. For a running tally of recent CVEs, see our MCP CVE surge review.

How MCP Server Security Breaks

The Model Context Protocol (MCP) is becoming the standard way AI agents talk to tools. An agent needs to check a calendar? MCP. Send an email? MCP. Query a database? MCP.

The protocol itself is well-designed for interoperability. The MCP server security problem isn't in the protocol — it's in the gap between the agent and the tool.

Here's what happens when an agent calls a tool through MCP today:

A user sends a message containing their name, email, and account number
The agent processes the message and decides to call a tool
The agent passes the raw user data directly to the tool server via MCP
The tool server processes it — maybe logs it, maybe sends it to a third-party API, maybe stores it in a database
None of this is audited, filtered, or governed

The agent never needed the real email. It never needed the real account number. But it got them anyway because nothing sat between the agent and the tool to strip that data out. This is the same class of failure as the Azure MCP no-auth CVE and the litellm supply-chain attack — trust is assumed, never verified.

The Three MCP Server Security Gaps

1. PII Leakage Through Tool Calls

Every piece of personal data in a user's message flows through to every tool the agent calls. Names, emails, phone numbers, medical information, financial data — all of it passes through MCP in plaintext. If any tool server is compromised, misconfigured, or simply logging too much, that data is exposed.

2. Prompt Injection via Tool Responses

MCP tools return data that goes back into the agent's context. A malicious or compromised tool can return data containing prompt injection payloads — instructions that override the agent's behavior. The agent trusts tool responses by default.

3. Uncontrolled Tool Access

Most MCP deployments give agents access to every tool on the server. There's no per-tool policy, no write-action approval, no rate limiting at the tool level. An agent that should only read calendar events can also delete them. This is precisely the surface area that shadow agents exploit.

The Fix: Put a Proxy in the Middle

The solution is architecturally simple: insert a proxy between the agent and the MCP tool server that:

Tokenizes PII before it crosses the boundary. Names become [VS:PERSON:a3f2]. Emails become [VS:EMAIL:b7c1]. The tool works with tokens. The real data stays encrypted.
Scans tool responses for injection patterns before they re-enter the agent's context.
Enforces tool policies — whitelist which tools the agent can call, require approval for write actions, rate limit expensive operations.
Logs everything in an immutable audit trail.

The agent doesn't know the proxy is there. The tool server doesn't know the proxy is there. One line of configuration:

{
  "mcpServers": {
    "my-tools": {
      "command": "guard-proxy",
      "args": ["--target", "my-real-server"],
      "env": { "VERISWARM_API_KEY": "vs_..." }
    }
  }
}

Why MCP Server Security Matters Now

MCP adoption is accelerating. Claude Desktop, Cursor, and dozens of other clients support it natively. The number of MCP servers will double in the next quarter.

Every one of those servers is a potential data leak, injection vector, or compliance violation. With EU AI Act enforcement on August 2, 2026, the organizations that put a governance layer between their agents and their tools now will avoid the incidents that make headlines — and the fines — later.