What is a private MCP gateway?

By Nolan Sullivan, Founding Growth Engineer

·Published September 23, 2026

An MCP gateway is the one component every governed agent tool call passes through, which makes its exposure the exposure of every MCP server behind it. Most MCP gateways, hosted and self-hosted alike, listen on the public internet and rely on OAuth, and sometimes an IP allowlist, to keep strangers out. For many teams that’s a reasonable default. Organizations that already route employee traffic through a VPN or an overlay network have started asking why agent tool traffic should be the exception.

Anything that speaks MCP on a public address gets found. In 2025, Knostic used Shodan to identify 1,862 MCP servers exposed to the internet, and every one of the 119 it checked by hand listed its tools to an unauthenticated caller. Those were individual servers with no authentication, and a gateway that enforces OAuth is in a much stronger position. The study still shows how quickly a public MCP endpoint turns up in someone else’s scan results.

Where a gateway runs and who can reach it are separate decisions, and a private MCP gateway is defined entirely by the second. It says nothing about who operates the software or which building the hardware sits in, which is why it’s easy to confuse with self-hosted, on-prem, and tunneled deployments.

What is a private MCP gateway?

A private MCP gateway is an MCP gateway placed on a private network. It does the usual gateway job: it authenticates the MCP client, decides which tools the caller may use, and logs each call. The difference is where its listener sits. Because the gateway is only reachable inside the private network, the first check on any request is whether the caller can reach the gateway at all.

That produces two layers of policy, usually with different owners:

• The network layer decides who can open a connection, based on device enrollment and network access rules. The network or IT team typically owns it.
• The gateway layer decides what a connected caller may do, based on OAuth identity and per-tool permissions. The platform or security team typically owns it.

A public MCP gateway has only the second layer. A request to a private MCP gateway follows this path:

1. The gateway joins the private network and gets a private hostname. It has no public address, or its public hostnames refuse every request.
2. An agent on an enrolled device, such as a developer laptop or a CI runner, connects to that hostname over the private network. The network admits the device before any traffic reaches the gateway.
3. The gateway authenticates the MCP client, attaches the network identity where the network provides one, and checks policy for the tool being called.
4. The gateway forwards the call to an internal MCP server and writes it to the audit log.
5. A request from the public internet has nothing to connect to.

The strongest objection is that the gateway already authenticates every request, so hiding it adds little. OAuth 2.1 with PKCE is a strong scheme, and a public gateway that enforces it correctly is not an open door. But authentication runs after the gateway accepts a connection. A public listener exposes the TLS stack, the OAuth authorization and token endpoints, the protected resource metadata the MCP authorization specification requires servers to publish, and any request parsing that happens before a token is checked. A private listener limits that surface to devices the network has already admitted.

The trade is uneven. Moving the listener costs a network change and some client enrollment. A pre-authentication bug in a public gateway is an incident for every MCP server behind it.

How is a private MCP gateway different from a self-hosted one?

Self-hosted describes who operates the gateway. Private describes who can reach it. The two vary independently, and all four combinations exist:

A self-hosted gateway on a public load balancer is as exposed as any hosted one. A managed gateway can be private when the vendor puts it on the customer’s network. The two terms get conflated because the most common way self-hosters end up private is by deploying into a VPC with no public ingress, where the gateway is private by default. That privacy belongs to the deployment. A later change to the load balancer, the ingress controller, or DNS can make the same self-hosted gateway public again, which is why the exposure needs to be tested, not assumed.

An on-prem MCP gateway runs on hardware in the organization’s own facilities. That is a statement about location, and on-prem networks publish services to the internet all the time. On-prem gateways are often private in practice because the surrounding network is, but the posture still has to be configured and checked the same way.

Is a private MCP gateway the same as an MCP tunnel?

A private MCP gateway and an MCP tunnel cover opposite ends of the same path. An MCP tunnel is an outbound-only connection that lets a gateway or agent platform reach an MCP server inside a private network without opening an inbound port. It makes a private server reachable. A private MCP gateway keeps the gateway’s own listener off the public internet, so the path from agents to the gateway is private.

Each one alone leaves a gap. A tunnel terminating at a public gateway keeps the server hidden, but the gateway in front of it is still on the internet. A private gateway on one network doesn’t help reach servers in a different network it has no route to, which is the problem tunnels solve. Speakeasy’s private MCP gateway release describes running both together so that neither end touches the public internet.

What are the risks of a public MCP gateway?

