What Is Enterprise MCP Gateway?

Start

What Is Enterprise MCP Gateway?

Enterprise MCP Gateway is the governed boundary for approved agent-to-tool traffic. The control plane registers private MCP servers and selected OpenAPI operations. The data plane exposes approved tools through MCP-compatible endpoints. Cedar policy filters discovery and calls. Credential bindings resolve secret references through the broker. Sessions and audit make the runtime path attributable and revocable.

V1 is narrow by design. It is not a broad agent platform, LLM gateway, workflow engine, public marketplace, managed MCP host, arbitrary API proxy, or default Kubernetes operator package.

Audience

• Platform engineers deciding where private MCP servers or internal APIs enter the gateway.
• Security reviewers checking default deny, discovery filtering, credential handling, and audit.
• Developers exposing selected internal API operations as governed MCP tools.
• Operators proving managed public-target or self-hosted private-target readiness.

What is this?

This is the product model. The gateway gives an enterprise one approved path for private MCP servers and selected API-backed tools. The source owner submits the capability, a reviewer approves the exact runnable projection, and runtime clients discover only the tools they are allowed to use.

The main nouns are stable across the product:

• Control plane: registry, approval, policy metadata, credential bindings, audit configuration, session metadata, and deployment scope.
• Data plane: discovery, tool calls, schema validation, credential resolution, routing, session handling, revocation, and audit emission.
• Governed MCP: MCP-compatible access filtered by identity, agent, client surface, environment, policy, credential mode, and approval state.
• Selected operations: OpenAPI operations intentionally selected, approved, mapped, and bounded before they become tools.
• Metadata-only audit: event records that carry IDs, decisions, policy versions, credential modes, reason codes, and redaction status without raw payloads or secret material.

When do I use it?

Use the gateway when the approved path needs to be easier to review than a collection of one-off MCP servers, local configs, unmanaged API keys, and incomplete audit trails.

Use it for:

• one private MCP server that needs approval, policy, credentials, routing, sessions, and audit;
• one internal OpenAPI API source where only selected operations should become MCP tools;
• one design-partner pilot that must prove allow, deny, revoke, audit, and deployment posture;
• one security review that needs stable reason codes and no-secret evidence.

What happens?

1. A server owner or API owner submits a source to the control plane.
2. The source is validated as metadata and review state, not as secret material.
3. A reviewer approves an immutable snapshot or selected API operation mapping.
4. The data plane consumes the approved projection.
5. Discovery filters tools through Cedar policy before an agent sees them.
6. Tool calls validate input, evaluate policy, resolve credential bindings, choose an approved route, handle session state, and emit audit metadata.
7. Revocation blocks new calls and affects active sessions according to the revocation contract.

What can go wrong?

• A submitted source is not approved, so no callable projection exists.
• A caller lacks identity, client-surface, group, tenant, environment, agent, or policy context.
• Cedar policy denies discovery or execution. Deny overrides allow.
• An API operation was not selected, was not approved, fails host allowlist, fails schema validation, lacks a credential binding, exceeds size, or times out.
• A credential, connector, server, agent, or session is disabled or revoked.
• A doc claim lacks source truth. Mark it needs-source instead of turning it into product behavior.

V1 boundary

Current V1 behavior is governed MCP/API traffic with Rust control-plane and data-plane services, Go CLI and diagnostics, Cedar policy, PostgreSQL durable state, Valkey hot state, OpenTelemetry, Helm packaging, signed images, SBOM evidence, and customer-controlled audit export.

ClickHouse, NATS, Kafka, Redpanda, Terraform modules, a Kubernetes operator, managed MCP hosting, virtual MCP servers, broad local process governance, full DLP, ML detectors, and tamper-evident audit hash chains are outside the V1 default path unless a later roadmap page explicitly says otherwise.

Source truth

• VISION.md
• docs/ARCHITECTURE.md
• docs/engineering/taste-invariants.md
• docs/SECURITY.md

Next

• Read Admin Console Tour for the browser control-plane surface.
• Read Quickstart for the first governed-call proof path.
• Read Runtime Architecture for control-plane and data-plane boundaries.