Home

Published

- 9 min read

MCP Security (Part 1)

By William OGOU
llm security ai agent mcp security security mcp ai
img of MCP Security (Part 1)

The Artificial Intelligence landscape is evolving at breakneck speed, and Large Language Models (LLMs) are rapidly moving beyond simple chat interfaces. Enter the Model Context Protocol (MCP), an emerging open-source standard championed by Anthropic and gaining significant traction. Heralded as the “USB-C for AI applications,” MCP promises a universal way to connect LLMs to external data sources and tools, unlocking powerful new capabilities for agentic AI.

Imagine AI seamlessly interacting with your file systems, databases, APIs, and SaaS applications. While this integration sparks excitement among AI developers, offering unprecedented standardization and power, it simultaneously throws open Pandora’s Box of security concerns. As MCP adoption accelerates, are we inadvertently building a new generation of vulnerable AI systems?

This is Part 1 of our deep dive into MCP Security, exploring what it is and the fundamental risks baked into its design.

What is Model Context Protocol (MCP)? The Promise of Universal AI Connectivity

At its heart, Model Context Protocol (MCP)aims to solve a critical challenge: how can LLMs reliably and consistently interact with the world outside their training data? Created by Anthropic, this open-source standard defines a universal method for LLMs to:

  1. Discover available resources: Detect what external data sources (files, databases, console logs) and tools (actions like retrieving file content, sending emails, interacting with APIs) are available.
  2. Understand context: Know when and why using these external resources would enhance the task it’s working on.
  3. Interact deterministically: Request specific data or actions needed to answer questions or complete tasks that require information beyond its internal knowledge.

MCP achieves this through a client/server architecture, typically involving three components:

  • Host Application: The orchestrator (e.g., Claude Desktop, IDE plugins like Cursor, Continue) managing interactions between the LLM and various MCP clients.
  • MCP Client: An interface within the host application responsible for the one-to-one communication link with a specific MCP server.
  • MCP Server: A backend service or small application implementing the MCP specification. It communicates with the client (often via JSON-RPC over STDIO locally or Server-Sent Events (SSE) over HTTP/S remotely) and exposes specific capabilities to the LLM via the client.

These capabilities generally fall into three categories:

  • Resources: Data stores the LLM can reference (e.g., file contents, database schemas, logs loaded at chat initiation).
  • Tools: Actions the LLM can request the server to perform (e.g., read a specific file, call an API, insert data into a database, send an email).
  • Prompts: Reusable, potentially templated prompts the server can provide to the client, often accessible via quick lists in the host application.

The allure is undeniable: write an MCP server integration once (e.g., for accessing Salesforce data), and potentially use it across any LLM and host application that supports MCP. This standardization is driving rapid interest and the emergence of MCP server “marketplaces.” But does this convenience come at a steep security price?

Inherent Security Weaknesses in MCP

While MCP’s functional goals are compelling, security researchers are sounding alarms about fundamental weaknesses, some baked into the protocol’s design and others arising from its current stage of maturity. It appears MCP was designed primarily for functionality, potentially overlooking critical secure-by-design principles, leading to risks reminiscent of early web application security challenges.

Trust as a Fragile Foundation

MCP operates on a significant degree of implicit trust:

  • Trust in the Host: Users must trust the host application to correctly control access between the LLM and various MCP clients/servers.
  • Trust in Transport: Users trust that clients are using adequately secured communication channels (like HTTPS with proper validation for remote SSE) with servers.
  • Trust in the Server: Users must trust that the MCP server itself implements secure practices when accessing underlying resources (files, APIs, etc.) and doesn’t harbor vulnerabilities.

This reliance on trust, especially with a growing ecosystem of third-party servers, creates a precarious situation. As Tenable’s research highlights, users should “trust but verify” and avoid installing unknown MCP servers.

Missing Secure-by-Design Fundamentals

Troublingly, the MCP specification itself exhibits security anti-patterns:

  • Session IDs in URLs: Research points out that the protocol specification suggests using session identifiers directly in URLs (e.g., GET /messages/?sessionId=UUID). This fundamentally violates security best practices, potentially exposing sensitive session IDs in logs (browser, server, proxy) and making sessions vulnerable to hijacking if intercepted.
  • Lack of Authentication Standards: While recommending authentication for remote servers, MCP doesn’t require it or standardize how it should be implemented. This leads to inconsistent, often weak or entirely absent, authentication mechanisms in practice, leaving servers exposed, no authentication by default.
  • Missing Integrity Controls: The protocol lacks built-in requirements for message signing or verification. This absence allows for potential message tampering between the client and server, enabling attackers to modify requests or responses undetected.

The Perils of Persistent Context

