MCP Security: Best Practices and Avoid Common Pitfalls

The model context protocol (MCP), pioneered by Anthropic, is quickly becoming the go-to standard for connecting large language models (LLMs) to the outside world. 

But the same simplicity that makes MCP so powerful also makes it risky. Spinning up an agent in minutes means handing new code the keys to your environment, and in the rush to build, security often takes a back seat. Then the news started rolling in.

• In May 2025, Invariant Labs disclosed a critical prompt-injection flaw in GitHub’s MCP integration.¹

• Not long after, researchers showed how untrusted MCP servers could hijack workflows, execute arbitrary code, and steal credentials.²

• This was followed by a flaw in Anthropic’s MCP Inspector that enabled remote code execution via an unauthenticated localhost UI.³

That’s where this guide comes in: how MCP can be used securely, highlighting the potential security risks and how to mitigate them.

Why does MCP security breakdown in practice?

While the MCP specification provides important safeguards, such as tool isolation security in operational environments largely depends on how MCP servers are configured and managed.

Common pitfalls of MCP

• Limited controls: Most MCP servers don’t restrict which functions an LLM can call, leading to excessive access. The unofficial Salesforce MCP, for instance, allows unrestricted use without authentication.

• Unverified sources: Connecting to MCP servers from unknown origins is risky, much like installing untrusted software packages.

• API security gaps: Non-stdio MCP setups expose APIs to the internet, requiring standard protections like authentication, authorization, and rate limiting.

• Low visibility: With no built-in monitoring, it’s hard to trace actions back to specific users or prompts, complicating audits and incident response.

• No approval steps: MCP lacks native human-in-the-loop reviews, leaving high-risk actions without oversight.

What does “Secure MCP” mean? (According to Anthropic)

Anthropic designed MCP with security guardrails in mind: isolated tools, explicit user consent prompts, and a local-first approach that avoids sending data off your device unless you approve it. On paper, those protections are strong.

But Anthropic stresses that real security doesn’t stop at the spec (specification: a formal description of how a protocol).

If servers are deployed with root access, exposed ports, or no audit logging, those built-in safeguards won’t save you. It’s the equivalent of putting a lock on your front door while leaving the keys hanging in it.

Here are Anthropic’s recommendations for MCP security:

1. Using OAuth or similar frameworks to enforce scoped consent
   
2. Validating all tokens to prevent bypasses like token passthrough
   
3. Eliminating weak session practices that enable hijacking
   
4. Applying least-privilege principles when deploying servers
   
5. Treating logging and monitoring as essential, not optional

How malicious OAuth proxying works?

Malicious OAuth Proxying works by manipulating the OAuth flow through misleading redirects and exploiting trust between the user, the auth server, and the proxy server.

Let’s break down the attack:

Step 1: The setup (Attacker registers a malicious client)

In this initial step, the attacker registers a malicious OAuth client with the third-party service. 

The client appears to be legitimate but uses a malicious redirect URI (for example, attacker.com). The OAuth service allows this registration because it doesn’t validate the authenticity of the redirect URI. So, anyone can register a valid client.

• Outcome: The attacker has successfully registered a fake client and now has control over the redirect URI to collect sensitive information.

Step 2: Exploiting the consent cookie

Next, the attacker sends a malicious link to the target user. This link references a legitimate client ID (e.g., mcp-proxy) but contains the malicious redirect URI. 

The user, who has previously consented to the mcp-proxy client and granted authorization, clicks the link.

Key exploit: The user’s consent cookie is still valid, which means the OAuth service skips the consent screen, automatically approving the request without prompting the user for new consent.

So that the attacker is leveraging the existing consent cookie, bypassing the consent step and sending the user through an unnoticed malicious OAuth flow.

Step 3: Authorization flow

In this step, the third-party OAuth server sends an authorization code along with a redirect to the MCP Proxy server, which has been registered as the legitimate client. The MCP Proxy exchanges this code for an access token.

