Container Constraints

Relevant source files

The following files were used as context for generating this wiki page:

• mcp_server_code_execution_mode.py
• README.md
• ARCHITECTURE.md
• GUIDE.md
• HISTORY.md

Container constraints represent the primary security boundary and resource management system of the MCP Server Code Execution Mode. The architecture utilizes rootless containers (via Podman or Docker) to isolate untrusted Python code execution from the host system. This ensures that even though the LLM can write and execute arbitrary scripts, the impact is strictly confined to a locked-down, ephemeral environment.

The system follows a security-first design philosophy, favoring "hard" container-based isolation over "soft" process-level or VM-based sandboxing. These constraints are applied at runtime to the python:3.14-slim image (or a user-defined alternative) and encompass network isolation, filesystem immutability, capability stripping, and resource caps.

Sources: ARCHITECTURE.md:3-12, README.md:15-28, HISTORY.md:27-33

Security Isolation Model

The bridge implements a "Defense in Depth" strategy by applying multiple layers of constraints to every sandbox invocation. This prevents common attack vectors such as network exfiltration, host privilege escalation, and resource exhaustion.

Primary Security Layers

• Rootless Execution: The container runtime operates entirely within the invoking user's namespace, requiring no privileged helpers or root access on the host.
• Capability Stripping: All Linux capabilities are dropped (--cap-drop ALL), preventing the sandboxed process from performing administrative system calls.
• Privilege Escalation Prevention: The no-new-privileges flag is enforced to ensure child processes cannot gain more permissions than the parent container.
• Unprivileged User: Code runs as a non-root user (UID/GID 65534:65534).

Sources: mcp_server_code_execution_mode.py:488-510, ARCHITECTURE.md:104-110, README.md:650-664

Isolation Architecture

This diagram illustrates how the host bridge mediates access through the strict container boundary.

The bridge enforces boundaries by explicitly mounting only necessary IPC and workspace paths while disabling all external connectivity.
Sources: ARCHITECTURE.md:7-30, mcp_server_code_execution_mode.py:480-495

Resource Constraints and Limits

Resource management is handled through explicit limits on memory, CPU usage, and process counts. These values are configurable via environment variables on the host.

Hard Limit Specifications

Constraint	Enforcement Mechanism	Purpose	Default Value
Network	--network none	Prevents data exfiltration and external service access.	Disabled
Memory	--memory	Prevents host memory exhaustion (OOM protection).	512m
PIDs	--pids-limit	Prevents "fork bombs" and process exhaustion.	128
CPU	--cpus	Limits CPU cycles to prevent CPU-bound denial of service.	Host Default
Timeout	Host-side Enforcement	Terminates executions exceeding the time limit.	30s (Max 120s)

Sources: mcp_server_code_execution_mode.py:84-95, README.md:580-593, GUIDE.md:105-125

Runtime Enforcement Implementation

The limits are applied during the construction of the container launch command in the RootlessContainerSandbox class.

# mcp_server_code_execution_mode.py:485-500
def _base_cmd(self) -> List[str]:
    cmd: List[str] = [
        self.runtime,
        "run",
        "--rm",
        "--interactive",
        "--network", "none",
        "--read-only",
        "--pids-limit", str(self.pids_limit),
        "--memory", self.memory_limit,
        "--tmpfs", "/tmp:rw,noexec,nosuid,nodev,size=64m",
        "--tmpfs", "/workspace:rw,noexec,nosuid,nodev,size=128m",
        "--security-opt", "no-new-privileges",
        "--cap-drop", "ALL",
        "--user", CONTAINER_USER,
    ]

Sources: mcp_server_code_execution_mode.py:480-505

Filesystem Constraints

The sandbox uses a hybrid filesystem approach: an immutable root for safety combined with ephemeral, restricted-access writable areas.

• Read-Only Root: The entire root filesystem (/) is mounted as read-only, preventing modifications to the Python runtime or system binaries.
• Tmpfs Mounts: Writable areas (/tmp and /workspace) are provided as tmpfs mounts. These exist only in RAM and are wiped when the container exits.
• Security Flags: Writable mounts are configured with noexec (preventing binary execution from these paths), nosuid, and nodev to further restrict capabilities.
• IPC Isolation: Communication with the host is handled via a dedicated /ipc volume, which contains the generated entrypoint.py used to proxy MCP calls.

Sources: mcp_server_code_execution_mode.py:488-498, ARCHITECTURE.md:112-114, README.md:650-664

Data Flow for Execution

This sequence diagram shows how the bridge enforces constraints while facilitating the execution of code.

The sequence demonstrates that the sandbox must request external operations through the bridge, which acts as a mediating proxy for all cross-boundary traffic.
Sources: ARCHITECTURE.md:83-102, mcp_server_code_execution_mode.py:804-850

Configuration and Environment Controls

Operators can tune the severity of container constraints through host-side environment variables. These settings determine the parameters passed to the container runtime during startup.

Variable	Default	Constraint Targeted
MCP_BRIDGE_MEMORY	512m	RAM allocation limit.
MCP_BRIDGE_PIDS	128	Maximum concurrent process count.
MCP_BRIDGE_CPUS	N/A	Fractional CPU core limit (e.g., 1.5).
MCP_BRIDGE_TIMEOUT	30	Default execution duration in seconds.
MCP_BRIDGE_IMAGE	python:3.14-slim	The base immutable image used.
MCP_BRIDGE_CONTAINER_USER	65534:65534	The unprivileged UID:GID pair.

Sources: mcp_server_code_execution_mode.py:84-95, GUIDE.md:105-135

Conclusion

Container constraints in the MCP Server Code Execution Mode provide a robust, multi-layered security framework that allows for the safe execution of LLM-generated Python code. By combining rootless execution with strict resource limits and filesystem immutability, the system ensures that the "Code Mode" functionality does not compromise host security or stability. The use of host-mediated RPC for MCP tool access further strengthens this boundary, turning the sandbox into a secure, stateless execution environment.