MCP facilitates persistent context sessions, allowing instructions and memory to span multiple interactions:

  • Context Leakage: Long-lived sessions increase the risk of accidentally retaining sensitive user data (passwords, PII, proprietary info) longer than intended. If context isn’t properly cleared or is inadvertently exposed (via API misuse or logs), it can be extracted by malicious prompts or actors.
  • Memory Poisoning / Context Corruption: Attackers could potentially introduce false or malicious context data into a persistent session, poisoning the LLM’s “memory” over time. This could lead to the model generating misinformation or exhibiting biased outputs based on corrupted context instructions.

New Attack Vectors Emerge

The way MCP structures interactions introduces specific threats:

  • Prompt Injection Vulnerabilities: MCP’s structured prompts provide a direct interface that malicious actors can target. Attackers might craft inputs designed to inject hidden instructions, overwriting the system’s intended behavior, bypassing moderation filters, or hijacking the model to perform unintended actions.
  • Replay and Session Hijacking: Without robust session authentication and validation (often lacking, as noted above), attackers might reuse stolen context tokens or hijack active model sessions, enabling them to impersonate legitimate users or force the model to respond based on compromised context.
  • Metadata Exposure: Context protocols inherently carry metadata about user sessions. If exposed, this metadata could reveal user identities, interaction patterns, or sensitive system-level instructions.

The Expanded Attack Surface: Beyond the LLM

A critical point often overlooked, is that MCP servers can be called by anyone, not just the LLM via the host application. While LLM interactions often involve “plan” and “act” phases providing some transparency, a direct attacker faces no such constraints.

Many developers, focusing solely on the LLM integration, may not have adequately secured the MCP server endpoints against direct malicious calls, creating a significantly expanded and often poorly protected attack surface.

Initial Findings: A Regression in Security?

Preliminary security research into popular MCP server implementations paints a concerning picture. Findings reveal a high prevalence of fundamental vulnerabilities:

  • Command Injection: Found in 43% of tested implementations.
  • Path Traversal / Arbitrary File Read: Found in 22%.
  • Server-Side Request Forgery (SSRF): Found in 30%.

The resurgence of these “classic” web vulnerabilities in cutting-edge AI technology suggests a potential regression in security practices, where rapid development outpaces security maturity. Compounding this is a reported lack of urgency from some developers when notified, with many dismissing risks as “theoretical” or failing to respond. This indicates a dangerous gap in understanding the real-world implications of these flaws within the MCP ecosystem.

Conclusion (Part 1): A Powerful Tool Requiring Immediate Cautionications of these flaws within the MCP ecosystem.

Model Context Protocol represents a significant advancement, standardizing how LLMs connect to the world and paving the way for truly powerful agentic AI applications. However, its rapid rise is built upon a foundation with concerning security weaknesses, both inherent in the protocol’s current design and evident in early implementations.

The heavy reliance on trust, lack of mandatory security controls like robust authentication and integrity checks, risks associated with persistent context, and the expanded attack surface demand immediate attention.ion with concerning security weaknesses, both inherent in the protocol’s current design and evident in early implementations.

Organizations rushing to implement MCP servers must carefully consider these security implications before deployment. Standardization efforts need to prioritize security alongside functionality to avoid creating a new generation of vulnerable AI systems.

In Part 2, we will delve deeper into specific attack scenarios and explore recommended mitigation strategies for developers and organizations navigating the complexities of MCP Security.

To further enhance your AI security posture, contact me on LinkedIn Profile or [email protected].

(Content of MCP Security Part 1 - Consider adding a link to the Google Cloud Next recap if it discusses MCP: Google Cloud Next ‘25 : Security and AI Recap)

Frequently Asked Questions (FAQ)

What is Model Context Protocol (MCP)?

MCP is an open-source standard, initiated by Anthropic, designed to provide a universal way for Large Language Models (LLMs) to interact with external data sources (like files, databases, APIs) and tools (actions like sending emails or retrieving web content).

Why is MCP security a concern?

MCP security is a concern because the protocol, in its current state, lacks strong built-in security requirements (like mandatory authentication or message integrity), relies heavily on trust, introduces risks via persistent context (leakage, poisoning), and creates new attack vectors (prompt injection, session hijacking). Early implementations are already showing high rates of basic vulnerabilities.

What are the main security risks associated with using MCP?

The main risks include: unauthorized access to data/tools via insecure servers, command injection or SSRF vulnerabilities in MCP server implementations, sensitive data leakage from persistent context, model manipulation via prompt injection, session hijacking due to weak session management, and exposure of the MCP server to direct attacks beyond the LLM interface.

Is it safe to use MCP servers?

Yes, but using MCP servers requires quite caution. Safety depends heavily on trusting the host application, the security of the transport layer, and crucially, the security practices implemented within the MCP server itself. Users should only use servers from reputable sources, verify their security posture, and implement strong controls in their environment.

Who created Model Context Protocol (MCP)?

Model Context Protocol (MCP) was created and open-sourced by the AI company Anthropic.

Resources