Securing LLM Superpowers: Navigating the Wild West of MCP

Summary

The Model Context Protocol (MCP) is a standardized framework that enables large language models (LLMs) to interact with external tools, APIs, and data sources. While MCP offers powerful integration capabilities across software development, data analysis, automation, and security operations, it also introduces serious security risks. This post provides a technical overview of how MCP works, its architecture, and real-world use cases. From there, we will explore a wide range of known and practical attack vectors, including tool poisoning, session hijacking, cross-server manipulation, and supply chain attacks, highlighting how malicious actors can exploit weaknesses in the ecosystem. The goal is to inform security practitioners, developers, and platform maintainers so they can evaluate and harden their MCP deployments.

• MCP standardizes how LLMs connect to external tools and data sources, enabling seamless, scalable integration without requiring the model to understand each APIs specifics.
• While MCP enhances LLM capabilities across diverse domains, its optional authorization and lack of robust identity verification pose significant security and supply chain risks.
• Known attack vectors in MCP include tool poisoning, rug pulls, cross-server hijacking, and invisible ANSI escape code injections that exploit the trust and user awareness gaps.
• The growing MCP ecosystem needs stronger governance, authentication, and verification standards to prevent impersonation, malicious tool distribution, and session hijacking threats.

What is MCP?

The Model Context Protocol (MCP) is an emerging standard designed to seamlessly connect LLMs to external tools, APIs, and data sources. It provides a universal translation layer that allows LLMs to interact with external systems in a reusable way, without requiring the model to understand the specifics of each API. MCP abstracts this complexity by defining a common protocol for these interactions, ensuring scalability and flexibility for developers. It has gained broad industry backing, including support from OpenAI, Microsoft, Anthropic, and Google.

How MCP Works

MCP relies on a few core components that work together to facilitate these connections:

Host Application

• The central program that initiates and manages the MCP environment (Claude Desktop, Cursor IDE, VSCode, and some browsers too).

MCP Client

• Runs on the host (or built-in) and establishes a 1:1 relationship with MCP servers, acting as a bridge between the host and the external tools. Clients vary significantly in their security posture, with some offering better support for human-in-the-loop workflows and stronger permissions management.

MCP Server

• Provides the actual tools, resources, and prompts that the client accesses. Servers can be local (accessing local files) or remote. Third-parties often develop servers and can introduce significant supply chain risks.

Transports

• Define how data is exchanged between the client and server. The MCP specification supports several transport types:
  
  • Standard Input/Output (Stdio): Ideal for local integrations and CLI tools.
  • Server-Sent Events (SSE): Enables HTTP-based message streaming, making it suitable for web services.
  • Custom transports: Developers can define their own protocols to support unique requirements. SSE is a built-in MCP transport type but is known to have security vulnerabilities, such as DNS rebinding attacks.

Message Flow

1. Initialization: The MCP host reads a configuration file, establishes connections, and sends an initialization request to the MCP server.
2. Capability exchange: The server responds with its capabilities, available tools, and supported transport types.

Message handling: The client and server exchange JSON-RPC messages, enabling real-time tool calls and data exchanges.

MCP interaction flow: Initialization and discovery phase

MCP defines a standard, structured interface between a host application, language model, and a set of external tooling backends exposed via MCP servers. Before an LLM can safely or effectively use these tools, the initialization and discovery phase lays the groundwork for communication, trust, and capability awareness. This process is critical for maintaining correctness, enforcing boundaries, and preventing misuse.

 Application launch and MCP client initialization

When the Host Application starts (e.g., a SaaS platform, productivity suite, or security operations tool), it loads or instantiates an embedded MCP client. This client is responsible for managing:

• Discovery and connection to one or more MCP servers
• Session establishment and version negotiation
• Tool listing, schema retrieval, and response routing
• Execution orchestration and telemetry

The MCP client typically includes configuration for known server endpoints, authentication credentials, or discovery logic (e.g., service registry, hardcoded URLs, or DNS records).

Server handshake and capability negotiation

MCP uses JSON-RPC 2.0, a lightweight remote procedure call protocol encoded in JSON. The handshake begins when the MCP Client sends an initialize request to each server. This message typically looks like:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": {}
    },
    "clientInfo": {
      "name": "example-client",
      "version": "1.0.0"
    }
  }
}

The server responds with:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "logging": {},
      "prompts": {
        "listChanged": true
      },
      "resources": {
        "subscribe": true,
        "listChanged": true
      },
      "tools": {
        "listChanged": true
      }
    },
    "serverInfo": {
      "name": "example-server",
      "version": "1.0.0"
    },
    "instructions": "Optional instructions for the client"
  }
}

This bidirectional capability exchange allows both the client and server to:

• Negotiate protocol versions
• Communicate supported features like streaming, authentication methods, or context-aware tool invocation
• Establish optional constraints (e.g., maximum tool schema size, payload limits)

Tool listing request

