Cloudflare One can now connect MCP server portals to servers that exist only on a private network, removing the need to expose the MCP service itself to the public internet.
The network path Cloudflare now supports
Cloudflare private MCP servers can use private hostnames or IP addresses. An administrator connects the network with Cloudflare Tunnel, Cloudflare Mesh or another Cloudflare One connector. The MCP portal then sends traffic through Cloudflare Gateway to the configured private route.
The change is useful for internal databases, deployment tools and operational systems that should not receive direct public traffic. Users and agents can connect through one controlled portal while the upstream MCP server stays on a private address.
Private does not mean every endpoint is private
| Component | Required exposure | Reason |
|---|---|---|
| MCP server | Private hostname or IP is supported | Portal reaches it through Gateway |
| OAuth authorization endpoint | Public internet | Users must complete authorization |
| OAuth token endpoint | Public internet | The portal needs to exchange or refresh tokens |
| Dynamic Client Registration endpoint | Public when Cloudflare registers automatically | The portal must create the OAuth client |
| Private network route | Cloudflare connector | Gateway needs a path to the upstream server |
This is the most important configuration caveat. The upstream tool server can stay private, but the identity plane still needs public endpoints in the documented OAuth flow.
What changes in the threat model
Removing a public MCP endpoint reduces unauthenticated scanning and direct exploitation opportunities. It also centralizes access policy and logging. But an authorized portal can still reach a powerful internal service, so compromised identities, excessive scopes and unsafe tool behavior remain material risks.
- Limit each MCP server to the smallest private route.
- Require user or service identity at the portal.
- Constrain upstream credentials by tool and resource.
- Log tool discovery separately from tool execution.
- Use approval for destructive or high-radius actions.
- Test what happens when Gateway, OAuth or the connector fails.
A reference deployment sequence
- Place the MCP server on an internal hostname or address that is not publicly routed.
- Connect its network with Tunnel, Mesh or the connector appropriate to the environment.
- Publish the private hostname or CIDR route to Cloudflare Gateway.
- Add the MCP server to the portal and enable Route traffic through Cloudflare Gateway.
- Configure public OAuth endpoints and a registered client or DCR flow.
- Apply Access and Gateway policies to the portal, user and destination.
- Verify discovery, authorization, execution, revocation and logs with a low-privilege test identity.
How this differs from simply adding a reverse proxy
A reverse proxy can hide an origin address, but the origin is still normally reachable through an internet-facing service. Cloudflare’s private route keeps the MCP server on a private network and uses its connector and Gateway control plane to reach it. The portal can also aggregate servers and present a governed tool surface to clients.
The architecture resembles a service access layer more than a public API gateway. That makes routing and identity policy easier to centralize, but it also makes the portal an important security dependency.
What teams should test before production
Create an acceptance test that covers more than a successful tool call. Confirm that the private host is not reachable from the public internet, revoked users lose portal access, expired tokens fail cleanly, DCR cannot register unauthorized clients and Gateway policies block disallowed destinations. Verify that tool results cannot expose credentials or data outside the user’s scope.
Our OpenAI MCP tunnel guide covers another private-connectivity pattern. The managed browser MCP guide shows why reachability and permission boundaries must be evaluated separately.
The practical verdict
Cloudflare’s update removes a real deployment obstacle for enterprises that want MCP access without a public tool server. The boundary is narrower than the headline: OAuth endpoints stay public, and private networking does not validate tool semantics. Use the portal as one layer in a design that also includes least privilege, approval, observability and server-side authorization.
The best rollout is intentionally small. Start with one read-only server, one identity group and one narrowly scoped destination policy. Capture denied as well as allowed requests, test token revocation and document which public OAuth surfaces remain reachable. Only then add write-capable tools. That sequence helps administrators distinguish network reachability, identity, tool authorization and human approval as four separate controls instead of assuming the private route solves all of them.
Primary sources
- Cloudflare: Private MCP server support
- Cloudflare: Connect a private MCP server
- Cloudflare: MCP server portals
Checked September 23, 2026. Feature behavior is confirmed by Cloudflare documentation; plan eligibility and configuration requirements can change.
