By Nolan Sullivan, Founding Growth EngineerMCP gateway bypass
MCP gateway bypass is any route by which an AI agent reaches a Model Context Protocol (MCP) server, or the API behind it, without passing through the organization’s MCP gateway. The gateway’s authentication, tool policy, and audit log apply only to requests it receives, so a call that takes another route carries none of them.
An MCP gateway is the policy point between agents and tools. It authenticates the caller, decides which tools they may use, and logs every call. All of that assumes the call arrives. Connecting an agent to a server takes one line of client configuration, and Cloudflare describes how it usually happens: an employee finds a server in a repository, a product guide, or a message from a colleague and adds it to their MCP client directly. Nothing about that connection passes the gateway, and the gateway has no record that it exists.
A gateway governs the traffic it receives, so preventing MCP gateway bypass means making every other route fail, and each route is closed by a different layer. Two of those layers live in the gateway. The others live on the network, on the device, and at the upstream provider, and one route stays open whatever you deploy: a device the organization doesn’t manage.
How is MCP gateway bypass different from shadow MCP?
Shadow MCP is a connection to an MCP server the organization has not approved. The OWASP MCP Top 10 catalogs it as MCP09:2025 Shadow MCP Servers. Gateway bypass is the wider set. It includes every shadow MCP connection, and it also includes connections to approved servers that skip the gateway placed in front of them.
Cloudflare makes the same split in its August 2026 post on MCP detection. It calls the second case portal bypass: an approved server sits behind an MCP Portal, and an employee connects to its upstream URL anyway, skipping the Portal’s access policy, tool catalog, data loss prevention, and audit trail. Cloudflare’s conclusion is that shadow MCP needs a network control, while portal bypass needs that network control plus an origin that can reject direct requests.
Approving a server therefore doesn’t close the bypass. An organization can put every approved server behind a gateway and still find calls to those servers going direct, because the old client configuration still works. Shadow AI is the broader category again, covering models, agents, skills, and MCP servers used outside the security perimeter. This article covers only the routes around the MCP gateway.
Why can’t the gateway stop bypass by itself?
The gateway is a server, so it can refuse a request it receives but has no view of a request sent somewhere else. Three of the four bypass paths never produce a request to the gateway.
The local stdio path is the clearest case. The MCP transports specification defines stdio as a transport where the client launches the server as a subprocess and exchanges messages over standard input and output. A server configured that way runs entirely on the developer’s machine. If it calls an API, that call is ordinary HTTPS from the laptop to the API, with nothing in it that says MCP.
Direct remote connections and personal tokens are the same problem one step out. The request goes from the client to a server or API the gateway doesn’t front, so the gateway’s policy never runs. Unmanaged clients are the exception, because they do connect to the gateway. That makes them the one path a gateway can close at the point of connection.
Deploying a gateway gives approved use a governed path. The other layers make the ungoverned paths fail, or at least show up somewhere a security team can see them.
How do agents route around an MCP gateway?
Each path looks different in practice and leaves different evidence:
| Bypass path | What it looks like | What the gateway sees | Layer that closes it |
|---|---|---|---|
| Local stdio server | A client config entry that runs a command such as npx some-mcp-server | Nothing | Client hooks and device-level discovery |
| Direct remote URL | A server URL pasted into a client, either an unapproved server or the upstream address of an approved one | Nothing | Network egress policy, plus an origin that rejects direct requests |
| Personal token | A personal access token or API key in a client config or environment variable | Nothing | Credential custody at the gateway, plus provider token policy |
| Unmanaged client | An unreviewed MCP client, or a client switched to a personal account that dropped the organization’s plugins and hooks | An authorization from an unfamiliar client, which it may admit | Client admission at the gateway, plus device enrollment |
The personal-token path outlives the others. A user who connected a server directly last quarter may still hold the token. Removing the server from their client config doesn’t revoke it, and the shadow MCP guide makes the same point about closing findings: a config entry removed without addressing the credential leaves the connection easy to restore.
The unmanaged-client path has a quieter version that falls under configuration drift, which Speakeasy’s device agent documentation calls the most common bypass on developer laptops. A user switches their AI agent to a personal account and silently loses the organization’s plugins, telemetry, and guardrails. The client is the same one the organization approved, but its configuration is not.
How do you prevent MCP gateway bypass?
Five control layers cover the four paths: network egress, the origin server, credential custody, client admission, and device-level discovery. None covers every path, and each has a documented blind spot.
Network egress: block direct MCP traffic on managed paths
A secure web gateway sees HTTP traffic after it leaves the client, which makes it the widest view of remote MCP connections from managed devices. Cloudflare Gateway now classifies TLS-inspected requests as MCP when they carry the MCP-Protocol-Version header, and exposes that as a beta Is MCP selector in HTTP policies. Combined with a Traffic Source selector that marks requests proxied by an MCP Portal, one rule blocks MCP traffic that didn’t come through the Portal:
experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")Action: BlockDocker documents the same two-layer pattern for its sandboxes. Its MCP access policies govern only server registration and requests handled by Docker’s MCP gateway. A direct connection from inside a sandbox to a remote MCP server is outbound sandbox traffic, so Docker’s guidance is to block the server in MCP policy and block its network destination in network policy.
Egress control has three limits, and Cloudflare states all of them. Detection requires TLS decryption. Local stdio servers, off-network connections, and traffic exempted from inspection stay outside the view. And legacy MCP clients send their first initialize request without the protocol header, so the first request to a previously unknown endpoint may not be classified. An egress rule is therefore a control for managed devices on managed networks, and the rest of the stack has to assume it can be absent.
The origin: make direct requests fail at the server
An egress rule stops the request on the way out. A locked-down origin stops it on arrival, which also covers devices the egress proxy never sees. Cloudflare’s MCP server portal documentation is direct about why this layer is needed: users blocked by a portal’s Access policy can still connect to the server, and bypass that policy, by using its direct URL, unless Access is configured as the server’s OAuth provider.
For MCP servers the organization runs, the strongest origin control is to give the server no address anyone else can reach. An MCP tunnel lets the gateway reach a server inside a private network over an outbound-only connection, with no inbound port open. The server can also check that a request came through the gateway. Speakeasy’s private tunneled servers receive a short-lived signed JWT in an X-Speakeasy-Identity header on each forwarded request, which the server can verify and reject when absent.
Private networking on the client side is a separate decision with its own costs. A private MCP gateway takes the gateway’s own listener off the public internet, so only devices on the private network can reach it. That narrows who can reach the gateway, and it means hosted agents such as remote connectors in ChatGPT or Claude can’t reach it at all. On Speakeasy, private network access runs over a Tailscale tailnet, requires an Enterprise organization, and is set per server as public only, public and private, or private only. The private MCP gateway guide covers when that trade is worth making. Speakeasy runs as a managed gateway by default, and self-hosting is available for Enterprise customers (talk to our team).
For third-party SaaS servers, the origin belongs to the vendor, and the organization’s options depend on what the vendor exposes.
Credential custody: keep the token in the gateway
A direct connection to a SaaS MCP server works only if the user can authenticate to it. If the upstream credential lives in the gateway and never reaches the user, a direct connection has nothing to authenticate with. This is the cheapest layer to deploy, because it needs no software on any device.
The MCP security best practices already forbid token passthrough, where a server accepts a client’s token and forwards it upstream. Gateways implement the custody side in different ways. Kong’s AI MCP OAuth2 plugin, part of AI Gateway Enterprise, validates that each token was issued for the target MCP server and doesn’t forward client access tokens upstream by default. IBM’s ContextForge stores per-user OAuth tokens encrypted, keyed by gateway and user, and keeps header passthrough off unless an operator enables it.
Speakeasy’s gateway holds upstream credentials one of two ways: a token per user, obtained through the upstream’s OAuth flow, encrypted at rest and refreshed by the platform, or one shared credential per remote server, either a static key or an OAuth client credentials token. With Enterprise Managed Auth through Okta, the platform exchanges each person’s Okta identity for the downstream token, so there’s no per-service connect step and removing a person in Okta stops new access to every server that uses it.
Custody stops new tokens from reaching users. It does nothing about tokens users already hold or can still create, and that half belongs to the provider. GitHub, for example, lets an organization restrict access by personal access tokens and enable OAuth app access restrictions, so members can’t authorize unapproved OAuth apps against organization resources. A provider without equivalent controls leaves the personal-token path open, and the remaining options are rotation and detection.
Client admission: refuse unreviewed clients at the gateway
Client admission is the one bypass control that runs inside the gateway at connection time. The OAuth handshake is where the gateway learns which client is connecting, and with Client ID Metadata Documents (CIMD) the client’s ID is an HTTPS URL on its vendor’s domain. That URL is the same on every install, so the gateway can allowlist it, block it, and search for it.
Speakeasy exposes this as a per-server Client access setting with three options. Verified clients admits a catalog of client documents Speakeasy has checked plus any URLs the organization adds, Any client admits any valid document, and Off admits no CIMD client. Separately, Shadow AI records a decision per AI tool that enrolled devices report, and a tool marked Blocked is refused when it authenticates, on every MCP server in the organization.
Admission has real gaps, and the documentation states each one. Dynamic Client Registration (DCR) stays open to every client whatever the Client access setting says, and a Shadow AI block takes effect only for callers that present a CIMD client ID. CIMD verifies that a document belongs to its vendor, and doesn’t prove that the program on a user’s machine is genuine. Admission also gates new authorizations, not existing sessions, so cutting off a client that is already connected takes a revocation. And admission only covers clients that connect to the gateway, which none of the other three bypass paths do.
Device-level discovery: see what runs on the laptop
The device is the only place that can see a local stdio server. Cloudflare’s post lays out the trade clearly: a hook inside the MCP client runs before the request is serialized, can deny a server not on an allowlist, and covers stdio servers that never produce network traffic, but the controls have to be reproduced in every client employees use.
Two kinds of device software do this work. Hooks in the coding agent see each tool call, its server, and its arguments, which is how agent hooks catch calls to servers the gateway doesn’t host. A device agent installed through MDM inventories the AI tools on a machine and keeps the organization’s client configuration in place. Speakeasy’s device agent reapplies that configuration every 60 seconds, which is what closes the personal-account case above. It is in beta and enabled per organization. Docker takes a sandbox-side approach to the same problem: its MCP access policies can refuse registration of host-run stdio servers outright.
Discovery depends on enrollment, and Speakeasy’s Shadow AI documentation puts it in one line: a tool on an unenrolled machine appears nowhere. Shadow MCP detection has the same property, since sessions from an uninstrumented client produce no traffic to scan.
Which bypass paths can’t be closed?
Four gaps stay at least partly open whatever an organization deploys.
- Unmanaged devices. A personal laptop with no device agent, no hooks, and no managed proxy is invisible to three of the four layers. On that device, the organization’s only levers are credentials it holds centrally and restrictions it sets at each provider.
- Providers without token controls. If an upstream service lets any user mint an API key and offers admins no way to restrict it, a user can always reach that service directly. Custody at the gateway removes the convenient token but not the ability to create one.
- Off-network traffic. An egress rule covers traffic that passes the proxy. A device on a home network without the proxy client running sends direct MCP traffic the rule never evaluates.
- Tools without an MCP client. Some agents call APIs directly and never speak MCP. Speakeasy’s Shadow AI page notes that a decision about such a tool is recorded and never enforced, because there’s no MCP authentication for the gateway to refuse.
The strongest argument against investing here follows from this list. A determined person with a shell and an API key can always reach the API, and the shadow MCP guide warns that enforcing a policy before a workable alternative exists can push teams toward the bypass it’s meant to stop. Both points are correct, and they argue for a narrower goal: on managed devices with organization credentials, the direct path fails, and everywhere else, a direct connection shows up in an inventory with an owner.
In what order should you roll out bypass controls?
Ranked from least to most effort, with the path each step closes:
- Move upstream credentials into the gateway, and restrict personal tokens at providers that allow it. No endpoint software, and it closes the personal-token path for every provider whose credentials move. This is realistic for every organization.
- Turn on client admission. Set servers to admit verified clients, and record approve or block decisions for the AI tools you already know about. It closes part of the unmanaged-client path, for clients that publish a CIMD document.
- Run discovery in flag mode. Deploy hooks and the device agent, and let a flag-only policy build the inventory of stdio and direct remote servers before anything is blocked. Speakeasy’s shadow MCP allow and block lists guide describes this sequence, including the choice between a block-all and an allow-all posture.
- Lock down the origins you own. Move internal MCP servers behind tunnels, and have them verify the gateway’s signed identity header. Add private network access for the gateway endpoint if your clients all run on enrolled devices.
- Block direct MCP traffic at the egress proxy. This needs TLS inspection and a managed proxy on every device, which many organizations already run and many don’t. If you don’t have one, this step is a network rollout before it is a policy.
Each step makes the next one less disruptive. Credentials in the gateway mean a blocked direct connection has a governed alternative waiting, and an inventory built in flag mode means the first blocking policy is based on observed traffic instead of guesses.
A note on Speakeasy
Speakeasy runs a managed MCP gateway as part of the AI Control Plane. Of the layers above, it covers credential custody, client admission, and origin lockdown for internal servers through tunnels, and it pairs those with device-side discovery. Shadow AI is generally available under Guardrails for every organization. It lists the harnesses, assistants, and local models that enrolled devices report, and lets an admin approve or block each tool at the gateway. A blocked tool is refused when it authenticates, on every MCP server in the organization.
The limits are the ones described above. Enforcement needs the tool to publish a client ID metadata document. A tool with no MCP client gets a recorded decision and no enforcement. And a device that isn’t enrolled doesn’t appear. Blocking direct MCP traffic on the network is a job for a secure web gateway, such as Cloudflare’s, alongside the gateway.
If you’re mapping which of these paths are open in your organization today, we’d be interested to hear how you’re approaching it. Talk to us.