What is the Model Context Protocol and what are its security risks?

What Is MCP?

Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools.

It was originally popularized as an open source framework by Anthropic in November 2024.

Model Context Protocol has become the de facto standard for enabling communication across a growing ecosystem of artificial intelligence driven services.

MCP is now found in both experimental and production AI deployments across multiple industries, such as business, finance, legal, and software development.

How Does MCP Work?

The MCP Host is the environment where the LLM runs, including an AI-powered IDE or a conversational interface embedded into a product.

The MCP Client is a component inside the host that handles protocol communication, discovering servers and requesting metadata about available capabilities.

The MCP Server is the external service that provides context and capabilities and can access internal data sources, SaaS platforms, specialized security tooling, or proprietary workflows.

Underneath these roles, the inner data layer is based on the JSON-RPC protocol and handles client-server communication.

Why Did MCP Security Lag Behind Adoption?

MCP's rapid proliferation has outpaced the development of its security model.

Critically, the protocol reverses a familiar interaction pattern: instead of clients requesting data from servers, MCP often expects servers to query and sometimes execute actions for the connected clients.

This inversion creates new and largely not well-traced attack paths.

These theoretical risks have now been made concrete, as public labs and security researchers released vulnerable MCP server implementations to illustrate how easily insufficiently secured MCP can be exploited.

The protocol's own specification acknowledges that while MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD build robust consent and authorization flows.

What Are the Core Security Risks in MCP?

Access control is weak by default: associating a session to an identity is not defined by the protocol, but optionally achieved at the discretion of the implementor.

Many implementations omit authentication entirely, and those that do include it often lack any role-based enforcement.

MCP currently lacks support for exchanging Role Based Access Control permissions at instantiation, making it difficult to enforce or verify access boundaries between tasks or services.

Serialized content such as context or prompts can open a path for injection techniques because it can include executable code or embedded model calls.

This is especially problematic if deserialization occurs in a permissive way without strong isolation between code and other text.

Approval workflows can also drift silently, since a previously benign and approved AI service could later access sensitive resources on demand, without triggering any review.

On token and session security, authorization in MCP is optional, meaning not every implementation uses it.

In the event of session hijacking, a malicious actor can impersonate a legitimate client, inject malicious prompts, or interact with MCP servers without detection.

Attackers can also exploit MCP proxy servers that connect to third-party APIs, creating a confused deputy problem.

This attack allows malicious clients to obtain authorization codes without proper user consent by exploiting the combination of static client IDs, dynamic client registration, and consent cookies.

A related anti-pattern is token passthrough, which is an anti-pattern where an MCP server accepts tokens from an MCP client without validating that the tokens were properly issued to it.

When a server accepts tokens it should not, it may accept tokens originally issued for other services, breaking a fundamental OAuth security boundary and allowing attackers to reuse legitimate tokens across different services than intended.

Local MCP servers carry their own risks, because local servers can be powerful, and that power cuts both ways.

Those risks include running untrusted code, unsafe startup behavior, and exposing a local service in a way that another site or process can reach it.

Overly broad permission scopes increase blast radius and weaken governance.

Finally, MCP servers often lack task or data isolation, creating opportunities for inadvertent data exposure.

What Attack Patterns Have Security Researchers Documented?

Some MCP implementations allow malicious actor-controlled inputs to reach execution environments without appropriate constraints, creating vulnerabilities generally considered high severity.

One such class of vulnerabilities is Arbitrary Code Execution, which can easily arise in MCP environments where user provided logic or code is executed.

How Should Security Leaders Secure MCP Deployments?

These design tendencies suggest that secure-by-default behavior must be enforced through rigorous implementation practices.

Organizations need to apply supply-chain controls, scan code and dependencies, pin versions, and review changes before release.

Teams should also work to harden endpoints with strong authentication and authorization, rate limits, and secure defaults.

For proxy deployments, operators should follow the secure pattern where a server acts on behalf of the user with explicit consent and least-privilege scopes, not with a blanket service identity.

What Comes Next for MCP Security?

Guidance in this area is intended to reduce risk while supporting safe innovation in AI-augmented systems, offering practical recommendations for organizations adopting MCP in high-stakes or production environments.

Such guidance is designed to be extensible and remain relevant as the protocol, implementations, and operations continue to evolve.

The MCP specification itself continues to be updated with dated releases and complementary documents such as its security best practices guide, which complements the MCP Authorization specification.