Using MCP build? Beware of security vulnerabilities

Inherent security flaws are raising   questions about the safety of AI systems built on the Model Context Protocol (MCP) ^{[2] .}

MCP ^[3] , developed  by  Anthropic ^[4]  , is an open source specification for connecting AI agents based on large language models with external data sources (called MCP servers).

As  the first proposed industry standard for agent-to-API communication ^[5]  , interest in MCP has surged in recent months, leading to a proliferation of MCP servers.

In recent weeks, developers have raised the alarm that MCP lacks default authentication and is insecure out of the box — some say it is a  security nightmare . ^[6]

Recent research from Invariant Labs ^[7]  shows that MCP servers are vulnerable to tool poisoning attacks, in which an untrusted server embeds hidden instructions into tool descriptions.

According to Invariant Labs, Anthropic, OpenAI, Cursor, Zapier, and other MCP clients are vulnerable to this type of attack, and Invariant Labs demonstrated how to  leak WhatsApp chat logs ^[8] .

Luca Beurer-Kellner , co-founder and CTO of Invariant Labs  ^[9]  , told The New Stack, “MCP itself is generally not a security issue because the underlying vulnerability is actually a problem with the model.”

He added: “At the same time, MCP adoption is driving more and more users to connect LLM systems to sensitive data sources and tools, making the security challenges of AI, and especially agent AI, even more important.”

MCP safety issues 'very real'

MCP has been described as the “ USB-C port for AI ” ^[10] . According to  MCP.so ^[11]  , there are over 8,000 MCP servers in operation.

Sam Altman of OpenAI  ^[12]  recently  committed to adopting MCP ^[13]  for their platform. Early adopters like  Digidop ^[14]  have reported a 55% reduction in development time and complexity.

However, rapid progress can overlook security risks.  A recent study ^[15] by API security company Equixly  found that 43% of MCP servers contained command injection vulnerabilities.

Kevin Swiber ^[16], API strategist at Layered Systems,  shared on LinkedIn ^[17]  that “security concerns are very real.” 

Researchers have identified several key risks associated with MCP systems:

• • Tool poisoning.
• • Rug pulls (where a trusted server changes the tool to become malicious after obtaining approval from the client).
• • Tool shadowing (one server changing the behavior of another server).
• • Remote Command Execution (when an attacker runs a system command).

Mitigation strategies include:

• • Scan the MCP server for vulnerabilities.
• • Implement identity authentication.
• • Use a trusted identity provider.
• • Apply least privilege scope to tool access.

Deep dive into the MCP vulnerability

Tool poisoning attacks are a type of indirect prompt injection that can be used to hijack behavior in MCP-based systems. This could expose sensitive secrets such as SSH keys, or trigger unauthorized actions through other connected tools.

This risk stems from a core architectural issue: an untrusted MCP server can embed hidden instructions into tool descriptions that the AI ​​model will process but are generally invisible to users.

"The fundamental problem is that the proxy system exposes descriptions of all connected servers and their instrumentation, which allows a rug-pulled or malicious server to inject information about the proxy's behavior regarding other servers," the Invariant Labs report said.

Swiber told The New Stack, “A malicious actor could masquerade as a dispatch agent, when in reality all it is doing is eavesdropping on private communications to launch sophisticated phishing attacks. The risks range from basic privacy issues to advanced data breaches.” Invariant Labs found that the malware package could be modified after installation to include untrusted code, a known supply chain risk.

“MCP Server is subject to the same supply chain risks as any third-party software package,” an Anthropic spokesperson told The New Stack. “We recommend that organizations continue to follow security best practices when using third-party software packages.”

A DevOps researcher also highlighted ^[18]  cross-server tool shadowing and command injection vulnerabilities in the MCP system.

Be careful with local MCP servers

MCP servers are generally divided into two categories: remote and local. The most pressing issues revolve around local MCP servers.

Alessio Dalla Piazza ^[19] , co-founder and CTO of Equixly,   told The New Stack: “MCP servers present several security challenges by design that developers must proactively address to ensure robust and secure communications.”

Swiber noted that remote MCP servers are still evolving in terms of authorization and transport protocols. As a result, developers are increasingly turning to local MCP servers, which are more clearly defined in the current specification.

The downside is that local MCP servers pose a higher security risk because they often pull unvetted third-party packages from public registries like npm or PyPI, greatly increasing the likelihood of introducing malicious code.

"The local MCP server runs on the user's operating system, often with the same permissions as the user," Swiber added. "This opens a window for malicious actors."

