MCP Enterprise Gateway | Docker

Secure, minimal container images for every team, free with enterprise features, if needed.
Approve what the organization can reach. Unvetted servers are denied by default.
Expose only the tools a group needs, not the whole catalog a server ships.
Allow and deny by server, tool, transport, and call, evaluated before anything runs.
Cut off a server or a tool and every session picks it up on the next call.
A structured event per evaluation, tied to user and agent, streamed to your SIEM.
The groups you scope it to pick it up on their next session.
One endpoint per client. Catalog and policy changes land without anyone reconfiguring anything.
Each one in its own container, separated from the machine it was launched from.
Supplied when a tool runs, never distributed through client config files.
We publish and version the servers your developers want, in registries you already trust.
Isolated execution on the runtime you already run in production.
Remote, internal, and Docker-packaged servers enforce the same identity, policy, and audit rules.
Tools called from Docker Sandboxes and third-party clients follow one policy model, not two.
Sign in through your provider. Policy follows the groups you already manage.
Structured events per tool call, in the pipeline your security team already watches.
Credentials are read at call time from the store that already holds them.
Write rules in the gateway, or delegate to the policy engine you already run.
Publish private catalogs from registries you already operate, internal servers included.
Docker-operated, inside your own account or VPC. Data and traffic stay in your environment.
Private Kubernetes with no outbound connection. Catalogs, server images, and policy load from inside your network.
Multi-tenant, operated by Docker. Governed MCP without running the infrastructure.
Governs agent execution: the network the agent can reach, the files it can touch, and which MCP servers load in each sandbox.
See Docker Sandboxes
Governs agent tool use: which servers and tools any client can call, with identity, policy, and credentials applied to every call.
Control and visibility across both: what an agent may execute in a sandbox, and what tools it may call through the gateway. One place to set policy, one record of what happened.
Thousands of developers
Multiple agent harnesses
Replaced separate MCP configurations across several coding agents with one approved catalog for thousands of developers. Its platform team scopes access by identity group and revokes it organization-wide without redistributing anything.
Thousands of developers
Multiple agent harnesses
With hundreds of millions of monthly users, it retired a homegrown MCP proxy for a governed gateway: identity-bound policy, a record of every tool call, and internal servers reaching agents without handing credentials to developers.
It authenticates the user through your identity provider, resolves which servers and tools that user’s groups can reach, evaluates policy for the specific call, injects the credentials the call needs, routes it to the server, and records the decision.
Clients that speak MCP, including Claude Code, Cursor, VS Code, Codex, ChatGPT Enterprise, and agents your teams build in house.
Remote services over HTTP or SSE, containerized servers, and the internal servers your own teams build. Containerized servers run isolated in their own containers.
In your approved secret store. The gateway supplies them when a tool runs, so long-lived credentials are not distributed through client configuration files.
Yes. Catalogs, server images, and policy load from inside your network with no outbound connection.
Sandboxes governs the environment an agent runs in. The gateway governs which servers and tools it can call. Either works alone, and many customers run both.
A way of exposing tools so the agent discovers and invokes what it needs instead of loading every definition up front, which keeps context usage flat as the catalog grows.