The MCP Security Problem Nobody's Talking About

Published March 28, 2026

17,000+ MCP servers deployed. 118 known vulnerabilities found. And most agent developers have no idea their agents are passing raw PII directly to tool servers with zero filtering.

How MCP Works (and Where It Breaks)

The Model Context Protocol 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 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:

1. A user sends a message containing their name, email, and account number
2. The agent processes the message and decides to call a tool
3. The agent passes the raw user data directly to the tool server via MCP
4. The tool server processes it — maybe logs it, maybe sends it to a third-party API, maybe stores it in a database
5. 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.

The Three MCP Security Gaps

1. PII Leakage

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.

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 This 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. The organizations that put a governance layer between their agents and their tools now will avoid the incidents that make headlines later.

Try Guard Proxy free →

---

VeriSwarm Guard Proxy intercepts MCP tool calls for PII tokenization, injection scanning, and policy enforcement. Free tier available.