How do you run an MCP server in Docker safely?

To run an MCP server in Docker safely, launch it with docker run in interactive mode so the client can talk over standard input and output, then restrict the container: read-only filesystem, non-root user, dropped capabilities, resource limits, mounted folders only as needed, and a network setting that matches what the server must reach.

Why bother with a container?

The MCP specification's stdio transport has the client launch the server as a subprocess, which reads JSON-RPC messages from standard input and writes to standard output. That subprocess runs with the client's privileges.

The MCP security guidance warns about exactly this. Local servers can have direct access to the user's system, and risks include arbitrary code execution with the client's privileges, no visibility into what commands run, and command obfuscation. Attack paths named in the guidance include a malicious startup command in a client configuration, a malicious payload inside the server itself, and an insecure local server left running on localhost and reached by DNS rebinding. The guidance calls for sandboxing and consent requirements.

A container is a sandbox you can set up in one command.

What does a hardened command look like?

Constructed example for a notes server. The image name is invented:

docker run -i --rm \
  --read-only \
  --cap-drop ALL \
  --user 10001:10001 \
  --memory 256m \
  --pids-limit 100 \
  --network none \
  -v "$HOME/notes:/data:ro" \
  example/notes-mcp:1.2.0

What each choice does, using the Docker run reference:

• The interactive flag keeps standard input open, which stdio transport needs. The remove flag deletes the container when it exits.
• The read-only flag mounts the container's root filesystem read only.
• Dropping all capabilities removes Linux privileges the server does not need.
• The user flag runs as a numeric non-root user.
• Memory and process limits stop one runaway server from taking the host.
• Network none gives no network at all. A notes reader does not need one.
• The volume mounts one folder, read only.

What if the server needs the internet?

Many do. Then use a dedicated Docker network and control egress outside the container, for example with a firewall rule that allows only the host names the server needs. NIST SP 800-190 notes that in most runtimes containers can reach each other and the host by default, and that egress control is harder in container environments, so do not assume the defaults protect you.

What about secrets and tools?

Pass only the credentials the server needs, scoped to least privilege and short lived, as environment variables or mounted files that are read only. Never mount your home directory or the Docker socket. A server with the Docker socket can start other containers with any privileges.

Also pin the image by version or digest, from a source you trust. A floating latest tag means the thing you approved last week is not what runs today.

A container limits blast radius. It does not decide whether a tool call is a good idea. An agent that can call a delete tool inside the sandbox can still delete what the sandbox contains.

Where Safeguard fits

Container isolation protects the host. A separate layer decides what an agent may do through MCP tools. Safeguard's MCP Guardrail and policy gates work at that layer, and the Safeguard MCP server at mcp.safeguard.sh offers unlimited tool calls on every plan. Use both layers.

How to check or apply this

1. Prefer a vetted image or build your own from a minimal base, pinned by digest.
2. Start with the hardened command above, then loosen one setting at a time as the server fails, documenting each change.
3. Mount only the folders needed, read only unless the server must write.
4. Keep the Docker socket and your home directory out of the container.
5. Control outbound traffic for servers that need the network.
6. Log tool calls and review them.
7. Re-check the image when it updates.

Quick check

Sources

• Model Context Protocol: Transports
• Model Context Protocol: Security Best Practices
• Docker docs: docker container run
• NIST SP 800-190, Application Container Security Guide

Last reviewed: 18 October 2026.