Using Containers to Secure Your MCP Infrastructure

By Alfredo Oliveira, David Fiser

Summary

• This report is part of our continuous research on how to strengthen MCP security. We have previously warned about unwanted MCP server exposure in this report.
• Our previous research also discussed how poor secret management can threaten the safety of private data in this report.
• Use verified MCP servers to prevent AI supply chain attacks using abandoned MCP server repositories.
• Implement least privilege and MCP server containerization to improve AI security.

As part of our continuous research on how to strengthen Model Context Protocol (MCP) security we explore how proper MCP server hardening within containers can mitigate security risks and offer security benefits essential for protecting cloud workloads. MCP is an open-source standard that enables AI applications to interact with systems like databases, APIs, and services using natural language, simplifying and increasing the scalability of the creation of complex workflows on top of LLMs.

MCP offers enterprises many advantages but adds to an organization’s attack surface when implemented and so requires additional security. This report explores how containers can help provide an additional layer of protection to MCP servers. However, it should be said that containers do not guarantee absolute protection, and so we will discuss how improper container usage creates a false sense of security.

Lastly, we will discuss the possibility of AI supply chain attacks induced by dangling MCP server repositories, and give actionable advice for designing secure container MCP server deployments.

First things first: Do I need MCP?

Before discussing the security risks of adding an MCP layer, we recommend assessing if there is truly a need for it. Check if the problem benefits from tool orchestration and LLM-driven reasoning, or if a direct CLI/SDK call would do the job with less complexity and a smaller attack surface.

Large language models, together with tools and data provided from MCP servers, can be powerful allies in non-deterministic applications. However, looking over the number of MCP servers available and their description begs the question of whether a developer really needs MCP for SSH and container registries among others, or will it only extend attack vector?

Use MCP when the task needs reasoning over messy inputs, multi-tool coordination, or human-in-the-loop decisions. Prefer a simpler approach when the action is deterministic and well-bounded (such as running one SSH command, reading a registry tag list, or rotating a key).  

This keeps the benefits of MCP where they matter while avoiding an unnecessary new attack path. Keep in mind that not every workflow or automation needs an LLM application.

When it is determined that using a MCP is truly beneficial, prefer stdio mode. In that case the MCP server runs as a local process and communicates with the client over standard input and output. Remember, when no TCP port is opened, nothing is exposed on the network.

Improving MCP security through containers

In following text, we describe how to improve MCP server security through containerization, while pointing out security gaps we identified in our research by analyzing 22,000 MCP repositories.

Sandboxing MCP server functionality

Certain MCP servers poses significant risk by exposing local system resources to the remote network calls. While this is more a feature than a vulnerability, extra steps should be taken to minimize risk. prevent the worst.

As a demonstration we created a Proof of Concept using Playwright MCP project. According to documentation the standalone MCP server with HTTP transport enabled gives every client access to system resources.

Figure 1: Playwright MCP running as a standalone computer process

We requested access to the /etc/passwd file. In our case, the server runs isolated in a container. However, if the process was not sandboxed, any attacker with access to the MCP server could request sensitive local files. Depending on the server process permissions, attackers could exfiltrate system credential files, all SSH keys, and cloud accounts credentials, among others.

Additionally, it isn’t safe to assume the MCP server is only available at localhost; unless a specific configuration is passed, the MCP server listens to all network interfaces. And even if the MCP server is only exposed on the localhost interface, other local users could still exploit the MCP server functionality and achieve privilege escalation. Naturally, the risk increases when the MCP server becomes fully exposed to the network.

Unfortunately, we already identified nine instances of Playwright MCP server exposed on the internet in our MCP exposure research.

Figure 2: Playwright MCP server default network exposure

Figure 3: Playwright MCP server request browsing the /etc/passwd container file

Although running MCP over HTTP/SSE is convenient, it expands the attack surface compared to stdio. A common bad practice is starting an MCP server that listens on the network and binds to 0.0.0.0 (all interfaces). That makes your tools reachable from any host on the same network (and, in cloud or mis-NAT setups, sometimes far beyond). Even if you “just test locally,” a coworker on the same network, a shared lab subnet, or a port scan in the office can discover and interact with it.

When running MCP server inside a container it is crucial to limit the network access to the required minimum. We highly recommend not sharing the host network (--network=host) with the container. Always remember to limit the MCP server permissions and capabilities to a functional minimum, mitigating lateral movement options.

Read-only protection and security transfer to third-parties

