Restructuring MCP for enterprise-scale AI adoption
As agentic workflows move from engineering experiments into everyday business operations, the security perimeter around Model Context Protocol (MCP) deployments has become a central concern. Authorization sprawl, prompt injection, and supply chain risks all grow as more employees connect AI assistants to internal systems. The answer is not to restrict access, but to centralize how MCP servers are deployed, governed, and monitored.
Cloudflare’s internal rollout of MCP provides a working model for this approach. Their architecture relies on remote MCP servers hosted on Cloudflare’s developer platform, combined with Cloudflare Access for authentication, MCP server portals for discovery and policy enforcement, and Cloudflare One’s security tools for monitoring. The key insight is that separating the MCP client from the MCP server creates a clean boundary: the AI application integrated at the client never holds credentials for corporate resources, which remain locked behind the server.<\/p>
Why remote MCP servers beat local deployments
The initial wave of MCP adoption at Cloudflare relied on locally-hosted MCP servers. That approach proved untenable. Local servers depend on unvetted software sources and versions, creating supply chain and tool poisoning risks. They also bypass IT administration entirely, leaving individual employees responsible for choosing, updating, and securing their own servers.
Cloudflare’s solution was to create a centralized team managing enterprise MCP servers from within a shared monorepo. When an employee wants to expose an internal resource, they request approval from the AI governance team, then copy a template, define their tools, and deploy. The scaffolded infrastructure includes default-deny write controls, audit logging, auto-generated CI/CD pipelines, and secrets management. The result is that governed MCP server deployment takes minutes instead of weeks, because the security controls are baked into the platform.
Authentication and visibility for private and public servers
The centralized deployment model also simplifies authentication. Public-facing MCP servers, like Cloudflare’s documentation and Radar servers, remain open to anyone. But private corporate resources are fronted by Cloudflare Access, which acts as the OAuth provider. It aggregates identity from single sign-on (SSO) and multifactor authentication (MFA), while also checking contextual signals such as IP address, location, and device certificates.
MCP server portals: discovery, policy, and logging in one place
As the number of remote MCP servers grew, discovery became the next bottleneck. Employees—especially those new to MCP—needed a simple way to find the servers available to them. MCP server portals solve that by acting as a single connection point: an employee connects their MCP client to the portal, which then reveals every internal and third-party server they are authorized to use.
Portals add more than convenience. They centralize logging, allow administrators to set data loss prevention (DLP) rules that restrict sensitive data like personally identifiable information, and enable fine-grained policy controls over both portal access and tool exposure. For example, one portal might be limited to the finance group and expose only read-only tools from a code repository server, while a separate portal for the engineering team on corporate laptops could expose read/write capabilities.
The architecture is notably performant because all components—the portal, Cloudflare-hosted remote MCP servers, and Cloudflare Access—run on the same physical machine within Cloudflare’s network. Traffic never leaves that machine, making the full security and networking stack effectively co-located.
Cutting token costs with progressive tool disclosure
The standard MCP pattern of exposing one tool per API operation becomes expensive at scale. Platforms with thousands of endpoints force agents to absorb massive tool schemas into their context windows on every request. Cloudflare previously addressed this for its own API with a "Code Mode" pattern, exposing thousands of endpoints via just two tools: a search tool and an execute tool. The model writes JavaScript to discover what it needs on demand rather than loading everything upfront.
That pattern is now available for MCP server portals. Instead of sending every tool definition from every connected upstream server to the client, the portal exposes two tools:
portal_codemode_search— provides acodemode.tools()function that returns all tool definitions from connected upstream servers, letting the model filter through them with JavaScript.portal_codemode_execute— provides acodemodeproxy object where each upstream tool can be called as a JavaScript function, supporting chained operations and error handling in code.
The code execution runs in a sandboxed environment on the portal via Dynamic Workers. A typical workflow—locating a Jira ticket and updating it from Google Drive—becomes two tool calls instead of a full schema download plus three separate invocations.
// portal_codemode_search
async () => {
const tools = await codemode.tools();
return tools
.filter(t => t.name.includes("jira") || t.name.includes("drive"))
.map(t => ({ name: t.name, params: Object.keys(t.inputSchema.properties || {}) }));
}
// portal_codemode_execute
async () => {
const tickets = await codemode.jira_search_jira_with_jql({
jql: ‘project = BLOG AND status = “In Progress”’,
fields: [“summary”, “description”]
});
const doc = await codemode.google_workspace_drive_get_content({
fileId: “1aBcDeFgHiJk”
});
await codemode.jira_update_jira_ticket({
issueKey: tickets[0].key,
fields: { description: tickets[0].description + “\n\n” + doc.content }
});
return { updated: tickets[0].key };
}
Measuring the savings
Cloudflare quantified the benefit: connecting their internal portal to just four MCP servers exposes 52 tools that consume roughly 9,400 tokens of context for definitions. With Code Mode enabled, those collapse into 2 portal tools consuming about 600 tokens—a 94% reduction. Critically, this cost remains constant even as more servers are connected, since only the two portal tools are ever advertised to the client.
Code Mode is activated by adding a query parameter to the portal URL: append ?codemode=search_and_execute to the standard endpoint, e.g. https://myportal.example.com/mcp?codemode=search_and_execute.
Bringing it together: a unified governance stack
Cloudflare’s internal architecture combines several layers: centrally managed remote MCP servers for software supply chain control, Cloudflare Access for authentication and contextual policy, MCP server portals for discovery and DLP enforcement, and Code Mode for token efficiency. Together these provide a governance model where security controls are inherited from the platform rather than bolted on per deployment. This reference architecture also highlights two additional capabilities: Code Mode with MCP server portals to reduce token costs, and Cloudflare Gateway for shadow MCP detection—which surfaces unauthorized remote MCP servers connecting into the corporate network. The full picture is a model for enterprises looking to adopt agentic workflows without leaving security or cost to chance.
Cost Controls and Provider Flexibility
The connection between the MCP client and the LLM itself also needs management. By inserting our AI Gateway into this path, we gain the ability to switch between LLM providers without major architectural changes, which helps prevent vendor lock-in. The same layer gives us granular cost controls, such as limiting the number of tokens each employee can consume.
Detecting Unauthorized MCP Servers
Governed access for approved MCP servers only solves half the problem. Enterprises also need visibility into unauthorized servers that employees may connect to directly. Cloudflare Gateway, our secure web gateway, provides that visibility by scanning traffic for signs of shadow MCP usage.
Through the Cloudflare Gateway API, we can run multi-layer scans to find remote MCP servers that bypass the MCP server portal. This is done with a combination of existing Gateway and Data Loss Prevention (DLP) selectors:
- Using the Gateway
httpHostselector to look for known MCP hostnames (likemcp.stripe.com) or anymcp.*subdomain with wildcard patterns. - Using the Gateway
httpRequestURIselector to identify MCP-specific paths such as/mcpand/mcp/sse. - Using DLP body inspection to catch MCP traffic even when the URL contains no obvious markers. Since MCP relies on JSON-RPC over HTTP, every request includes a
methodfield with values liketools/call,prompts/get, orinitialize. Regex rules can flag these patterns within HTTP bodies.
const DLP_REGEX_PATTERNS = [
{
name: "MCP Initialize Method",
regex: '"method"\\s{0,5}:\\s{0,5}"initialize"',
},
{
name: "MCP Tools Call",
regex: '"method"\\s{0,5}:\\s{0,5}"tools/call"',
},
{
name: "MCP Tools List",
regex: '"method"\\s{0,5}:\\s{0,5}"tools/list"',
},
{
name: "MCP Resources Read",
regex: '"method"\\s{0,5}:\\s{0,5}"resources/read"',
},
{
name: "MCP Resources List",
regex: '"method"\\s{0,5}:\\s{0,5}"resources/list"',
},
{
name: "MCP Prompts List",
regex: '"method"\\s{0,5}:\\s{0,5}"prompts/(list|get)"',
},
{
name: "MCP Sampling Create Message",
regex: '"method"\\s{0,5}:\\s{0,5}"sampling/createMessage"',
},
{
name: "MCP Protocol Version",
regex: '"protocolVersion"\\s{0,5}:\\s{0,5}"202[4-9]',
},
{
name: "MCP Notifications Initialized",
regex: '"method"\\s{0,5}:\\s{0,5}"notifications/initialized"',
},
{
name: "MCP Roots List",
regex: '"method"\\s{0,5}:\\s{0,5}"roots/list"',
},
];
The Gateway API enables further automation. A custom DLP profile can block traffic, redirect it, or simply log and inspect MCP payloads. With this setup, Gateway offers comprehensive detection of remote MCP servers accessed over the enterprise network. For a full build-out guide, see our tutorial on detecting MCP traffic with Gateway logs.
Securing Public-Facing MCP Endpoints
Internal workforce protection is only one part of the strategy. Many organizations, including Cloudflare, also expose public-facing MCP servers that let customers manage products agentically. These servers live on our developer platform, with individual MCPs available for specific products. For broader API access, we reference Code Mode as a more efficient alternative.
Publishing official first-party MCP servers matters. The alternative is customers pulling unvetted servers from public repositories where packages may carry dangerous trust assumptions, hidden data collection, or other unsanctioned behavior. First-party servers let you own the code, update cadence, and security posture.
Every remote MCP server is still just an HTTP endpoint, so it can sit behind our Web Application Firewall (WAF). Enabling the AI Security for Apps feature lets the WAF automatically inspect inbound MCP traffic for prompt injection attempts, sensitive data leakage, and topic classification. Public MCPs are then protected like any other web API.
A Path Forward for Enterprise MCP Adoption
Our own MCP workflows are secured through a combination of controls:
- A templated framework for developers to build and deploy remote MCP servers on our platform, with Cloudflare Access handling authentication.
- Identity-based access to authorized MCP servers across the entire workforce via MCP server portals.
- AI Gateway mediating LLM access to manage token consumption and costs, with Code Mode in portals reducing context bloat.
- Cloudflare Gateway discovering shadow MCP usage that bypasses approved channels.
For organizations charting their own MCP adoption, the recommended starting point is placing existing remote and third-party MCP servers behind MCP server portals and enabling Code Mode. That combination addresses the core challenges of cost, security, and operational complexity in enterprise MCP deployments.
