Securing Remote MCP Servers

Securing Remote MCP Servers

Speakers: Jake Berkowsky

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=9-e4VVPlWB8

Overview

Jake Berkowsky, a principal architect and field CTO at Snowflake, delivered a pragmatic briefing on the security challenges of Model Context Protocol (MCP) servers -- the emerging standard for connecting AI clients like Claude Desktop, ChatGPT, and Cursor to external tools and data sources. Rather than chasing the sensationalist headlines about MCP vulnerabilities, Berkowsky focused specifically on server-side threats, transport layer security, authorization pitfalls, and why the enterprise should adopt a platform engineering approach to MCP deployment. The talk is notable for its honest assessment that MCP's client-side security model is essentially a return to the ActiveX era, where isolation guarantees we take for granted in web browsers simply do not exist.

Background

▶ Watch: MCP threat headlines vs. actual server-side risks (1:45)

MCP is a specification for writing APIs that are designed to be easily consumed by large language models. MCP servers can run locally (as executables on the same machine as the client) or remotely (accessed over the network). The protocol is transport-agnostic but defines common transports including Server-Sent Events (SSE) -- now deprecated -- and Streamable HTTP, a newer transport Anthropic introduced specifically for MCP. The specification is evolving rapidly; Berkowsky timestamped his talk to late June 2025 and warned that information could be outdated within weeks. The core challenge is that MCP represents a fundamental shift from the browser security model: instead of many websites isolated from each other with a few browser extensions, MCP inverts this to a few AI clients with many tool extensions that can all communicate with each other.

Key Findings

▶ Watch: npx/uvx boot-time execution and rapid compromise propagation (7:30)

Berkowsky identified several concrete security concerns specific to MCP servers that go beyond standard API security:

Local MCP servers propagate compromises faster than typical code. Since clients like Claude Desktop and Cursor re-download and execute MCP server code via npx (npm) or uvx (Python UV) every time they boot, a compromise of the source repository can propagate to every user the next morning. This is fundamentally different from code that gets deployed through a build pipeline on a controlled schedule.

SSE transport is deprecated but still widely used. Organizations should treat SSE-based MCP servers as a signal of potentially outdated dependencies. Streamable HTTP replaces the two-endpoint SSE model with a single POST endpoint but remains vulnerable to DNS rebinding attacks -- servers must validate origin headers.

OAuth implementation is the critical weak point. The MCP spec mandates OAuth and forbids token pass-through, but many implementations simply embed tokens in URLs or pass them around informally. The spec's security guidance consists largely of vague "must be mindful of security" directives. The confused deputy problem is particularly acute when third-party authorization servers are involved, as consent screens using cookies can allow an unauthorized MCP client to inherit permissions intended for a different client.

Session management requires deliberate engineering. MCP servers can assign session IDs, but these must be bound to users, generated with high entropy, and strictly enforced -- sessions without valid IDs must be dropped. Berkowsky specifically warned against using session IDs for authentication.

Technical Deep Dive

▶ Watch: OAuth misconceptions and the confused deputy problem in MCP (12:15)

Berkowsky's central architectural recommendation is to adopt a platform engineering approach using API gateways for MCP deployment. The reasoning is straightforward: OAuth is notoriously difficult to implement correctly, and leaving it to individual developers building MCP servers will inevitably result in vibe-coded authentication that introduces vulnerabilities. By centralizing authentication, session management, and logging at the gateway level, organizations can enforce consistent security controls across all MCP servers.

For session management, he proposed middleware that restricts which unique tools can coexist in a single session. This addresses both security and data governance concerns -- for example, preventing European data from comingling with US data when both are accessible through different MCP tools connected to the same client.

On the commercial tooling front, Berkowsky noted that Cloudflare, major cloud provider API gateways, Kong, and F5 all now support MCP. For Kubernetes deployments, Microsoft has released an open-source MCP gateway handling proxying to Kubernetes clusters. The Python ecosystem has FastMCP, though he warned that there are effectively three versions in circulation: the original 1.0 (now merged into Anthropic's official Python SDK and no longer separately maintained), the continued 2.0 with enterprise features, and the SDK-embedded version.

For logging and monitoring, Berkowsky emphasized that MCP's agentic nature means LLM clients may generate unexpected but valid requests -- for example, sending a parameter that is 5,000 characters long. Organizations need to log the full context: tokens, inputs, outputs, user identity, client identity, and server identity.

Demo / Proof of Concept

▶ Watch: Platform engineering approach using API gateways for MCP (15:45)

No live demo was performed. The talk was a pragmatic guidance session rather than a vulnerability demonstration.

Defensive Implications

▶ Watch: Logging and observability requirements for agentic MCP clients (19:30)

Organizations deploying MCP servers should first ask whether a local server (file-based, run via npx/uvx) would suffice instead of a remote deployment, as this reduces the attack surface to standard code security concerns. For remote MCP servers, defenders should deploy them behind existing API gateways rather than exposing them directly. OAuth should be handled at the platform level, never implemented per-server by individual developers. All MCP sessions should be bound, logged, and auditable. SAS and DAST scanning should run more frequently on MCP server code than on typical application code, given the rapid pace of development and the high-visibility nature of these tools. Finally, defenders should treat the MCP ecosystem with the same skepticism they would apply to any rapidly evolving protocol where the community is reinventing established security patterns from scratch.

Key Takeaways

• MCP's client-side security model is essentially ActiveX-era -- no isolation guarantees between tools; enterprise governance must happen at the platform level
• Local MCP servers propagate repository compromises at boot time via npx/uvx; scan code more frequently than usual
• Streamable HTTP replaces deprecated SSE but is vulnerable to DNS rebinding; always validate origin headers
• OAuth is mandated by the spec but poorly implemented in practice; use API gateways to centralize authentication
• Session IDs must be bound to users, high-entropy, and strictly enforced -- never use them for authentication
• Existing API gateway products (Cloudflare, Kong, F5, cloud-native gateways) already support MCP

About the Speaker(s)

Jake Berkowsky is a Principal Architect and Field CTO at Snowflake, where he builds and discusses security and observability data lakes. His background spans cloud architecture, software development, and running delivery for a cloud consultancy. He emphasized that the talk represented his personal opinions and was unrelated to his work at Snowflake.