However, due to the malicious redirect URI, the authorization code is sent to attacker.com, which is the attacker’s domain. The attacker receives the MCP authorization code.

This means that the attacker now holds a valid OAuth authorization code tied to the user’s identity, which they can exchange for further access to user data.

Step 4: Exploit completion (attacker impersonates the user)

With the MCP authorization code received at the malicious redirect URI, the attacker can now exchange this code for the access token. This token allows the attacker to impersonate the user and gain access to their protected resources without needing the user’s password/approval.

At this final stage, the attacker has effectively impersonated the user using a valid OAuth token, gaining unauthorized access to sensitive data and resources.

How to keep your MCP secure?

Now that we’ve covered how Malicious OAuth Proxying works, let’s focus on how you can prevent your MCP from being tricked into executing unauthorized actions:

1. Make authentication non-negotiable

Problem: MCP specification sometimes marks authentication as optional. When MCP servers are network-exposed and accessible through protocols like HTTP servers are much more vulnerable to unauthorized access.

Solution: Make authentication mandatory:

• Use strong authentication: Ensure that all OAuth clients and servers are protected with secure authentication mechanisms. OAuth 2.1 provides enhanced security features, including improved token management and client verification.

• Validate token audience: Validate the aud claim or resource parameter in OAuth tokens to ensure they are only valid for specific resources, preventing tokens from being misused.

• Avoid reusing static client credentials: Do not reuse static credentials across services to prevent attackers from exploiting these credentials and gaining unauthorized access.

2. Apply context-aware enforcement

Problem: Without context, security decisions are often too generic. This can lead to situations where valid-looking requests are granted access without the necessary scrutiny.

Solution: Context-aware enforcement: Ensure that security decisions take into account the full context of the request, who is making it, what they are asking for, and whether it aligns with the overall security policy.

This can include: Prompt validation (in AI systems), user identity verification, and contextual permission adjustments.

3. Prioritize runtime monitoring and tracing

Problem: Without real-time monitoring, it’s impossible to detect if the OAuth flow or MCP tools are being exploited or misused.

Solution:

• Runtime monitoring: Track and log all actions and behaviors throughout the OAuth flow and MCP server interactions, including every API call, user request, and invoked tool.

• Tracing: See the full execution path of requests to pinpoint any suspicious activity, whether it’s a malicious proxy or an attempted exploitation of a system flaw.

• Use standardization tools like OpenTelemetry: Use these tools to trace every request from start to finish, ensuring complete visibility into agent behavior and allowing teams to investigate and respond to incidents as they occur.

4. Keep humans in the loop where it matters

Problem: Automated systems can sometimes make dangerous decisions, particularly when handling high-risk actions such as deleting data or sending emails.

Solution:

• For critical actions: Always require human approval for tasks like deleting files, making financial transactions, or executing unauthorized commands.

• Implement review workflows: Use tools like HumanLayer to create approval mechanisms for sensitive or risky actions.

5. Use only trusted MCP servers

Problem: Using untrusted or unofficial MCP servers can introduce vulnerabilities or malicious code into your system, making it easier for attackers to exploit weaknesses.

Solution:

• Only adopt official, vendor-verified MCP servers: Reduce the risk of introducing malicious components by using servers that are officially verified and trusted by the vendor.

• Establish strict internal policies: Implement policies to ensure third-party tools and MCP servers are thoroughly vetted before use, ensuring they align with your organization’s security standards.

• For critical applications: Consider forking and maintaining your own versions of essential tools, allowing full control over updates and ensuring consistent security over time.

6. Validate and verify tools before use

Problem: Malicious tools integrated into MCP environments can be used to execute dangerous actions, such as data exfiltration or executing arbitrary code.

Solution:

• Always inspect and validate tools: Review the source code and check for any vulnerabilities or malicious behavior before integrating any tool into your MCP server.

• Use trusted repositories: Rely on trusted repositories for tools and avoid auto-updating them without reviewing changes. For sensitive tools, consider forking and managing them internally.

