Table of contents
The hidden security threats of MCP—and how to mitigate them
.png)
The Model Context Protocol (MCP) offers an incredibly powerful way to integrate your LLM with outside data sources, but you’ll need to take certain security measures when using it.
Otherwise, you risk leaking sensitive information on your business, your customers’ businesses, and—if you’re implementing customer-facing integrations—your end users.
Here are some of the biggest security threats to consider and how you can address them.
{{this-blog-only-cta}}
Prompt injection threats
If your customers use API keys to authenticate with your MCP server, they’re trusting you—the MCP provider—to keep these credentials safely stored and away from malicious actors.
Unfortunately, you can easily break their trust.
Researchers at Cornell found that Malicious actors can find ways to use inputs—such as a document with instructions—that coerce you LLM to provide authentication credentials.
For example, a user can include a document in an input that asks your LLM to provide an API key to another server that they control. Since your LLM likely isn’t trained for this scenario and doesn’t understand the intent behind the ask, your LLM would go on to add the API key in the other server.
https://www.merge.dev/blog/how-to-build-mcp-server?blog-related=image
Comprehensive API scopes
Since MCP is so flexible, you’ll likely want to expose as many tools (which correspond to API endpoints) as possible.
This’ll lead you to support keys that access a wide range of sensitive data across applications, whether that's social security numbers, business financials, customers’ payment information, and so on.
This will only up the stakes of a key interception.
A single point of failure
MCP servers might store API keys in a single place. This gives an attacker a single target to access API keys that—as our previous section touched on—support multiple services.
For instance, if you’re using MCP to support internal integrations, you now have a single service that exposes data and functionality for multiple services, like a CRM (e.g., Salesforce), a marketing automation platform (e.g., HubSpot), and a ticketing solution (e.g., Zendesk). This means that if the agent or server is successfully attacked, data from all of the applications can be exposed.

Scenarios like these would be extremely difficult to address, and even if they are, they’d cause long-term damage to your company’s reputation both internally and externally.
https://www.merge.dev/blog/mcp-best-practices?blog-related=image
Poorly-documented tools
If your MCP server’s tools aren’t descriptive or use names that don’t accurately describe their functions, your LLM can easily choose the wrong tool from a given input and potentially invoke a tool that reveals sensitive information.
For instance, if a user wants to get an update on a ticket related to onboarding a specific customer from their project management system, the LLM can mistakenly share another ticket that includes information on a new hire—such as sensitive details from the new hire’s collected documents.

https://www.merge.dev/blog/api-vs-mcp?blog-related=image
How to address these security threats
When you put all of this together, the security threats associated with MCP only grow in severity and likelihood.
For example, if an MCP server stores a few comprehensive API keys in a single place, a significant amount of sensitive information is more vulnerable to exposure. And if you consider the different attack vectors—from prompt injections to indirect access via unsecure connections—your chances of getting breached will be higher.
Fortunately, you can use Merge MCP to avoid these security issues altogether.
Our MCP server lets your LLM access 220+ CRM, HRIS, ATS, ERP, file storage, and ticketing integrations across your customer base.

Merge MCP also offers enterprise-grade secure integrations by providing advanced authentication support (e.g., OAuth 2.0), fully-searchable and comprehensive logs, encryption in transit and at rest, granular data access controls, and more.
{{this-blog-only-cta}}