After handshake, the client proceeds to enumerate available tools using a listTools, this allows the client (and by extension, the LLM) to learn:

• Tool name: Used internally for execution.
• Natural-language description: Often injected into the LLM context.

Input/output schema: A strict JSON schema defining argument types, constraints, and expected response formats.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}

The server responds with a collection of tools:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "nextCursor": "next-page-cursor"
  }
}

Tool invocation and usage phase

This phase outlines the active sequence of events that occur when a user-initiated query results in the invocation of an external tool via MCP.

• User input initiation: The process begins when a user submits a query or command to the host application. These inputs often hint at the need for enhanced capabilities, like fetching real-time data or processing local files (e.g., “Summarize this document” or “Get weather info for Rome”).
  
• LLM-driven tool selection: The host application, possibly in collaboration with the LLM, interprets the user’s input and identifies the most appropriate tool for the task. The LLM leverages preloaded metadata (provided earlier during tool registration) to match the prompt to the tool’s schema and generate the required input parameters.
  
• Permission handling: In scenarios where a tool’s access may involve sensitive permissions, like reading local files, location access, read email, or incurring costs, the MCP Client (or host app) may prompt the user to confirm execution. However, since the tool descriptions are not verified in MCP, these prompts could be misleading or spoofed.
  
• Tool invocation request: Once any required permissions are granted, the MCP client sends a JSON-RPC command (e.g., invokeTool) to the selected MCP server. This includes the chosen tool identifier and the input parameters determined in the previous step.
  
• Server execution dispatch: The MCP server receives the tool invocation request and delegates it to the corresponding tool process or function handler. This tool might interface with APIs, process data, or access external systems.
  
• Result handling and relay: After the tool completes execution, it sends the output back to the MCP server, which forwards it to the originating MCP client.
  
• Contextual integration and final output: The MCP client passes the tool output to the host application, where it is typically injected into the LLM’s context. The LLM then produces an enriched and coherent final response based on both the original user prompt and the tool output, which is returned to the user.

MCP authorization

MCP includes optional support for authorization at the transport layer, allowing MCP clients to access protected servers on behalf of resource owners. However, because authorization is optional, many MCP servers may operate without access controls. This lack of enforced authentication introduces significant risk, if an MCP server is exposed to the internet or accessible by untrusted clients, it may be vulnerable to misuse, data leakage, or abuse of sensitive tool capabilities.In an MCP authorization flow, a protected MCP server functions as an OAuth resource server. It enforces access control by accepting and responding only to requests that include valid access tokens. The MCP client, acting as an OAuth client, obtains these tokens and issues requests on behalf of the resource owner (typically an host application). An external authorization server is responsible for authenticating the user and issuing the access tokens needed for interaction with the MCP server.

MCP use cases

• Software engineering and development tools

MCP enables integration with development environments and software engineering platforms to automate tasks like code generation, static analysis, documentation lookup, test creation, and code review. This allows LLMs to act as intelligent coding assistants within IDEs or version control systems.

• Data analysis and reporting

LLMs can connect to tools that access and analyze structured or unstructured data, perform aggregations, statistical analysis, generate visualizations, or produce summaries. MCP provides the interface for securely accessing query engines or analytics pipelines.

• Workflow automation and orchestration

By exposing task-based APIs or automation platforms (e.g., task runners, schedulers, cloud functions) via MCP, LLMs can orchestrate multi-step workflows such as onboarding users, provisioning resources, or syncing systems.

• Personal productivity enhancement

Tools related to personal information management (e.g., calendar, email, file storage, notes) can be exposed to LLMs via MCP. The model can then reason over and automate tasks such as summarizing emails, scheduling events, or preparing daily agendas.

• Security operations and incident response

MCP facilitates access to security tools like SIEMs, log analysis engines, or threat intelligence databases. LLMs can then assist with threat hunting, anomaly detection, or summarizing incidents in real time.

• Enterprise knowledge and document retrieval

MCP tools can expose internal document repositories, wiki systems, or knowledge stores. LLMs then use semantic search and summarization to surface relevant content in response to user questions.

• Natural language database interaction

MCP allows tools to map natural language to structured query languages (e.g., SQL, GraphQL) and return results in structured format. The model can then format and present the result conversationally.

• Design and manufacturing systems integration

In technical and industrial settings, MCP tools can interface with design platforms, CAD systems, or resource planning software. LLMs can query system status, generate summaries, or plan actions based on engineering constraints.

• Web application enhancement

LLMs can be connected to live web backends using MCP to dynamically read or update user-facing content, automate page generation, or support real-time content adaptation based on user queries.

• Multi-agent systems and coordination

MCP enables modular tool decomposition where an LLM coordinates among specialized tools or agents. Each tool performs part of the reasoning or execution chain, and the LLM orchestrates the flow.

MCP registers and distribution