A public MCP gateway is not insecure by default. The risks below come from what a public listener makes possible, and from how much then depends on every other control being right:

• It can be found. Anything that answers MCP requests on a public address shows up in internet-wide scans, as the Knostic study showed. A gateway hostname also tells an attacker where the organization’s tools are concentrated.
• Pre-authentication code is reachable by everyone. TLS termination, OAuth endpoints, discovery metadata, and request parsing all run before a token is validated. A bug in any of them can be exploited from anywhere on the internet.
• A stolen token works from any network. OAuth access tokens are bearer credentials. If one leaks from a laptop, a log file, or a compromised agent, it can be replayed from anywhere until it expires or is revoked. Against a private gateway, the attacker also needs a device the network admits.
• IP allowlists identify addresses, not people. An allowlist narrows who can connect, but the listener stays public and a request carries only a source IP. The organization also needs stable egress addresses for every client and a second list to keep in step with its network policy.
• Misconfiguration has no backstop. If the gateway’s authentication or allowlist is configured wrong, its MCP servers are exposed directly, because there is no second boundary behind it.

What are the benefits of a private MCP gateway?

The benefits mirror the risks, with one addition: identity from the network itself.

• Nothing to enumerate. With no public listener, there is no hostname for a scanner to find and no TLS handshake for a stranger to complete.
• Two independent checks. A caller must be admitted by the network and authenticated by the gateway. A stolen token without an admitted device, or an admitted device without a valid token, gets nowhere.
• User and device identity on each request. On overlay networks such as Tailscale, each connection carries the user, device, and tags it came from. The gateway can record that next to the tool call, so the audit trail answers “which machine made this call” as well as “which account.”
• One place for reachability rules. Who can reach the gateway lives in the network policy the organization already maintains, such as a tailnet ACL file or VPC security groups, instead of a separate allowlist in the gateway.
• No stable egress requirement. Laptops and CI runners don’t have to leave the network through fixed IP addresses to satisfy an allowlist.
• Fails closed. When public access is blocked independently of the private network, an overlay outage or a restart makes MCP servers unreachable, never exposed.

What does a private MCP gateway cost?

A private listener has real costs, and for some organizations they outweigh the benefits:

• Hosted agents can’t reach it. Agents that run on a vendor’s infrastructure, such as remote connectors in ChatGPT or Claude, call MCP servers from the vendor’s network, which isn’t on yours. Any MCP server those agents need has to keep a public path. This is why implementations that support private access usually let exposure be set per server rather than for the whole gateway.
• Every client needs network membership. Developer laptops, CI runners, and background agents all have to be enrolled in the private network. For an organization that already runs Tailscale or a corporate VPN everywhere, that’s close to free. For one that doesn’t, a private MCP gateway means rolling out a network before rolling out a gateway.
• The network becomes a dependency. Failing closed is a security property and an availability cost. An overlay outage takes agent tool access down with it.
• Identity providers usually stay public. OAuth flows to an external identity provider still need internet access. AWS notes this explicitly for private access to AgentCore Gateway. The gateway’s own OAuth endpoints also need to be served on the private hostname, or MCP clients can’t complete the authorization flow.
• Network access is not authorization. A device on the private network is not entitled to every tool. Tool permissions still belong in the gateway, and treating reachability as permission recreates the flat-network problem zero trust networking was meant to fix.

As a rule of thumb, if most of your agent traffic comes from hosted assistants calling public SaaS MCP servers, a public gateway with strong OAuth is the simpler choice. If most of it comes from agents on company devices calling internal systems, a private gateway fits the way the rest of your network already works.

How do you deploy a private MCP gateway?

There are three common patterns, ordered from least to most you operate yourself:

1. Join a managed gateway to your private network. The vendor runs the gateway and joins it to your overlay network as a node with a private hostname. This is the least operational work, but it only works with the networks the vendor has integrated with. Speakeasy’s Tailscale integration is this pattern.
2. Use a cloud gateway’s private endpoint. Cloud-provider gateways can expose a private endpoint inside your VPC. Amazon Bedrock AgentCore Gateway supports an interface VPC endpoint through AWS PrivateLink. Clients inside that cloud get a private path; clients elsewhere need a VPN or peering into the VPC.
3. Self-host behind an internal load balancer. Deploy the gateway in your VPC or data center with no public address and reach it over a VPN or overlay. You get full control of the network path and take on running the gateway, its upgrades, and its availability.

Whichever pattern you choose, the rollout follows the same steps:

1. Sort your callers. List which agents run on devices you manage and which run on vendor infrastructure. The second group decides which MCP servers must keep a public path.
2. Put the gateway on the network. Give it a stable private hostname, and serve the MCP endpoints, OAuth endpoints, and any discovery metadata there so clients can complete authorization without leaving the network.
3. Write the reachability rules. Decide which users, groups, and machine tags can reach the gateway, and express that in the network’s own policy. On Tailscale, a grant like the one below lets the engineering group and CI runners reach nodes tagged as the gateway on port 443.
4. Run both paths while clients move. Serve each MCP server on the public and private hostnames at once, repoint clients at the private hostname, and watch until traffic on the public path stops.
5. Close the public path and test from outside. From a machine that is not on the private network, the gateway’s public hostname should refuse the request or fail to connect. Repeat the test after load balancer, DNS, or ingress changes.
6. Keep tool permissions in the gateway. Network rules decide who can reach the gateway. The gateway still decides which tools each caller may use.

{
  "grants": [
    {
      "src": ["group:eng", "tag:ci"],
      "dst": ["tag:mcp-gateway"],
      "ip": ["tcp:443"]
    }
  ]
}

# Run from a machine that is not on the private network.
# Expect a connection failure or a 403, never a 200 or 401.
curl -sS -o /dev/null -w "%{http_code}\n" https://mcp.example.com/mcp

A 401 from the public hostname means the listener is still public and is only asking for credentials.

Which vendors support a private MCP gateway?

The list is short, and the products differ in shape. Each entry below covers only what the vendor documents.

Speakeasy

Speakeasy’s MCP gateway can run on a customer’s Tailscale tailnet at a stable private hostname, through a feature called private network ingress that Speakeasy announced in September 2026. An org admin connects the tailnet with a scoped Tailscale OAuth client, and the gateway joins as a node. Each MCP server is then set to public-only, dual, or private-only. In private-only mode, the platform host and the organization’s custom domain return a 403 on every public route, and that block doesn’t depend on the tailnet being up, so a Tailscale outage or misconfiguration leaves servers unreachable rather than exposed.

A per-organization attestor forwards only the allowlisted MCP and OAuth paths and attaches the Tailscale user, device, and tags to each request, which then appear in the audit log next to the tool that was called. The MCP endpoint, its OAuth endpoints, and its install page are all served at the private hostname. Paired with Speakeasy’s MCP tunnels for servers inside the network, an agent can reach a private MCP server without either end on the public internet.

Private network ingress is rolling out per organization and is enabled on request. Tailscale is the only overlay network supported today; others are on the roadmap. Per-server authorization using Tailscale ACL capability grants is in development and not yet available.

Tailscale Aperture

Aperture is Tailscale’s proxy for LLM and MCP traffic on a tailnet. It aggregates tools and resources from configured remote MCP servers behind a single /v1/mcp endpoint and identifies the caller from the tailnet connection, so requests must come from inside the tailnet and need no separate authorization header. Access is deny-by-default: grants in the Aperture configuration decide which users can list and call which tools. For an organization that has standardized on Tailscale and wants MCP tool access expressed in the same grants model as the rest of its network, Aperture is a more direct fit than a separate gateway.

Amazon Bedrock AgentCore Gateway

AgentCore Gateway documents private paths on both sides. For inbound traffic, an interface VPC endpoint through AWS PrivateLink gives callers inside a VPC a private route to the gateway. For outbound traffic, a VPC Lattice private endpoint on a gateway target reaches self-hosted MCP servers inside a VPC. AWS notes that OAuth token retrieval with external identity providers, and access to tools hosted outside AWS, still need internet connectivity. It’s the natural option for agents that already run inside AWS.

MintMCP

MintMCP documents two ways to reach MCP servers inside a private network: a private network replica deployed in the customer’s VPC that connects outbound, and an outbound-only tunnel to a reverse proxy. Both keep internal MCP servers off the public internet, with traffic flowing from the MCP client to MintMCP’s policy gateway and then through the replica to the internal server. That is the MCP tunnel pattern, covering the server side of the path. The documentation we reviewed doesn’t describe putting the policy gateway’s own listener on a private network.

Building it yourself

Any MCP gateway you can self-host can be made private by deploying it behind an internal load balancer with no public address and reaching it over a VPN or overlay network. This is the third deployment pattern above, with the same trade: full control of the network path, and full responsibility for the gateway.

If you’re working out which of your MCP servers can come off the public internet and which need to stay reachable for hosted agents, we’d be interested to hear how you’re drawing that line. Talk to us.