Our previous research found a lack of authentication in exposed MCP servers, leaving private data sources prone to data breaches. The initial MCP protocol specification does not discuss authentication nor authorization. Meanwhile, the current specification describes authorization as optional, and our previous research showed that although the MCP frameworks used for the server development support authentication, it was not widely adopted. The MCP security was left completely in the hands of DevOps teams and third-party solutions.

Users raised their concerns regarding this, and as a result, community developers started implementing security and read-only features on MCP servers. However, as with any codebase, they are not bug free. While we found these read-only security features among 6,032 of the 22,000 MCP servers we analyzed, not all of them were properly implemented

During our analysis we identified following vulnerability types:

• Read-only protection transfers full responsibility to the LLM. This creates the risk of a model completely ignoring the tool description and bypassing the protection, whether intentionally or not. The MCP server could even be used completely without LLM, and the tools executed directly.
• Vulnerabilities in feature implementation. These include missing normalization prior to filtering and allowing bypassing using a non-filtered argument sentence.
• Third-party component present vulnerabilities. These include open-source library dependencies and closed source library dependencies.

Read-only bypasses or dangerous commands implementation for user convenience allows creative threat actors or AI agents to exploit it. We have already reported several vulnerabilities through Trend’s Zero Day Initiative. Never assume the default MCP server container is inherently secure. Use it as a base and fine-tune security for your needs. Instead of relying solely on these “security features,” spend time fine-tuning the access permissions of the data source token. Create a special token for MCP and make it read-only.

Additionally, hardening the MCP servers inside a container with limited capabilities and permissions narrows lateral movement options. For instance, limiting the network access only to the linked data sources, excludes other private data sources potentially available through the network. 

If the MCP server is vulnerable to remote code execution, limited permissions and capabilities will ensure there is no easy access to the underlying host. You might lose your container, but there is at least added complexity to make it difficult for the attacker to compromise your system. 

Figure 4: Security diagram about container isolation

Container isolation could prevent a threat actor from performing lateral movement from the exploited MCP server to the private network or interacting with other host services.

However, container isolation does not protect against Overpermissive Private Access tokens to the data source in cloud-hosted services. Proper RBAC, least privileges, and essential zero-trust policies are required to prevent lateral movement within the service provider.

Credential exposure

For accessing any private data source (APIs, databases, cloud accounts, and internal tools), a form of credentials (alias secrets) is required. Secure MCP server container deployment will prevent accessing aggregated MCP server configuration files with non-essential secrets, however it will not fully protect against every credential leak. 

Containers can help lower the risk of credential exposure through responsible secret management. However, they do not protect against bad practices, which we broadly described in our previous paper.

MCP server reputation & usage

The Model Context Protocol has been introduced in October 2024. Since then, the number of public MCP server repositories increased to over 22,000. This rapid growth introduces the question: “How can we recognize if an MCP server is trustworthy and secure?”

Figure 5: Growth of new MCP projects in GitHub from Jan 2025 to Jul 2025

We observed that the development of certain MCP servers has already been abandoned. These then become dormant dangling resources.

We analyzed over 22,000 MCP server code repositories available through public MCP marketplaces. These marketplaces provide MCP server listings with functionality description, tool availability, deployment settings and, most importantly, they link to developer’s source code repository.

We identified that in 746 cases, the code repository no longer exists, or it has been made private. These MCP servers then become a dangling reference. The listing is still in the marketplace, but the source code repository is gone.

This creates a dangerous situation as these abandoned entries can be revived by anyone who manages to control the same repository name, especially if the original maintainer is no longer active.

Figure 6: GitHub repository take over

Once a GitHub username is released, it can be registered by anyone else. For instance, when an attacker takes over the username, recreates the repository, and publishes a malicious version of the MCP server under the same familiar address, a user who sees this in an MCP marketplace has no clue that it is no longer the original safe project and could clone it without hesitation. This is an AI era supply chain attack scenario, provided by the marketplaces’ trust. 

Navigating through a jungle of unverified MCP servers with security in mind might be overwhelming. A verified MCP server container image helps to mitigate that risk. A vendor-signed container image ensures the authenticity of the code and reduces the likelihood of running a tampered or outdated version.

Running the MCP server inside a container also adds a layer of isolation, limiting the impact if the server is compromised. This combination of image verification and container isolation helps address both the trust and maintenance challenges that come with such a rapidly expanding ecosystem.

It should be said, however, that while verified container image mitigates the risk of using unofficial, vulnerable, or malicious images, it does not prevent supply chain attacks on the vendor or container registry itself and thus, by itself can't guarantee complete security.