MCP servers can be registered in public or private registries to improve discoverability and accelerate integration. However, the MCP ecosystem still lacks robust trust enforcement and verification standards, leaving users vulnerable to typosquatting, server impersonation, and supply-chain attacks.

Known MCP server registries

• smithery.ai: One of the earliest directories for browsing and testing MCP servers.
• glama.ai: Offers a clean server list focused on tools for Claude-based workflows.
• hub.docker.com/u/mcp: Docker Hub namespace for MCP servers, including reference implementations.
• huggingface.co/spaces?filter=mcp-server: Several open-source MCP servers available as HF Spaces.
• mcpindex.net: A curated index of active MCP servers, searchable by category, popularity, and creator.
• mcpserverfinder.com: Offers categorized views like “Model Context Protocol,” and security-related extensions.
• mcpbusiness.com: Oriented toward enterprise integrations, such as Google Workspace or Cloudflare.

Governance and supply chain concerns

Most MCP registries lack:

• Authentication of server identity
• Signature verification or version pinning
• Scanning for common MCP weaknesses

This opens the door to typosquatting, tool impersonation or rug pulls. 

Known and practical attack vectors in the MCP ecosystem

Tool poisoning attacks

Attackers embed hidden instructions within tool descriptions, invisible to users but readable by AI models. These concealed commands can prompt the AI to perform unauthorized actions, such as extracting sensitive data and transmitting it to malicious servers. For instance, a seemingly benign calculator tool might secretly instruct the AI to read confidential files and send their contents to an attacker-controlled endpoint.

Rug pulls: Silent redefinition

After initial approval, MCP tools can alter their definitions without notifying users. This creates a security risk where a tool that initially appears safe can later change its behavior, such as leaking API keys or executing harmful actions, without detection. This technique is not unique to MCP; it is also commonly exploited in other domains, such as browser extensions. For example, the LNKR malware campaign involved malicious updates to seemingly benign extensions, which turned them into adware or spyware after installation.

Cross-server tool shadowing

In environments with multiple servers, a malicious server can intercept or override calls intended for trusted servers. This “confused deputy” scenario enables attackers to manipulate legitimate tools by redirecting their operations through a malicious server, effectively hijacking the tool’s functionality.

ANSI escape code injection

Attackers can use ANSI terminal escape codes to hide malicious instructions in MCP tool descriptions and outputs, making them invisible on the screen while still being processed by the AI model. This technique leverages the line-jumping vulnerability to deceive even security-aware users further. In tests with Claude Code, no filtering or sanitization for tool descriptions containing ANSI escape sequences has been found. This allows attackers to launch supply chain attacks by injecting hidden suggestions to download packages from malicious servers, planting backdoors in dependencies, or manipulating development environments without users noticing.

Session hijacking in multi-server MCP setups

In environments with multiple stateful MCP servers, stolen session IDs can be exploited to inject malicious prompts or impersonate legitimate clients. An attacker can craft events using a hijacked session ID and target a different server that shares a queue or session store. This allows the malicious payload to be delivered to the original client, triggering unintended behavior. If the server does not enforce strict session validation, attackers can also use the stolen ID to make unauthorized tool calls or data access requests, bypassing authentication and gaining control over active sessions.

Typosquatting in public registries

Attackers may register MCP tools or servers with names similar to legitimate ones (e.g., file-summary-tool vs. file-summarizer). Because there is no strict identity verification or signature validation in MCP’s standard, users or applications may unknowingly connect to or authorize malicious tools, especially if using automated discovery or registries with lax trust models.

Tool supply chain attacks

MCP tools often depend on third-party packages or external APIs. Attackers can compromise the supply chain by injecting malicious code into dependencies or hosting malicious versions of common tools on registries. Because MCP lacks signature verification or integrity enforcement, compromised tool packages can be silently pulled and executed by clients, leading to persistent compromise, data exfiltration, or lateral movement within environments.

Conclusion

MCP represents a major advancement in connecting large language models to external tools, enabling powerful new capabilities across many domains. However, as this blog has shown, the MCP ecosystem also introduces significant security and supply chain risks that require urgent attention. From tool poisoning and silent redefinition to cross-server shadowing and session hijacking, attackers have multiple ways to exploit the protocol’s flexibility and limited trust enforcement. 

As MCP adoption grows, organizations and developers must prioritize strong authentication, permission controls, and active monitoring to protect sensitive data and maintain control over AI-driven workflows. This post is the first in a series that will explore these vulnerabilities and defensive strategies in detail.

Understanding how MCP works and its ecosystem is essential for building safer, more reliable AI tooling. Stay tuned for upcoming posts that will dive deeper into MCP attack vectors and best practices for securing this evolving landscape.

If you’d like to learn more in the meantime, please read the blog Beyond LLMs: The Strategic Need for MCP Security.

Final Thought

The flexibility of MCP is a double-edged sword. If treated casually, it becomes an open channel for abuse. But with a layered approach to validation, monitoring, and access control, organizations can deploy MCP securely and confidently, even in hostile environments