MCP Security Threats Explained: The Categories That Matter

The Model Context Protocol made it trivial to give an AI agent access to your databases, APIs, code, and internal tools through one standard interface. It also opened a new attack surface. In early 2026 the Coalition for Secure AI published an MCP security whitepaper mapping roughly a dozen core threat categories and close to 40 distinct threats. This post walks through the ones that matter most in practice — and what actually defends against them.

Why MCP changes the threat model

Before MCP, connecting an AI to a data source meant bespoke, narrow integrations. MCP replaced that with a universal connector — which is the point, and also the risk. A single overprivileged or compromised MCP server can reach customer databases, internal communications, production code, and cloud infrastructure within the same agent session. The blast radius of one bad server is the whole session.

The threat categories worth knowing

1. Tool poisoning. An attacker rewrites an MCP tool’s description so the model misreads what it does. The model thinks it’s calling a search tool; the tool exfiltrates data. Because the model reasons over tool descriptions, the description is an attack vector.

2. Confused deputy. The MCP server runs actions with its own elevated privileges rather than the requesting user’s. A user without admin rights asks for a destructive query; the server, which has admin, complies without checking. (Deep dive: the confused deputy problem.)

3. Overprivileged tokens. Servers store database passwords and API keys in plaintext config files, usually with far broader access than any task needs — full read/write across every table.

4. Prompt injection into tool output. Untrusted data returned by a tool (a row, a document, an email) contains instructions the model then follows. The data channel becomes a command channel.

5. Excessive permissions & scope creep. An agent granted access “just in case” accumulates reach far beyond its job, so a compromise is catastrophic instead of contained.

6. Missing audit trails. When something goes wrong, there’s no attributable, tamper-proof record of what the agent did — 33% of organizations admit they lack evidence-quality trails for AI operations.

The remaining categories — supply-chain risks in third-party servers, credential leakage, insecure transport, unvetted “shadow” MCP servers — all compound these core failures.

What actually defends against them

You don’t need a control for all 40 threats individually. A few structural choices remove most of the blast radius:

  • Read-only by default. A SQL guard that rejects writes and DDL neutralizes confused-deputy writes and destructive prompt injections at once — the destructive path simply doesn’t exist.
  • Scoped, per-connection keys. Kill overprivileged tokens by never handing the agent a raw credential; give it a key mapped to one connection with least-privilege scope.
  • A vetted, governed gateway. Route agents through one audited gateway instead of a sprawl of unvetted servers, so tool descriptions and transport are controlled and every call is logged.

The pragmatic stance

MCP’s risks are real, but they’re not a reason to keep agents away from your data — they’re a reason to put a governed layer between them. The AI2SQL MCP SQL server implements the defenses above: read-only guard, per-connection keys, audit logging, one vetted endpoint. Compare it with rolling your own in AI2SQL gateway vs. a Postgres MCP server.

The teams that get burned aren’t the ones using MCP — they’re the ones using it with a default admin credential and no gateway.