Implementing least privilege with containerization

In the case of MCP security, applying the principle of least privilege is the best approach: it is simple, measurable, and can be proven with a checklist. No software is bug-free and MCP servers are not an exception. If an attacker achieves code execution on the MCP server, the last thing you want is over-permissive token or a process that runs with rich OS capabilities.

Limiting the server’s effective capabilities and permissions is the most realistic way to mitigate risk: it can be tested, enforced, and audited.

Below are some best practices for MCP servers running in containers:

• Identity and tokens
  • Give each MCP server its own service account and client identity. Do not reuse tokens across servers or tools.
  • Use short-lived credentials (OIDC/STS). Set TTL value to minutes, not days.
  • Scope tokens to the exact APIs and actions, and avoid wildcards.
  • Bind tokens to audience and origin where possible; disable refresh unless needed.
• Process and container runtime
  • Run as non-root, add no-new-privileges, drop all capabilities; then add back only what is truly required (often none).
  • Use a read-only root filesystem; mount a small writable tmpfs if needed.
  • Enable seccomp default profile and an AppArmor/SELinux profile.
  • Avoid a shell in the image; no bash, no package managers in production image.
• Filesystem and mounts
  • Mount only the directory the server needs, read-only when possible.
  • Never mount the Docker socket, SSH agent, cloud CLI profiles, or your home directory.
• Network egress
  • By default deny all egress. Allow only the few endpoints the server must reach (for example, a specific API hostname).
  • Bind to 127.0.0.1 if you must use HTTP/SSE; prefer stdio to avoid any listening socket.
• Tool surface
  • Disable risky tools by default (filesystem write, shell, cloud management). Enable case by case.
  • Add allowlists over denylists for commands, paths, and target resources.
• Secret management
  • Prefer on-demand secret retrieval from a vault over credential hardcoding.

Ensure the MCP server container is short-lived, and its access token is limited to a single API. The container should not have any writable mounts, no shell, no extra Linux capabilities and the network accessibility is limited to bare minimum. If that server is exploited, the impact stays small and easier to detect, which is least privilege in practice. 

Another critical layer of hardening that is often overlooked in containerized MCP deployments is running the process as a non-root user inside the container. Containers provide isolation, but if the container process runs as root and an attacker escapes the application to the container, they inherit root privileges, amplifying the impact. Additional layers to container security can be explored in our previous research that discuss minimizing containers using distroless for security, enhancing vendor container security with custom containers, and the risks in running privileged containers in Docker.

In total, 5,414 of the 22,000 MCP-related GitHub repositories we analyzed included a Dockerfile, showing containerization support. Alarmingly, only 1,276 of them, explicitly configured a low-privilege user, while 96 of them reinforced root usage. The remaining majority relied on the default user from the base image which is commonly root.

Figure 7: Example of Dockerfile setting the user as root. (https://github.com/thomasgazzoni/vsc-mcp/blob/master/Dockerfile)

This data highlights a significant gap in secure-by-default practices. While containers add a valuable layer of security, neglecting to drop privileges inside them undermines the entire model, leaving MCP servers exposed to privilege escalation attacks. In other words, the provided MCP containers might not be necessarily secure and custom evaluation and tweaking might be required. 

After careful assessment and proving the MCPs are beneficial to enterprise operations, the organization must ensure that the extension of the organization’s attack surface is protected. Containerization is a practical way to cover security risks that come with the use of MCP, especially when implemented with the principle of least privilege in practice.

When your enterprise opts to strengthen MCPs through containerization, security tools and policies should be implemented to ensure the protection of the container infrastructure, software supply chain, runtime, and the processes that run in between.

Trend Vision One™ Container Security provides end-to-end container protection by simplifying container security with advanced image scanning, policy-based admission control, and runtime protection, detection, and response. Trend Vision One Container Security helps enterprises detect risks such as vulnerabilities, malware, and compliance violations within containers earlier, before they can be exploited.

Trend Vision One™ Security Operations can provide enterprises with another layer of security to protect their AI stacks, powered by the broadest native sensor coverage that delivers actionable insights, centralized visibility, and faster response. SecOps is powered by Agentic SIEM, which is designed to ingest limitless data and deliver real-time detection; Agentic Soar, which uses AI-guided SOC workflows to reduce manual effort and drive more efficient action; and XDR, which unifies native third-party telemetry with the industry’s broadest sensor coverage in one console.