MCP without moving secrets — reverse federation

There's a trade at the heart of every managed MCP platform, and almost everyone makes it the wrong way.

You want to give a customer a governed MCP endpoint — one place their agents connect, with your policy, your audit, your rate limits in front of their tools. The tools reach the customer's data: a CRM, an internal database, a line-of-business API. To serve those tools from your cloud, the conventional answer is to bring the customer's credentials to your cloud — publish a config containing their secrets into a gateway you run. Now you're holding someone else's database password. That's a liability you didn't want, a compliance conversation you didn't need, and a blast radius that spans every tenant.

Reverse federation inverts the trade: the gateway runs where the secrets already are, and the secrets never move.

The inversion

Instead of copying secrets up to the cloud, the customer runs an MCPG gateway inside their own infrastructure — holding their credentials, their network access, their firewall. That gateway opens a private reverse tunnel: it dials out to a relay over a single outbound 443 connection and binds no public port. Nothing listens; nothing is exposed to the internet.

A gateway you run in the cloud then federates that tunnelled gateway over a tunnel:// upstream. It lists the customer's tools, re-exports them under your namespace, and applies your governance — identity, policy, audit — on every call. When a request comes in, it travels cloud gateway → relay → the private tunnel → the customer's gateway, which executes it against the CRM with credentials your cloud never saw.

  end user ──▶  cloud gateway  ──tunnel://acme-crm──▶  relay  ──▶  customer gateway
               (your policy,                                       (in ACME's VPC,
                no secrets)      re-exports ACME's tools           holds the creds)

The cloud is a governed aggregator. The secrets are sovereign. Both sides get what they actually want.

Why a byte tunnel isn't enough

"Isn't this just ngrok?" No — and the difference is the whole point.

ngrok, cloudflared, and OpenAI's MCP tunnel are byte pipes. They move bytes from A to B and stop there. They solve one leg — exposing a local server — and they're unaware of what's flowing through them. That leaves three gaps that matter for a governed platform:

• No identity in the policy chain. A byte tunnel forwards a request; it can't resolve the caller and enforce a rule on them. Reverse federation runs the full MCP request path on both sides: the end user's identity propagates through, minimum_trust and per-tool allow_if rules evaluate, and every call is audited.
• No inverse direction. Every consumer tunnel exposes a server outward. None of them run the direction that matters here — a gateway reaching an MCP server behind NAT and re-serving its tools under central control. That's the federation half, and it's the half no byte pipe offers.
• No private mode. A generic tunnel gives you a public URL and terminates your TLS at a third party. A private MCPG tunnel mints no public hostname at all — it's reachable only as an org-scoped federation upstream. The customer's attack surface is zero.

MCP is stateful and semantic — sessions, capabilities, streaming, server-initiated requests. Reverse federation carries all of that end to end. A byte pipe carries none of it.

What it unlocks

Once secrets stop being the thing you move, several hard problems soften:

• Managed governance over data you're not allowed to hold. Regulated customers can put a gateway in their own boundary and still get your central policy and audit over their tools. You never take custody of their credentials.
• A cleaner multi-tenant story. No per-tenant secret vault in your cloud, no cross-tenant blast radius from a leaked config. Each customer's tools stay behind each customer's tunnel.
• Reach into networks you can't route to. The customer's gateway dials out; you never need an inbound path into their VPC, no VPN peering, no firewall change on their side.

This is the pattern teams reach for once they've felt the weight of the alternative — a secrets store full of other people's credentials.

An honest note on the relay

In the shipping design, a public or relay_terminated tunnel means the relay sees plaintext — the same trust you extend any hosted tunnel provider. If your threat model says the relay must be blind, the honest answer today is to self-host the relay inside your own boundary rather than rely on end-to-end encryption: the e2ee mode is specified and plan-gated, but the ciphertext-splice data plane that would make the relay cryptographically blind is not yet shipped. We'd rather tell you that than let a mode name imply a guarantee it doesn't yet deliver.

Try it

Two commands and a federation block:

# Customer side — the gateway that holds the secrets, tunnelled privately
mcpg --config acme-gw.yaml --tunnel --private --tunnel-name acme-crm

# Cloud side — federate it by name, apply your governance
mcp:
  federations:
    - name: acme-crm
      governance: { minimum_trust: verified }
      upstream: { url: "tunnel://acme-crm/mcp" }
      import: { tools: true }
      naming: { tool_prefix: "acme." }

The reverse tunnels guide walks through the full setup, the two tokens, and the security model. MCP federation covers everything the cloud gateway can do with those re-exported tools — because a tunnel:// upstream is just a federation upstream that happens to reach a gateway with no front door.