7. Secure OAuth implementation (Specific to OAuth proxying)

Problem: If OAuth implementation is improperly configured, attackers can manipulate the OAuth flow or redirect URIs to gain unauthorized access.

Solution:

• Validate redirect URIs: Ensure that OAuth tokens are sent only to trusted destinations, preventing attackers from redirecting tokens to malicious sites.

• Use OAuth 2.1: Implement OAuth 2.1 for stronger token security and client authentication to reduce the risk of token hijacking.

• Ensure scoped access: Limit the actions that tokens can perform to minimize the impact if tokens are compromised.

Malicious OAuth Proxying: Real-world MCP security vulnerabilities

Let’s look at some real-world use cases that demonstrate different aspects of this attack flow, showcasing how various vulnerabilities play a role in the exploitation process:

1. An overlooked security gap: The MCP attack surface

One key issue often overlooked is that anyone, not just LLMs, can access MCP servers. While LLMs usually reveal their intended actions through structured “plan” and “act” phases, attackers don’t follow such transparent patterns. This creates a broader attack surface that many developers have yet to secure properly.

Other security researchers, such as @junr0n (see below), have independently reported similar vulnerabilities throughout the MCP ecosystem.

2. CVE-2025-49596 vulnerability in Anthropic’s MCP Inspector

A critical flaw was uncovered in Anthropic’s MCP Inspector, a developer tool for testing MCP servers. Researchers demonstrated that attackers could host a malicious website which, when visited by a developer, sent crafted requests to the Inspector process. 

Because the tool by default lacked authentication and listened on all network interfaces, these requests could silently execute commands on the developer’s machine, resulting in remote code execution (see the attack diagram below):

MCP Inspector are vulnerable to remote code execution due to lack of authentication between the Inspector client and proxy, allowing unauthenticated requests to launch MCP commands:

3. Vulnerability in mcp-remote tool exposes developers to full system compromise

Researchers also discovered a serious flaw in mcp-remote, a proxy tool for connecting LLMs to MCP servers.

The bug allows a malicious server to send a crafted URL that executes system commands on the developer’s machine, resulting in Remote Code Execution (RCE).

4. MCP preference manipulation attacks

Researchers have described an attack called MCP Preference Manipulation (MPMA), which targets the mechanism language models use to rank and select tools. 

By embedding promotional or persuasive terms into tool names and descriptions, a malicious MCP server can bias the model’s selection process toward its own tool. This introduces risks such as the execution of untrusted tools and exposure of sensitive data.

The future of MCP security

Concerns about MCP security are real, but I see MCP as a major opportunity for LLM security vendors. 

In security, standardization has always been the turning point. For example, OpenTelemetry provided a shared way to collect system activity, which transformed how organizations monitor their software.

With adoption now accelerating, MCP could follow the same path. It has the potential to serve as a single integration layer and make agentic behavior across applications traceable.

External Links

• 1. GitHub MCP Exploited: Accessing private repositories via MCP.
• 2. [2504.03767] MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits.
• 3. Critical Vulnerability in Anthropic's MCP Exposes Developer Machines to Remote Exploits.
• 4. The MCP Security Survival Guide: Best Practices, Pitfalls, and Real-World Lessons | Towards Data Science. Towards Data Science
• 5. jro on X: "Some IDA MCP servers can be tricked into executing arbitrary code directly from the malware sample https://t.co/4kGjlKowfA" / X.
• 6. Critical RCE in Anthropic MCP Inspector (CVE-2025-49596) Enables Browser-Based Exploits | Oligo Security. Oligo Security
• 7. Critical Vulnerability in Anthropic's MCP Exposes Developer Machines to Remote Exploits.
• 8. RCE in mcp-remote (CVE-2025-6514) • William OGOU Cybersecurity Blog. William OGOU Blog
• 9. https://arxiv.org/pdf/2505.11154