Bring your own gateway. Keep the controls you built.

Point the runtime at the gateway your team already operates. Your allowlist, your identity, your audit trail, with composition and per-workspace scoping added on top.

Points at what you run

Your gateway is just a remote connection.

A gateway that speaks MCP is reachable the way any remote server is: Streamable HTTP or SSE, with OAuth discovery over the published standards. There is no adapter to write and no certification programme to join, because the protocol is the integration.

  • Streamable HTTP or SSE Whichever transport your gateway exposes. Both are first-class here.
  • Standards for auth OAuth discovery over RFC 9728 and RFC 8414, so your identity provider stays yours.
  • Direct also works No gateway is required. Point at a server you trust and hold the auth yourself.
Where the runtime sits: 1. Your gateway fronts the vendors, The allowlist, the credentials and the egress rules you already run.; 2. The runtime connects as a client, One more MCP consumer, subject to everything the gateway enforces.; 3. Tools reach the agent scoped, Composed into one namespace, then narrowed per workspace and per task.. The result: Nothing routes around you, The runtime cannot reach a vendor your gateway does not allow..
Nothing is taken over

You keep the layer you already got signed off.

The runtime is a consumer of your gateway, not a replacement for it. Whatever it enforces still gets enforced, because every call the agent makes arrives as an ordinary MCP request from an ordinary client.

  • No second allowlist Vendor policy stays in one place, and it stays in the place you audit.
  • No credential copy The gateway holds what it holds. We never need a copy to route around it.
  • Two records, not a gap Your gateway logs the call. We attribute it to a person and a workspace.
Your gateway keeps: Which vendors are reachable, The credential to each one, Network egress and rate limits, Your audit trail at that layer. The runtime adds adds: One namespace across every source, Which workspace sees which tools, Skills that narrow tools per task, Per-run attribution to a person. The two meet where the runtime holds a connection to your gateway. Everything it can reach, your gateway already allowed.
Works both ways

It is an MCP server as well as a client.

The runtime exposes its own MCP endpoint, so the hosts your team already uses can consume the composed toolset. Your gateway feeds the runtime; the runtime feeds Claude Code, Claude Desktop or Cursor, with the scoping intact.

  • One endpoint out Streamable HTTP at /mcp, with OAuth discovery for automatic client setup.
  • Composed, then scoped Local servers, remote servers and your gateway arrive as one toolset.
  • Same wall either way A session gets one workspace, whichever client opened it.
One workspace: Your gateway, Local servers, Your own, connected to each other. Another workspace sits outside that boundary with no connection into it. Not blocked. It has no name in this session.

Where you are starting from

Three ways teams arrive at this page.

The answer differs, and only one of them involves changing what you run.

Keep it. Point the runtime at it.

Your allowlist, identity integration and audit trail were work, and none of it is wasted. The runtime connects as one more client and inherits everything the gateway enforces, so the review your security team already did still holds.

How isolation works

Nothing to migrate

The gateway keeps its vendors, its credentials and its policy.

Nothing to re-review

The runtime cannot reach past what the gateway already allows.

You gain scoping

Per workspace and per task, which a gateway does not model.

MCP gateways

Questions people ask about gateways

Do we have to replace the gateway we already run?
No. The runtime connects to it as an ordinary MCP client over Streamable HTTP or SSE, so your allowlist, credentials, egress rules and audit trail stay exactly where they are. Everything the gateway enforces still gets enforced, because the agent has no path that goes around it.
Which gateways do you support?
Any that speaks MCP. The integration is the protocol rather than a per-vendor adapter, which is also why there is no certification list to be on. If your gateway exposes an MCP endpoint over Streamable HTTP or SSE, the runtime connects to it the way it connects to any remote server.
What does the runtime add that our gateway does not?
Composition and scoping. A gateway decides which vendors are reachable; it does not model which workspace or which task should see which tools. The runtime aggregates every source into one namespace, then narrows that namespace per workspace and per task through skills, and attributes each call to a person.
Do you need a copy of our credentials?
No. The gateway holds what it holds, and the runtime authenticates to the gateway rather than to the vendors behind it. Where a connection is direct instead, the credential sits with the workspace or the person that owns it and is never pooled.
Can our existing MCP clients use this?
Yes, and this is the half most people do not expect. The runtime is also an MCP server: it exposes a Streamable HTTP endpoint at /mcp with OAuth discovery, so Claude Code, Claude Desktop or Cursor can consume the composed toolset with the workspace scoping intact.
What happens when a downstream account expires?
This is the failure a broker hides: its own credential stays valid while the account behind it lapses, so the first symptom is a tool failing partway through a run. The runtime revalidates connections on a sweep and marks a lapsed one for re-auth, so it surfaces as a connection to fix rather than as a broken job.
Do we need a gateway at all?
No. Connect directly to servers you trust, or install from the built-in directory. A gateway earns its place once authorising each remote server yourself becomes the bottleneck, which is a threshold rather than a rule.

Put an agent layer on the gateway you already run.

Read the docs