Docker open-sources an MCP Gateway
Docker announced an open-source MCP Gateway intended to sit between AI agents and multiple MCP servers. The company described the gateway as a centralized enforcement point that works with Docker Compose and can apply options such as signature verification, call logging, and secret blocking. Docker said the gateway was available in Docker Desktop and as an open-source project for community use.
By Hypler editorial team ยท Source: Docker.
Original source date: .
Hypler publication: . Hypler updated: .
Topics: Docker, MCP, security, gateway
Engineering relevance
MCP connections create a growing tool and data-access boundary that benefits from centralized policy enforcement. Gateway features can support defense in depth, but they do not prove that a call is appropriate or that a server is trustworthy. An effective control plane also needs explicit allowlists, scope review, audit retention, and human accountability for high-impact actions.
Source record: a centralized MCP enforcement point
On July 9, 2025, Docker announced its open-source MCP Gateway as a process between AI agents and multiple MCP servers. Docker described the project as compatible with Docker Compose and showed configuration commands for enabling selected servers and selected tools. The launch article listed an initial interceptor set for image-signature verification, inbound and outbound secret blocking, and call logging. It also described the gateway as available through Docker Desktop and as an open-source project. The source presents a gateway architecture for discovery, configuration, execution, and security controls around MCP workloads.
Engineering guidance: define gateway policy as configuration
Gateway policy should be explicit, versioned configuration. Define allowed clients, servers, transports, tool names, argument constraints, rate limits, authentication requirements, log destinations, and failure handling in a reviewed artifact. Separate tenant, environment, and sensitivity policies so a local developer gateway does not inherit a broader server list or credential scope. Expose only the server and tool subset required for each workflow. A policy diff should show whether a change adds a server, broadens a tool argument, permits a new outbound host, or changes a security interceptor. These details are the operational meaning of centralized enforcement.
Interceptors supplement server-side controls
Signature verification, secret scanning, and call logging address important transport and supply-chain conditions. They work alongside server-side authorization, schema validation, target-object checks, and application approval rules. Treat an interceptor result as a structured policy signal with a decision, reason code, configuration version, and request identifier. Preserve the server result separately from the gateway result so operators can distinguish a blocked request, a rejected request, an unavailable server, and an executed request with an uncertain outcome. This separation supports incident investigation without asking a single log line to explain the whole action path.
Hypothetical implementation: a two-server support gateway
Consider a hypothetical support gateway for one agent client. The gateway exposes a public-status lookup server and a read-only knowledge-base server over a named transport. Its policy lists the two server images by digest, permits only status and search tools, blocks payloads matching configured secret patterns, and writes structured call records to a retained audit store. The client can gather cited status and knowledge excerpts for a draft response. Customer updates, ticket changes, and message sending remain separate workflows with their own authorization paths. The example shows how a gateway can make one narrow tool surface visible and testable.
Logging must preserve decision context
Record a correlation identifier, authenticated client, gateway policy revision, server image digest, selected tool, argument classification, interceptor decisions, timestamps, response category, and retained evidence reference. Redact secrets and sensitive data according to a defined logging policy rather than relying on ad hoc string filters. Link a retry to the originating request so operators can identify duplicates and reconcile ambiguous network failures. Monitor denied calls, secret-block events, unknown tool requests, policy mismatches, transport errors, and long-running calls. Those signals reveal policy drift and integration failures while the affected configuration is still easy to inspect.
Rollout requires controlled failure testing
Start with a small server set and a fixed client identity. Test allowed requests, blocked tools, invalid arguments, expired credentials, untrusted server output, failed signature checks, secret-pattern matches, server restarts, and partial responses. Confirm that a policy-denied call cannot bypass the gateway by using a direct connection in the intended deployment topology. Keep a rollback configuration that removes newly added servers or restores the prior policy revision. Re-run the suite when the gateway, a server image, an interceptor, or a transport changes. This creates repeatable evidence for the exact boundary the gateway is expected to enforce.
Gateway capacity also affects control behavior. Set timeouts, concurrency limits, connection pools, request-size limits, and backpressure rules for each transport, then exercise those limits under load. A saturated gateway should return a visible, classified failure rather than silently dropping audit events or forwarding a partially validated request. Capacity tests should verify log delivery, interceptor execution, and policy lookup while multiple clients compete for the same server. Capture the configuration and observed saturation point with the normal validation evidence. This connects security controls to the operational conditions in which they must continue to work.
Original source
Related links
Historical source briefing with Hypler engineering analysis. Source details reflect the original publication date; implementation examples are hypothetical.