01What MCP is – and why it creates attack surface
The Model Context Protocol connects AI applications to tools, data sources, and APIs through a unified interface; MCP servers act as a bridge, often operating with delegated user permissions. Dynamic tool integration at runtime, implicit trust relationships between components, and shared contexts create attack paths that classic API security does not cover. In addition, the protocol defines neither mandatory access control nor token lifecycle management – secure implementation rests entirely with implementers.
02MCP-specific threats
Key risks include Tool Poisoning (hidden instructions in tool descriptions), Rug Pulls (replacing already-approved tool definitions after the fact), and code injection through model inputs passed on without validation. Token passthrough creates a Confused Deputy risk: the MCP server is abused to perform unauthorized actions with another user's privileges; insecurely stored API keys and OAuth tokens enable credential theft. Real-world incidents – from the exfiltration of private GitHub repositories and leaked WhatsApp messages to the RCE vulnerability CVE-2025-49596 in the MCP Inspector – demonstrate that these attacks work in practice.
03Server-side hardening
The OWASP guide requires OAuth 2.1/OIDC for all remote MCP servers, short-lived and tightly scoped tokens, and schema validation of all inputs and outputs. Users and sessions must be strictly isolated, and tool execution belongs in hardened sandboxes (containers, seccomp/AppArmor) with minimal privileges and a segmented network. Secrets are kept in vaults and must never be accessible to the LLM at any time.
04Client and host protection
Wiz Research recommends deploying only MCP servers from trusted sources and auditing them like privileged software packages before use – auto-installation and auto-run of tools are high-risk patterns. A mature MCP client with approval dialogs, permission management, and human-in-the-loop for critical actions limits the damage from compromised servers. A central MCP-Gateway and Allowlisting on the host consolidate audit logging, guardrails, and policy enforcement at a single control point.
05Detection and operations
All tool and model calls should be logged, including parameters and the identities involved, and integrated into existing SIEM and detection pipelines. The NSA also recommends regularly scanning your own network for unauthenticated, vulnerable, or unapproved MCP servers – since MCP servers can change ports dynamically, periodic scans with differential reports are advisable. In addition, a formal process for tracking MCP-related vulnerabilities (CVEs, vendor advisories) belongs in routine operations.
06Governance and approval process
No tool and no tool change should go into production without a formal approval process: code scanning (SAST), dependency analysis (SCA), and manual security review are mandatory. Signed tool manifests with version pinning safeguard integrity; the advertised functionality of a tool description must be validated against its actual runtime behavior. A well-maintained inventory of all deployed MCP servers and tools, including versions and patch history, accelerates triage and response when new vulnerabilities become known.
