Speakeasy vs Docker MCP Gateway: Who governs your agents' tool calls?

Docker MCP Gateway has the most thorough documentation of any option for running Model Context Protocol (MCP) servers safely on a developer's machine. Each server runs in its own container with CPU and memory caps, no access to the host environment, and signature-verified images. Docker's AI Governance tier adds organization-wide policy written in Cedar and audit records you can forward to a SIEM. Speakeasy works on the other side of the connection: who the caller is in your identity provider, which AI client they're using, and which credential the gateway presents upstream on their behalf.

Choose Docker when the main risk is what an MCP server can do on the machine that runs it. Choose Speakeasy when the main risk is who can call which tool, from which client, with whose credentials. Plenty of organizations have both problems, and the two products don't rule each other out. Below, we compare them on identity, per-tool policy, client admission, upstream credentials, audit, and deployment. Every claim about Docker links to Docker's own documentation.

What is Docker MCP Gateway?

Docker MCP Gateway is Docker's open-source, MIT-licensed proxy between MCP clients and MCP servers. When a tool is called, the gateway starts the server that owns it as a Docker container if it isn't already running. It then injects the credentials that server declares and forwards the request (Docker docs). It ships as the docker mcp CLI plugin, and the Docker MCP Toolkit in Docker Desktop runs it in the background. Servers are grouped into profiles, and both profiles and catalogs can be pushed to and pulled from OCI registries (README).

The Docker MCP Gateway name now covers three offerings with different scopes, so an evaluation needs to say which one it means:

1. The open-source gateway and the MCP Toolkit. These are free, run locally, and are configured per machine through profiles and catalogs.
2. Docker Sandboxes with AI Governance. Docker Sandboxes has its own MCP gateway, separate from the Toolkit. With a separately sold AI Governance plan, organization admins write MCP access policies in Cedar, scope them to the organization or to teams, and collect audit records in Docker Cloud or a SIEM.
3. Docker MCP Enterprise Gateway. Docker's product page describes a central gateway that authenticates users through your identity provider, scopes tools to groups, reads credentials from your secret store at call time, and streams one structured event per evaluation to your SIEM. It's offered managed inside your cloud account or VPC, or as an air-gapped appliance on private Kubernetes. A multi-tenant Docker-managed cloud option is listed as coming "when it lands."

Docker's gateway documentation notes that "MCP Gateway as part of Docker AI Governance is an invite-only feature." The Enterprise Gateway has a product page but no public reference documentation that we could find. So the detailed comparisons below rely on the public AI Governance docs for policy and audit, and they report the Enterprise Gateway's capabilities as Docker states them.

Speakeasy vs Docker MCP Gateway at a glance

What does Docker MCP Gateway do well?

Docker's strongest argument is containment. The gateway docs put the problem plainly: "MCP servers are just programs that need to run somewhere," and running them directly on a laptop means taking on their dependencies and their security risks. The MCP Toolkit limits each tool container to 1 CPU and 2 GB of memory and gives it no host filesystem access unless the user grants a mount. The gateway's security model adds more. Containers start without the user's host environment and with no-new-privileges. Host bind mounts are read-only by default, and a writable bind needs an exact allowlist entry. If you're worried about a malicious or compromised MCP server reading ~/.aws on an engineer's laptop, that's the threat Docker designed for.

The defaults are cautious. Images in Docker's mcp/ namespace are signature-verified before they're pulled or run, and each ships with an SBOM. The --block-secrets flag is on by default and scans tool arguments and text responses for secret-like values. Call logging is also on by default and records only the tool name and argument shape, not raw values. On the sse and streaming HTTP transports, requests need a bearer token unless an operator opts out with --allow-unauthenticated. Remote MCP URLs must be public HTTPS destinations, so a crafted catalog entry can't point the gateway at a cloud metadata endpoint. Each of these is documented as a security boundary, along with how Docker triages reports against it.

Distribution builds on infrastructure many teams already run. Profiles and catalogs are OCI artifacts, so a platform team with a private registry can version an approved set of servers and publish it the same way it publishes images.

Docker's Cedar policies can also express more than Speakeasy's permission model. A rule can condition on tool arguments: Docker's policy reference shows a permit for approve_expense only when context.args.amount <= 500. A @requireApproval annotation pauses a matching call and asks the person in the session to confirm it through an MCP elicitation. Speakeasy's role grants stop at the tool, so it has no equivalent of an amount ceiling inside its permission model.

The open-source gateway costs nothing. For one team validating a few local servers, it's the right amount of product, a point we also made in our enterprise gateway roundup.

Where does Docker's documentation draw the lines?

These limits come from Docker's own documentation. Most are deliberate design choices, but each one affects how an enterprise rollout works.

Policies target teams, not people. The MCP policy reference says that "principal-based rules don't take effect" and that admins should use organization or team scope to target users. A one-person exception means creating a team. Audit records name the signed-in Docker Hub username and email (record reference), so the identity in the log is the Docker account. If that account is tied to your SSO, it resolves to the employee.