Therefore, be careful with local MCP servers. Erik Wilde ^[20]  , principal consultant at INNOQ, shared on LinkedIn ^[21] : “You probably shouldn’t blindly download and use MCP servers, as their behavior could compromise your data source.”

Developers should also ensure that they don't inadvertently access unsafe functionality, Piazza added. This includes the ability to read or write unprotected files, execute system commands, or fetch remote resources.

If the MCP server does not properly authenticate or display the tool description, it may be compromised. Invariant's Beurer-Kellner recommends using  a tool such as mcp-scan ^[22]  to verify that the server being used is secure.

“We are currently working with the community to establish standardized registries for MCP servers,” said an Anthropic spokesperson. “These registries will provide essential metadata about server implementations, enabling users to make informed decisions about which servers to support and integrate with.”

Securing MCP: Authentication, Authorization, Abstraction

When it comes to LLM tool security, tool poisoning is just the tip of the iceberg.

“Many popular proxy systems lack proper safeguards and behavioral assurances, which makes it very risky to connect them to sensitive tools and data,” Beurer-Kellner said. “Even the best LLMs available today are still susceptible to injection and can be easily hijacked.”

Implementing proper authentication is important. Going forward, Piazza hopes that MCP will include built-in security measures, such as standardized authentication by default and sandboxing.

“Until then, developers need to be careful to not only be aware of the intended use of LLM, but also of potential malicious interactions, ensuring their MCP implementations are secure, authenticated, and validated,” he said.

For remotely exposed MCP servers, their security really depends on the underlying API best practices that developers have implemented.

Swiber urges teams building MCP servers that interface with backend APIs to assess  the OWASP Top 10 API Security Risks ^[23] . They add that proper authorization, setting small scopes, rate limiting, and secure token storage are key activities.

Piazza said that API security measures should provide some protection: "If the underlying API is already secured, then exposing it through MCP by adding another layer of abstraction should not introduce additional risk."

However, Matt DeBergalis ^[24]  ,  CTO and co-founder of Apollo GraphQL ^[25]  , believes that this abstraction layer must be carefully considered. “AI agents cannot connect directly to production APIs — it’s a security and governance nightmare,” DeBergalist told The New Stack.

He added: “There needs to be an abstraction layer to enforce policy, handle authentication, manage rate limits, and decouple the rapid iteration of AI systems from existing services.” Finally, there’s the issue of identity and access management. As designed, MCP places a significant implementation burden on users.

Rather than requiring each MCP to handle authentication and authorization itself, it   is better to treat the MCP server as an OAuth resource server ^[27] and delegate difficult tasks such as token issuance to the identity provider, as Aaron Parecki, Director of Identity Standards at Okta, suggested in a blog post ^{[26 ].}

"The MCP authentication specification is still a work in progress," said a spokesperson for Anthropic. "We are actively evolving it to better align with enterprise security requirements and existing authentication systems."

A little objection

In their rush to embrace MCP, companies should not abandon their usual procedures for providing reliable APIs.

API Evangelist  Kin Lane ^[28]  told The New Stack: “Over the past decade, enterprises have been using HTTP APIs in earnest to define and expose the digital resources and functionality that exist in their databases, files, and other systems for consumption by multiple internal, partner, and public applications for a variety of business reasons.”

“You won’t find these commercial reasons in the current debate around MCP because they are being circumvented in order to get your data to train their models while convincing you that they will connect all the dots.”

While MCP appears to be taking off, as with any technology that gains hype at lightning speed, a little dissent can be beneficial.

An invitation to participate in shaping MCP

Agentic AI ^[29] , as well as MCP, are in their early stages. As it becomes more used, new threat vectors are likely to emerge. “Agentic security is actually a very hard problem to solve,” Beurer-Kellner said, adding that “the complexity of agent systems is about to explode and will continue to give rise to new security threats.”

Anthropic expects the protocol to improve over time, and cites upcoming improvements such as a standardized registry for MCP servers, simpler versioning, and authentication add-ons. The company also invites community involvement.

As an Anthropic spokesperson told The New Stack: “We continue to invite the community to actively participate in shaping MCP. We encourage people to follow the discussions on GitHub — you can contribute ideas, report issues, and propose changes to the specification.”

Swiber is curious but cautious: “This is an exciting area and I look forward to seeing these standards mature with enterprise-grade security.”

However, they acknowledged that "this technology is still in its early stages."