Docker MCP Gateway

Each MCP server receives only the secrets its catalog entry declares, passed as references that Docker Desktop resolves when the container starts, and the docker process gets a scrubbed environment (PATH plus those secrets). Remote servers get their own per-server OAuth token, and client tokens are never forwarded. The credentials themselves are whatever the user stored (often broad personal tokens), one per server for both reads and writes, and per-request authorization exists only when Docker Desktop's governance feature is on; otherwise the policy client is a no-op. If several servers are enabled, a hijacked client can write to several external systems.

As a tool server, the gateway passes through whatever risk annotations downstream servers declare, but it adds none to its own management tools (mcp-config-set, mcp-remove, mcp-create-profile, code-mode, mcp-exec). The mcp-exec and code-mode wrappers can call any enabled tool behind one tool name, which hides the inner tool's annotations from the host's approval logic. There is no dry-run, read-only mode or confirmation step enforced by the server. Downstream actions such as sending messages or deleting repositories are irreversible.

The gateway validates the inputs it acts on itself. Host bind mounts are resolved through symlinks, kept read-only and limited to temp directories unless the operator allowlists a path, and credential and system paths are refused. Values that look like docker flags are dropped, model-supplied server config is checked against the server's JSON schema, and management tools only reach enabled servers. Arguments to downstream tools are passed through unvalidated. All enabled servers' tools plus the dynamic management tools are exposed by default, though per-server tool lists can narrow that.

Every local MCP server runs as a fresh `docker run --rm --init` container with no-new-privileges, one CPU and 2 GB of memory, and there is no path that runs a server directly on the host or falls back to the host when Docker fails. The container is otherwise stock: whatever user the image picks (often root), Docker's default capabilities, a writable root filesystem and no process limit. It also gets full network egress by default, along with that server's own secrets. The Docker socket and system or credential paths cannot be mounted, and `--privileged` is added only under an explicit Docker-in-Docker environment variable. Code-mode scripts run in an embedded goja JavaScript engine that only exposes the tools injected into it.

The gateway relays downstream tool results, resources and tool descriptions to the client unchanged, with no provenance or untrusted-content marking. Its own mcp-add response pastes third-party tool descriptions into a message that also tells the model to assume the server is ready to use. The only related protections are a check that stops one server shadowing another's tool or prompt names, the secret-pattern scan, and opt-in network blocking. Because the gateway aggregates servers, one session commonly mixes untrusted content, credentialed servers and egress. Nothing in the gateway breaks that combination by default, so a hijacked client can leak data and take irreversible actions through it.

The gateway has no conversational memory, but the model can change persistent configuration. mcp-config-set swaps in new config for any enabled server (checked only against that server's schema), and mcp-create-profile saves the current servers and config into any named profile, including `default`, with no human confirmation. That profile is what the next gateway start loads, and its config feeds container command lines, environment and mounts. For Claude Code clients the profile is also written to `profiles.json` in the working directory, and on connect the gateway reads that file back. In the default configuration activation is refused for any server not already enabled, so a repository's profiles.json cannot add servers.

MCP servers are third-party container images (or remote endpoints) the user enables. Images under docker.io/mcp/ must be pinned by digest and pass cosign signature verification against an embedded Docker public key before pull, which is on by default. Community images, custom catalogs, --oci-ref and remote servers get no verification, and a tool definition that changes is not re-approved. The model cannot enable a new server by default. Each server runs in its own container with only its own secrets, but with open network access.

Secrets come from Docker Desktop's secrets store and reach containers as se:// references that Docker Desktop resolves at container start, so the gateway passes handles rather than values. By default every tool call's arguments and text results are scanned for secret patterns and blocked on a match. Call logs record only the shape of arguments, and verbose output masks secrets after four characters. Resource reads and prompts are not scanned. Content-free usage telemetry (tool, server and client names) is always on through the Docker CLI's OpenTelemetry provider. Stored credentials are mostly long-lived user API keys.

By default every incoming tool call is logged to stderr with the tool name, the shape of its arguments (not their values) and its duration. Config changes and profile writes are also logged. These are plain text lines on the gateway's stderr, which the MCP client may or may not keep. Structured audit events with client identity and policy decisions go to Docker Desktop only when its governance feature is on, and they are queued, dropped under backpressure and sent without error handling. Calls made inside code-mode scripts don't pass through the call log.

Each server container is limited to one CPU and 2 GB of memory by default, and the model can't change that. There is no timeout on tool calls, no rate limiting, and no limit on how many containers or code-mode tools a session can create. The code-mode JavaScript engine has no interrupt, so a looping script can't be stopped by cancellation. Closing a client session or stopping the gateway closes its server sessions, and the containers are removed via --rm.