Agents can see tools they can't call. Tool and resource listings aren't evaluated by Cedar, so "tool listings can include tools denied at invocation." An agent spends context on tool definitions it will be refused, and the person using it sees a failure instead of a missing tool.

Rules are written per server name and per tool name. Server groups aren't supported in MCP policy, so each server is referenced individually. A bare tool-name match "applies to every server exposing a tool with that name," and a rule for a registered server must match every name the server was registered under.

Tool annotations come from the server. Docker calls annotation attributes "advisory." Its defaults are conservative: destructive defaults to true and readOnly to false when a tool doesn't declare them. Even so, a rule that permits readOnly == true trusts whatever the server declares.

Approval is a confirmation, not a review. Docker's MCP access policy docs say @requireApproval "doesn't create administrator approval or separation of duties," and that "an autonomous MCP client can respond to an in-protocol elicitation programmatically." Docker recommends forbid for operations that must never run.

Enforcement covers only traffic that goes through Docker's gateway. MCP access policies "don't govern an MCP server that an agent or MCP client configures and connects to directly from inside the sandbox"; closing that path takes a matching network policy. The governance docs apply to local sandboxes, with cloud sandboxes configured separately. The AI Governance plan page notes that "members without an AI Governance license can still use Docker AI products." Docker's answer to personal accounts is sign-in enforcement, deployed through MDM, which revokes credentials for users outside the allowed organizations.

Registration rules don't reach backward. A new registration rule "doesn't remove existing registrations or stop an already-loaded server by itself," so withdrawing a server takes use-time rules for each registered name.

Audit records contain metadata only. They "don't contain prompt content, agent output, or parameter values." That's a privacy advantage, and it also means an investigation can see that a tool call was allowed but not what was sent.

How does Speakeasy handle the same six questions?

Speakeasy's MCP gateway is part of the AI Control Plane, a managed platform. It doesn't run MCP servers in containers on your laptops. It hosts servers it builds, proxies remote servers, and reaches servers inside your network through tunnels. Its controls sit on the authenticated path between the client and those servers.

Identity and SSO

People sign in through single sign-on, and Directory Sync over SCIM keeps membership and roles aligned with the identity provider. When Directory Sync is on, role membership comes from IdP group mappings, and the role editor shows assignments as read-only under Managed by directory sync. Removing, deleting, or suspending a person in the IdP deprovisions them: their membership and role assignments end right away.

For Okta customers, Enterprise Managed Auth uses Cross App Access (XAA), so a person signs in once with Okta and reaches every MCP server set up for them without a separate OAuth prompt per service. Speakeasy reads Okta through an API service app limited to the read-only scopes okta.apps.read, okta.users.read, and okta.groups.read. Speakeasy never writes to the Okta org, and that connection doesn't issue tokens or sign anyone in. Cross App Access itself is configured separately in Okta, by creating the AI agent, the linked OIDC app, and a resource connection per server. The Okta IdP gateway use case walks through the setup.

Roles can also be assigned to registered agent identities, and an agent's grants are filtered against an agent runtime scope allowlist. A role therefore can't give an agent a scope the agent couldn't hold directly.

Per-tool policy

Every MCP permission row in the role editor can narrow mcp:connect to All servers, Specific projects, Specific servers, or Specific tools. Remote and tunneled servers can be permissioned by tool name once their tool metadata has been recorded. Each read, write, and connect scope has a blocking counterpart, such as mcp:blocked_connect, that withdraws the scope for matching resources even when another role grants it. The same rules appear on each server's Team Access tab, where a grant can name a role, a person, or an agent.

Annotations work differently. For a remote server, Speakeasy records the title and the four MCP annotation hints per tool name. When the live server later disagrees with the stored values, a panel reports the difference and offers Sync annotations, so a changed hint is reviewed before it takes effect. Speakeasy also turns denied requests into Authorization Challenges, which record who tried what and which scope was missing, so an admin can grant the exact role that covers it.

Speakeasy has no argument-level conditions or in-session confirmation prompts in this model. If a rule must depend on an argument value, such as an expense amount, Docker's Cedar policies can express that directly and Speakeasy's role grants can't.

Client admission and Shadow AI

Docker's policy reference lists two context fields, request time and tool arguments, and none of the resource attributes identify the calling client. Speakeasy treats the client as something policy can name. Each server's Client access setting admits Verified clients, Any client, or Off for clients that identify themselves with a Client ID Metadata Document (CIMD). A refused client gets an invalid_client error before sign-in starts. Two limits apply. Any client is the default for an unconfigured server, and Dynamic Client Registration (DCR) stays open to every client whatever the setting says. The CIMD vs DCR post explains why DCR identities are self-asserted.

