Navigating MCP Security: Risks, Real-World Threats, and Practical Guidance

I was recently reading through a PDF I downloaded from WIZ Security, and I felt it was important to write a post about it and share my learnings.

The report dives deep into the Model Context Protocol (MCP) and exposes emerging security risks that both developers and organisations need to take seriously.

Hope this helps folks (like me!) who are delving deep into the vibe coding and utilising MCP. Stay secure 🔒

Navigating MCP Security: Risks, Real-World Threats, and Practical Guidance

As the Model Context Protocol (MCP) gains momentum as a core integration layer for AI tools and large language models (LLMs), it also brings a rapidly expanding attack surface.

MCP connects LLMs to external systems—unlocking powerful capabilities, but also introducing new security risks that can impact both developers and organisations alike.

This post explores the key concerns with local and remote MCP servers, real-world threats such as supply chain compromise and prompt injection, and actionable guidance for safely adopting MCP in its current form.

🔐 Understanding the Risks: Local vs Remote MCP Servers

Local MCP Servers: Trusted Code or Trojan Horse?

Installing a local MCP server is effectively equivalent to running arbitrary code on your own machine. These servers are typically sourced from open repositories like GitHub and distributed via unofficial registries—with little to no vetting, version pinning, or signing.

This ecosystem resembles early plugin systems, where supply chain risks loom large. Auto-installers like mcp-installer may offer one-click convenience, but they often bypass inspection and elevate the chance of installing malicious code.

Registry-based risks include:

Typosquatting: Trick users into installing malicious packages with similar names.
Rug pulls: Safe packages that later receive malicious updates.
Impersonation: Fake affiliations with known brands or organisations.
Account takeovers: Compromise of a legitimate developer’s account.

Even platforms like Glama .ai, which offer some trust signals (e.g., “Verified” or “Official” tags), can’t guarantee server authenticity or code integrity.

Remote MCP Servers: A False Sense of Safety

At first glance, remote MCP servers may appear safer, since they don’t run code directly on your system. However, this security is superficial. Remote servers can still:

Trigger remote code execution (RCE),
Steal credentials,
Access your local filesystem indirectly through client integrations.

Because remote servers may process sensitive tokens, application context, or internal data, vendor risk and data privacy concerns must be taken seriously.

⚠️ Real-World Threats: From Supply Chains to Prompt Injection

Supply Chain Compromise

MCP servers are vulnerable to many of the same attacks seen in open-source ecosystems:

Malicious updates pushed via hijacked accounts,
Unvetted servers published under deceptive names,
Abandoned tools that quietly become attack vectors.

Auto-installers exacerbate these issues by reducing user scrutiny.

Prompt Injection

Prompt injection remains one of the most pressing LLM-specific threats in the MCP ecosystem. Attacks may involve:

Indirect injection via content (e.g., README files or commit messages),
Command hijacking, where ambiguous inputs like /deploy are routed to malicious servers,
Tool impersonation, where a malicious server registers a common tool name to override a legitimate one.

A proof-of-concept published by Wiz security researcher Gal Nagli showed how an external MCP server parsing GitHub docs led to full RCE on the host machine—clearly demonstrating that prompt injection can become a system-level threat.

✅ How to Evaluate and Safely Use MCP Tools

While the ecosystem is still maturing, developers and security professionals can take proactive steps to mitigate risks:

Immediate Best Practices

Use trusted sources: Choose well-known servers or vendors with a visible security track record.
Always audit before usage: Inspect server code and activity before installing—avoid auto-installation.
Apply least privilege: Limit token scope and be wary of authentication requests.
Select secure MCP clients: Look for clients with audit logs, approval flows, and permission controls.
Prefer local servers (with caution): Run them in containers, with strict network and syscall restrictions.
Curate your own registry: Maintain an internal list of approved MCP servers to avoid surprises.
Use a proxy layer: Deploy an MCP Gateway (e.g., MCP Guardian or MCP Gateway) to monitor traffic and enforce policies.
Implement allowlisting: Extend existing binary allowlisting to cover MCP-related components.

Preparing for the Future

Support signed, pinned packages: Await the official registry with better integrity controls.
Encourage namespacing: Reduce typo-squatting by adopting scoped tool names.
Use sandboxed environments: WASM- or Docker-based server isolation (e.g., via toolhive or hyper-mcp) adds strong containment.
Follow tool annotations: Future support for tags like readOnly or destructive could drive permission-aware decisions.

🛍️ Conclusion: Proceed With Caution, But Don’t Stand Still

MCP is evolving rapidly, with exciting innovations on the horizon. However, many of its current security mechanisms are underdeveloped or inconsistently applied.

Until stronger defaults and official tools are available, it’s up to early adopters to tread carefully—applying hard-won lessons from past ecosystems.

If you’re experimenting with or deploying MCP in your environment, treat every server like privileged software. Inspect thoroughly, apply policy rigorously, and never assume safety just because something “looks official.”

📚 Reference

Wiz. Inside MCP Security: A Research Guide on Emerging Risks. 2025. Available at: WIZ Security page.

Navigating MCP Security: Risks, Real-World Threats, and Practical Guidance