Security Model

Relevant source files

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

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

The security model of the MCP Server Code Execution Mode is built on a foundation of rootless container-based isolation and host-mediated proxying. Its primary purpose is to provide a secure environment for executing LLM-generated Python code while preventing unauthorized access to the host system or network. The system transitions away from failed in-process sandboxing attempts to a robust "defense in depth" strategy.

Sources: HISTORY.md:7-11, ARCHITECTURE.md:3-6, README.md:120-130

Core Architectural Isolation

The bridge enforces strict boundaries between the untrusted code execution environment (the sandbox) and the host system. All cross-boundary operations, including calls to other MCP servers, are explicitly mediated by the host via a JSON-framed stdio bridge.

Container Hardening

The execution environment is a python:3.14-slim image (by default) heavily restricted using container runtime flags. These constraints ensure that even if the sandboxed code is malicious, its impact is contained.

Security Constraints

Constraint	Mechanism	Purpose
User Isolation	Rootless Podman/Docker	Runs in user namespace without privileged helpers.
Privilege Control	--no-new-privileges	Prevents process from gaining new privileges via suid/sgid.
Capability Dropping	--cap-drop ALL	Removes all Linux kernel capabilities.
Network Isolation	--network none	Completely blocks all external and internal network access.
Filesystem Security	--read-only	Makes the root filesystem immutable.
User Identity	65534:65534	Executes as an unprivileged, non-root user.

Sources: README.md:347-360, ARCHITECTURE.md:85-100, mcp_server_code_execution_mode.py:410-440

Resource Quotas

To prevent Denial of Service (DoS) attacks or resource exhaustion, the bridge applies strict limits on hardware usage:

• Memory: Defaulted to 512m (Configurable via MCP_BRIDGE_MEMORY).
• PIDs: Limited to 128 to prevent fork bombs (Configurable via MCP_BRIDGE_PIDS).
• CPU: Quotas applied via --cpus if MCP_BRIDGE_CPUS is set.
• Timeouts: Default 30s, maximum hard ceiling of 120s.

Sources: STATUS.md:27-38, ARCHITECTURE.md:74-83, mcp_server_code_execution_mode.py:84-88

Mediation and Proxying

Untrusted code does not communicate with MCP servers directly. Instead, the SandboxInvocation class generates a per-execution entrypoint that installs mcp_<alias> proxies. These proxies forward requests to the host bridge, which then routes them to the actual MCP servers.

Input and Configuration Security

The bridge implements defensive measures to prevent misconfiguration and recursive execution:

• Self-Reference Prevention: The bridge automatically skips configuration entries that would launch the bridge recursively (e.g., uvx ... mcp-server-code-execution-mode run). This is controlled by checking _looks_like_self_server.
• Fuzzy Discovery: Instead of preloading all tool schemas (which could leak information or bloat context), the bridge uses a "Discovery-First" approach. The LLM only receives metadata on demand via query_tool_docs or search_tool_docs.
• State Isolation: While sessions are persistent for convenience, the filesystem remains ephemeral. Only tmpfs mounts (like /tmp and /workspace) are writable, and these do not persist on the host unless specifically mapped.

Sources: README.md:120-135, mcp_server_code_execution_mode.py:195-225, ARCHITECTURE.md:54-68

Execution Lifecycle Security

Every request follows a secure lifecycle managed by the SandboxInvocation and SandboxRPCServer logic:

1. Validation: Input code and requested servers are validated against discovery catalogs.
2. Preparation: A temporary IPC directory is created with restricted permissions (0o755).
3. Injection: Metadata is injected via environment variables (MCP_AVAILABLE_SERVERS).
4. Monitoring: The host bridge monitors stdout/stderr, filters runtime chatter (like Podman pull progress), and enforces hard timeouts.
5. Cleanup: Temporary IPC assets are deleted after execution, though MCP clients remain "warm" in the host pool for efficiency.

Sources: ARCHITECTURE.md:54-70, mcp_server_code_execution_mode.py:750-800, STATUS.md:40-45

Summary

The security model prioritizes Defense in Depth by combining rootless containerization, mandatory host mediation, and strict resource capping. By shifting from in-process sandboxing to container boundaries, the project ensures that code execution is stateless (on the filesystem) and network-isolated, providing a production-capable bridge for LLM tool orchestration.

Sources: HISTORY.md:105-115, STATUS.md:110-120