Shadow AI is generally available under Guardrails for every organization. The device agent inventories the coding harnesses, assistants, and local models on enrolled machines. An admin marks each MCP-speaking tool Approved or Blocked, and a blocked tool is refused when it authenticates, on every MCP server in the organization. Shadow AI has three documented limits. A decision can be enforced only for a tool that publishes a client ID metadata document. Tools with no MCP client of their own, and local models, have their decisions recorded but not enforced. A tool on an unenrolled device doesn't appear at all. Shadow MCP covers the server side: MCP servers seen in agent traffic that nobody registered, each with an access review.

Docker's sign-in enforcement answers a different question: whether the developer is using an organization account. Shadow AI answers which AI tool that developer is allowed to point at your MCP servers.

Upstream credentials

A Speakeasy server authenticates to the API behind it in one of two ways. With per-user credentials, the platform holds an OAuth access token and refresh token for each person, encrypted at rest and refreshed silently, so a Linear tool call runs as that person in Linear. With one shared credential, a remote server can hold a static key or obtain its own token through the OAuth client credentials grant. The static credential guide covers the first case. A shared credential carries the app's permissions, not the caller's, so the docs recommend narrowing the server's Team Access to the people entitled to use it.

With Enterprise Managed Auth, Okta supplies each person's upstream token instead of a per-service connect step, and removing a person or a resource connection in Okta stops new access to every server that uses it. Compare that with Docker Sandboxes, where OAuth tokens and header secrets live in the host credential store on each developer's machine. The Enterprise Gateway's product page describes reading credentials from your own secret store at call time. Speakeasy stores credentials in its managed platform. That works for teams that want one place to revoke a grant, and it's a drawback for teams whose policy is that credentials never leave their own vault.

Audit

Speakeasy's Audit Logs record administrative activity across the organization in one feed. Each entry carries a resource:action badge, the actor, a diff of what changed, and the surface the change came from, whether that's an API key, the Platform MCP, or the Project assistant. The feed can be filtered by project, action, actor, and surface, and an Audit Log Insights assistant answers questions about it. MCP session revocations and transcript opens are logged as well. chat:read, the scope needed to read other people's session transcripts, is in no default role, including Admin.

For runtime activity, Tool Logs list each tool call with its server, tool, user, client, and status, including Blocked, and keep them for 90 days. Docker has the edge on SIEM setup: AI Governance forwards to Splunk, Dynatrace, Datadog, Sumo Logic, and CrowdStrike from a settings page. Speakeasy exports tool call logs and risk findings over OTLP, which reaches Datadog and other OpenTelemetry backends but takes more setup for some SIEMs.

Deployment model

Speakeasy is a managed gateway. It isn't self-hosted, on-premises, or air-gapped. If your security policy requires the gateway to run in your account or with no outbound connection, Docker's Enterprise Gateway offers both, and Speakeasy isn't the right choice for that requirement.

Self-hosted and private are different properties, and a self-hosting requirement is often a request for private network access. Speakeasy's answer to that request is Tailscale private access, which requires an Enterprise organization. The organization connects its tailnet once, and then each hosted server or gateway is set to Public only, Public and private, or Private only. A private-only server stops serving its public URLs and has no automatic fallback: if the tailnet is unavailable, so is the server, until an admin switches it back. Tailscale membership is an extra network restriction on top of MCP authentication, not a replacement for it. It also doesn't make the dashboard, the management APIs, or outbound connections to tool backends private. For servers that run inside your network, tunneled servers open an outbound connection, so the server gets a hosted URL with no inbound connectivity. What is a private MCP gateway? explains how private access, self-hosting, and tunnels differ and what each one costs.

When to choose Docker MCP Gateway

Docker MCP Gateway or its enterprise offerings are the better fit when:

• The main risk is the server process. Developers run local stdio servers, and you want each one isolated in a container with resource limits, no host environment, signed images, and secret scanning on by default.
• You distribute software through OCI registries. Profiles and catalogs as registry artifacts let a platform team version approved servers the same way it versions images.
• Policy depends on argument values or needs in-session confirmation. Cedar conditions on tool arguments and @requireApproval elicitation express rules that Speakeasy's role grants can't.
• The gateway must run in your account or air-gapped. Docker's Enterprise Gateway is offered in your VPC or as an appliance with no outbound connection. Speakeasy is managed only.
• You already run Docker Sandboxes. One policy model covers network, filesystem, and MCP access for sandboxed agents.
• You're running a single-team proof of concept. The open-source gateway is free, MIT-licensed, and enough for validating a few servers. Our MCP gateway architecture guide covers that setup.

When to choose Speakeasy

Speakeasy is the better fit when access should follow your identity provider down to a single tool for a person, role, or agent, and when the gateway should refuse AI clients your organization hasn't approved. It also fits when upstream credentials should be managed per user, or supplied by Okta, rather than stored on each laptop, and when a managed gateway with private Tailscale access on an Enterprise organization meets your network requirements.

Some teams will want both: Docker for isolating the servers developers run locally, and Speakeasy for the hosted and remote servers everyone shares. If you're working out where that line falls in your organization, we'd like to hear how you're approaching it.