Docker MCP Gateway: A Production Acceptance Sheet

Docker MCP Gateway receives a tool request, selects the server that exposes the tool, and starts that server in a container when required. It injects credentials and applies restrictions before returning the result to the AI client. This path can enforce server selection and credential delivery before the call reaches the container. It also concentrates image trust and secrets in one path. Network access and evidence concentrate there too.

Docker's MCP Gateway documentation describes a centralized proxy that manages MCP server configuration and credentials. It also manages access control plus routing across the server lifecycle. Servers run in isolated containers with restricted privileges and network access, with bounded resource use. The production decision should be based on observed controls under failure, not on the fact that a server starts successfully.

TL;DR

• Approve each MCP server image and tool as separate objects. Treat each credential and outbound destination separately too.
• Force isolation and credential expiry during acceptance testing. Test blocked egress and server failure too.
• Require image provenance plus digest pinning; a catalog label alone is insufficient evidence.
• Keep MCP tool traffic outside the DeepInspect model-request boundary unless a distinct HTTP LLM call is deliberately routed through it.

The acceptance boundary

Docker's MCP Catalog and Toolkit overview says the Docker MCP Catalog contains more than 300 verified servers packaged as container images with versioning and provenance, plus security updates. Profiles group approved servers for projects. Clients such as Claude Code or Cursor connect through the gateway. The same page notes that Docker AI Governance access to MCP Gateway is invite-only.

Write down the tested edition and gateway version. Record the Docker Desktop or Engine version beside the host operating system. Add the profile and exact image digest, then record the client application separately. "Current Docker MCP" will be useless during an incident six months later. I would reject an approval packet that records a mutable image tag without its digest. The green check mark belongs to the exact bytes that ran.

Each line below needs an owner, test date, captured evidence, result, and expiry date. A screenshot can show configuration, while a log, packet capture, image record, or forced-failure result proves behavior.

Catalog provenance and image acceptance

• Catalog source: Record the catalog URL or approved custom catalog and the process that admits a server. Separate Docker's published catalog from an enterprise-maintained list.
• Immutable identity: Pin the server image by digest for the acceptance run. Record the human-readable version beside it, but make promotion depend on the digest.
• Provenance: Capture the provenance material available for the image and identify its signer or builder. Verify it using an independent policy in the delivery pipeline.
• Update path: Define who reviews a new digest and how security updates enter the profile. Define how an emergency version is held back. Automatic movement to a new image without review invalidates the prior test.

The word "verified" needs a local definition. Docker publishes provenance and security-update claims for catalog images. For this acceptance sheet, verified means the publisher is recorded and the digest is immutable. Store the provenance result with the reviewer and failure disposition.

Isolation and transport acceptance

The gateway documentation says servers run in isolated Docker containers with restricted privileges, network access, and resource use. Test those properties with a server built to attempt a forbidden read, write, process action, and network connection. The server should fail at the boundary and leave evidence that an operator can retrieve.

• Process isolation: Deny privileged mode and host PID access. Remove unneeded Linux capabilities and block container-engine socket access. Confirm the effective settings on the running container.
• Filesystem isolation: Mount only named paths with the narrowest mode. Put a file named do-not-read.txt outside the allowed mount and capture the denied attempt.
• Resource limits: Exhaust memory and CPU in a test profile. The server should be contained without starving the gateway or unrelated tools.
• Transport map: Record the client-to-gateway transport and every gateway-to-server transport. Include local sockets and STDIO. Record remote MCP connections too. Authentication and encryption requirements belong beside each hop.

MCP server authorization patterns can help separate client identity from gateway policy. It also covers target authorization. A secure client connection gives no assurance about a server's outbound call unless that later hop has its own control.

Credentials, signatures, and egress

Docker says the gateway injects required credentials before forwarding a request to the server. Acceptance should show where the secret is stored, when it is materialized, which process can read it, and when it disappears. Run the server after revocation and expiry. Search its environment, filesystem, standard output, error output, and crash artifacts for the secret value.

• Credential scope: Use a dedicated identity per server and environment. Grant only the target operations exposed by approved tools.
• Credential lifetime: Prefer short-lived tokens. Record credential issuance, renewal, and revocation evidence. Test behavior during control-plane loss.
• Signature policy: Verify server images before promotion. If your organization requires signed profiles or catalog metadata, document that as an enterprise control rather than implying Docker's overview promises it.
• Outbound network: Build a destination allowlist. Record protocol, port, DNS behavior, and proxy path. Name the accountable owner for escalation. Block an unlisted domain and a direct IP address during the test.
• Response path: Inspect the route by which tool output returns to the client. Seed a test secret in tool output and verify its treatment at the gateway and client.

A connection to an unlisted host should leave a timestamped event naming the container and destination. The event should also name the profile and policy outcome, rather than a silent timeout.

Logging and rollback

Docker documents built-in logging and call tracing for visibility into AI tool activity. A usable event should record the client identity, profile, server image digest, tool name, target, start time, outcome, latency, credential reference without the secret value, and policy decision. Forward a sample to the SIEM, then reconstruct one tool call using only exported records.

Use MCP security best practices to review authorization and tool-risk controls around this operational record. Logging volume also needs a failure test. Fill the local log destination or interrupt the exporter. The team must choose a documented posture for continued tool execution and buffering. It must also cover alerting and data loss.

Rollback covers the profile and the server artifact. Preserve the last approved profile and image digest. Preserve the policy set and credential binding too. Revert them in a timed exercise, then confirm the withdrawn version cannot start. Rollback that restores an image while leaving the new credential or egress policy in place creates a mixed state with no tested baseline.

The DeepInspect boundary

MCP tool traffic sits outside the DeepInspect AI request boundary. Local STDIO calls, gateway-to-container messages, filesystem actions, database queries, and tool egress require separate controls in Docker, the host, the network, workload IAM, and the destination service. DeepInspect should never be presented as the enforcement point for those operations.

A separate HTTP request from an authenticated user or agent to an LLM can enter DeepInspect when the application deliberately routes that model traffic through the proxy. On that route, DeepInspect can evaluate identity-aware policy and record the model-request decision. AI runtime security controls explains why teams need a boundary map instead of one product label for the entire agent runtime.

DeepInspect

DeepInspect adds policy enforcement and independent evidence to the HTTP model-request segment of an agent design. It evaluates the identity context the application supplies and applies per-route policy to prompts and responses. It records the outcome before traffic continues. Docker MCP Gateway and the container runtime retain responsibility for MCP server isolation and tool authorization. Target services retain responsibility for credentials and egress.

Book a technical deep dive at deepinspect.ai.