Evidence-first authority page
MCP Server Security: Docker Sandboxing and Access Rules
Security practices for MCP servers that execute code or commands, including containerization and access-rule design.
Direct answer
For any MCP server that executes code or shell commands on behalf of a model, run that execution inside an isolated container with no access to the host filesystem, network, or credentials beyond what's explicitly required, and apply resource and time limits so a runaway process can't affect the host system.
Last reviewed 2026-08-29
This page remains noindex while its page-level source receipts are completed and verified. It is available for review, not presented as publication-ready authority.
Why execution servers need this specifically
Unlike a read-only data server, an execution server runs commands generated by a model — commands that were never reviewed by a human before running. This is a fundamentally different risk profile from a lookup tool, and warrants the strongest isolation available: a fresh, resource-limited container per execution, with no persistent access to anything beyond what the specific task explicitly needs.
Concrete sandboxing rules
- Mount only the specific working directory the task needs, never the host filesystem broadly.
- Disable network access inside the container unless the task specifically requires it.
- Set CPU, memory, and wall-clock time limits so a runaway or unintended long-running process is automatically terminated.
- Use a fresh container instance per execution rather than reusing one across unrelated tasks.