MCP Server: The Dangers of “Plug-and-Play” Code

With great power comes great(er) responsibility

Since its launch in November 2024, MCP (Model Context Protocol) has been adopted across industries, for high impact use cases it is now the de facto funnel between generative AI models and external data sources, tools, and enterprise systems. We are talking about enterprise tools (Microsoft, Github, Slack, Atlassian) connecting to developer platforms and databases (PostgreSQL,Single Store) and browser automation frameworks (Playwright, Puppeteer) resulting in core business data and work streams being exposed to agentic AI applications.

There have been several vulnerabilities listed by security researchers from various security companies including Acuvity ranging from unauthorized access to data leakage to tool poisoning to cross server tool shadowing that can give hackers the keys to the MCP kingdom easily.

Securing all aspects of MCP clients and servers becomes paramount to ensure Gen AI teams can adopt the extremely powerful component of the Gen AI developer ecosystem without having to worry about threats in production deployments.

Acuvity has taken up the gauntlet to secure the MCP ecosystem with a complete range of tools – secure containers, SBOM validation, miniaturized proxy with authorization and threat prevention controls that are enhanced based on core functionality the MCP server provides and more.

Introduction

Running MCP (Model Context Protocol) servers using local executables like Node’s npx, Astral’s uvx, or downloaded binaries might be convenient, but it carries serious security risks. When you run an MCP server locally, you grant untrusted code your user’s full permissions. This means the code can:

• Access any file your user can read or modify
• Scrape sensitive environment variables
• Open network connections and more

Security researcher Bob Dickinson warned, “the code that is then run on your machine has root access — it can see your entire machine, environment variables, the file system. It can open ports to listen or to exfiltrate data” [1].

Each time you use npx (or uvx), you’re downloading the latest code published by the author without any built-in auditing or sandboxing. This is similar to the notorious “curl | bash” anti-pattern—with no pinning, signing, or checksum verification for code integrity [2].

Supply Chain Risks

Because MCP servers are community-contributed, there’s little assurance of safe practices. A malicious actor could:

• Publish a package that mimics a popular tool’s name (typosquatting)
• Inject harmful code in a once-trusted project (a “rug pull”)

With auto-update defaults, you might pull a compromised version immediately. The risk increases further if the MCP tool is distributed as a compiled binary with no easy way to inspect its behavior [2].

The Safer Path: Docker Container Isolation

Using Docker or Podman to containerize MCP servers significantly mitigates these risks. Here’s why:

• Isolated Execution:
  Containers confine the tool to a restricted filesystem and process space. The MCP code only accesses files and directories you explicitly allow, keeping your system safe even in the presence of malicious code [1].
• Non-Root by Default:
  Container best practices run processes as non-root users, or if as root, within a namespaced environment. This reduces potential damage from exploits, aligning with Kubernetes’ Pod Security Policies [2].
• Immutable Runtime:
  Docker images offer a fixed filesystem snapshot that doesn’t change at runtime. Unlike npx, which fetches the latest code every time, a container runs a specific tagged or digest image. This ensures that updates occur only when you decide to update and review the changes [3].
• Version Pinning & Vulnerability Scanning:
  You can pin container versions and use security tools to scan images for known vulnerabilities before deployment. Official images on Docker Hub are often digitally signed, adding an extra layer of trust [4].
• SBOM and Provenance:
  Container builds can generate a Software Bill of Materials (SBOM) and cryptographic provenance attestations. This transparency helps verify that the tool hasn’t been tampered with [5].

A Cautionary Example: “Everything Wrong” Local Execution Demo

Imagine a not so fictive MCP tool server called mcp-server-everything-wrong. This insecure MCP server:

• Reads private files
• Dumps environment secrets
• Makes unauthorized network requests

For example, a debug tool like env_var might be harmless in a secure setting, but in the wrong hands, it could send sensitive API keys or credentials to an attacker. Running this server with npx or as a local binary gives it full control of your user permissions—handing over your secrets without your consent.                                  

An exploit like this can occur without your knowledge, as the tool may trigger harmful actions automatically as mentioned in these articles [1] [2] [6] [7].

A Better Approach: Containerize and Govern with ARC & MiniBridge

Security experts recommend containerizing MCP servers. This is why at Acuvity, we built ARC (Acuvity Runtime Container) to offer a hardened runtime as described in our articles Securing MCP Servers [8] and Securing Anthropic MCP with Acuvity [3].

• Isolated Execution: Run securely in isolated containers, preventing lateral movement.
• Non-root by Default: Minimize risks by enforcing least-privilege.
• Immutable Runtime: Read-only file system ensures tamper-proof operations.
• Version Pinning & CVE Scanning: Consistent and secure deployments with proactive vulnerability detection (via Docker Scout).
• SBOM & Provenance: Traceable builds for complete supply chain transparency.

Acuvity also pairs ARC with MiniBridge [9], a specialized opensource lightweight proxy enhancing security and governance. MiniBridge supports policy engines (like Open Policy Agent with Rego policies) to enforce fine-grained runtime security. Together, ARC and MiniBridge form a robust defense that limits damage even if an exploit occurs.

Remember, just because a tool is listed in an MCP registry doesn’t mean it’s safe. The safest approach—especially for handling sensitive data—is to self-host MCP tools in containers on trusted infrastructure with strict security policies.

1. Bob Dickinson. “Stop Running Your MCP Tools via npx/uvx Right Now.“ Medium. May 2025.
2. Rami McCarthy. “Research Briefing: MCP Security.“ Wiz Blog. April 17, 2025.
3. Sudeep Padiyar. “Securing Anthropic MCP with Acuvity.“ Acuvity Blog. May 16, 2025.
4. Acuvity. “MCP Security.“ Acuvity (product page), 2025.
5. Docker Docs. “Explore Analysis in Docker Scout.“ Docker Documentation.
6. Repello AI. “MCP Tool Poisoning to RCE.“ Repello Blog, 2025.
7. Repello AI. “MCP Exploit Demo.“ GitHub Repository, 2025.
8. Acuvity. “Securing MCP Servers.“Acuvity (web article), 2025.
9. Minibridge: “Make your MCP servers secure and production ready” GitHub Repository, 2025.