Remote MCP Servers: Connecting and Securing SaaS-Hosted Servers Through One Gateway

TL;DR

• Remote Model Context Protocol (MCP) servers move tool execution from local processes to cloud and SaaS environments over Streamable HTTP and Server-Sent Events (SSE).
• Direct connections between AI desktop clients and remote MCP endpoints create severe security blind spots, including credential sprawl, uninspected payloads, and shadow tool proliferation.
• A dedicated gateway consolidates upstream remote MCP connections into a single governed endpoint, enforcing token-level access controls and rate limits.
• Bifrost acts as both an MCP client and server, routing tool calls through virtual keys while adding sub-millisecond routing overhead.
• Deploying Bifrost Edge ensures endpoint developer tools like Cursor and Claude Code route SaaS tool traffic through central gateway policies automatically.

Connecting autonomous agents and AI assistants to external systems requires reliable tool interfaces. The Model Context Protocol (MCP), open-sourced by Anthropic, establishes an open standard for bridging language models with external data sources, code interpreters, and third-party SaaS services. While initial MCP adoptions centered on local processes communicating over standard input/output (stdio), production enterprise architectures increasingly run remote MCP servers hosted across managed cloud infrastructure. Managing dozens of direct client-to-server connections across multiple developer machines quickly becomes unmaintainable. Bifrost, a high-performance open-source AI gateway written in Go, provides a centralized architecture to aggregate, secure, and govern remote MCP servers through a single control plane.

The Architectural Shift from Local to Remote MCP Servers

Local MCP servers operate as subprocesses launched directly on a developer workstation or runtime host via stdio transport. In this model, an AI client (such as Claude Desktop or Cursor) forks a child process (for example, a Node.js script or a Python container) and exchanges JSON-RPC 2.0 messages over standard input and standard output streams. This design works well for isolated desktop experimentation, but it fails to scale when tools require enterprise credentials, shared state, heavy compute dependencies, or multi-tenant authorization.

Remote MCP servers solve these operational limits by hosting tool logic on cloud infrastructure or directly inside SaaS platforms like GitHub, Linear, Notion, and Slack. Instead of executing binaries locally, AI clients communicate with remote endpoints over networked transports:

1. Server-Sent Events (SSE): The legacy HTTP transport introduced in early protocol specifications, utilizing persistent HTTP GET streams for server-to-client events alongside separate POST endpoints for client-to-server messages.
2. Streamable HTTP: The modern transport standard introduced in the 2025 MCP specification revisions, using bidirectional streaming over a single unified HTTP endpoint to reduce connection state overhead and simplify firewall traversal.

Hosting tools remotely decouples the agent runtime from the tool infrastructure. Engineering teams can deploy tools as serverless functions, microservices within a Kubernetes cluster, or multi-tenant SaaS extensions without requiring end users to install runtimes, Python packages, or database drivers on their local machines.

The Security and Operational Risks of Direct Remote MCP Connections

Connecting client applications directly to remote MCP servers introduces significant architectural liabilities for enterprise environments. Because MCP tools execute actions against production databases, code repositories, and communication systems, ungoverned remote access creates severe threat vectors across the entire infrastructure perimeter.

+-----------------------------------------------------------------------+
|                 RISKS OF DIRECT REMOTE MCP ACCESS                     |
+-----------------------------------------------------------------------+
|  [Developer Client]  ----(Direct API Key / OAuth)----> [Cloud SaaS]   |
|         |                                                             |
|         +---> Credential Exposure (tokens stored on laptops)          |
|         +---> Unaudited Execution (tool inputs/outputs invisible)     |
|         +---> Blast Radius Expansion (agent accesses all tools)       |
|         +---> Token Bloat (giant tool schemas consume context)        |
+-----------------------------------------------------------------------+

Direct peer-to-peer connections between developer workstations and remote servers introduce several critical vulnerabilities:

• Credential Sprawl and Secret Exposure: When developers connect their desktop clients directly to remote SaaS servers, long-lived personal access tokens (PATs) or OAuth refresh tokens are stored in plain text configuration files across individual laptops.
• Complete Lack of Auditability: Security teams cannot monitor which prompts triggered specific tool calls, what parameters were supplied, or what sensitive data was returned in the payloads.
• Unrestricted Tool Visibility: Most SaaS-hosted MCP servers expose their complete suite of capabilities by default. An agent tasked with reading an issue ticket may also receive tools capable of deleting repositories or modifying access permissions.
• Context Window Exhaustion: Registering multiple remote MCP servers floods the LLM context window with tool definitions. Passing dozens of detailed JSON schemas on every inference turn drives up latency and API costs exponentially.
• Zero Perimeter Defense: Without an intermediate proxy, security mechanisms like data loss prevention (DLP), secrets redaction, and egress firewalls cannot inspect or intercept malicious tool inputs or prompt injections.

Core Architecture: Brokering Remote MCP Traffic Through an AI Gateway

A centralized AI gateway resolves perimeter fragmentation by inserting an intelligent, low-latency control plane between MCP clients and upstream MCP servers. In this topology, client applications interact with a single endpoint, while the gateway manages discovery, authentication, network transport, and payload verification for all upstream SaaS services.

Bifrost implements this pattern by functioning simultaneously as a high-performance MCP client to upstream tools and an MCP server to downstream AI applications. Downstream clients connect to Bifrost via standard HTTP or SSE endpoints (typically exposed at /mcp). When a client initiates a handshake, Bifrost queries its upstream tool inventory, aggregates available tool definitions based on the client's permission profile, and presents a curated list of tools.

+--------------------------------------------------------------------------------+
|                        BIFROST MCP GATEWAY ARCHITECTURE                        |
+--------------------------------------------------------------------------------+
|  [Clients]              [Bifrost Control Plane]               [Remote Servers] |
|                                                                                |
|  Claude Code   \                                            /-> GitHub SaaS    |
|  Cursor IDE     ===> [ Unified /mcp Endpoint ]             +--> Linear SaaS    |
|  Custom Agents /     | - Virtual Key Verification          \--> Internal DB    |
|                      | - Tool Filtering & Access Profiles   \-> Custom Microservice
|                      | - Prompt Guardrails & Audit Logs                        |
+--------------------------------------------------------------------------------+

When an agent selects a tool for execution, the request flows to the gateway rather than the upstream host. Bifrost inspects the JSON-RPC invocation, verifies that the requesting consumer is authorized to call that specific tool, strips or injects credentials dynamically, and forwards the call to the appropriate remote server. The response passes through the gateway for observability logging, schema validation, and sensitive data masking before returning to the model.

Because Bifrost is compiled in Go and optimized for high-concurrency event loops, it handles this mediation with negligible performance impact. In sustained benchmarks at 5,000 requests per second, the gateway introduces as little as 11 microseconds of overhead per request, ensuring that centralized governance does not create a latency bottleneck.

Protocol Transports: Streamable HTTP vs. Server-Sent Events

Modern MCP architectures rely on standard web protocols to transmit JSON-RPC payloads across public networks. Understanding the functional differences between transport options is necessary when designing secure infrastructure for SaaS tool integration.

The original remote transport defined in protocol version 2024-11-05 relied on dual-endpoint Server-Sent Events (SSE). Under this mechanism, the client opens a persistent GET connection to receive a server stream and sends JSON-RPC commands through independent HTTP POST requests. While functional, SSE requires maintaining long-lived TCP sessions across reverse proxies and stateful load balancers, making connection recovery difficult when connections drop.

To resolve these stateful limitations, the 2025-03-26 MCP specification introduced Streamable HTTP. Under Streamable HTTP, all communications occur over a single HTTP endpoint supporting both POST and GET verbs. Clients send requests as standard HTTP POST operations, receiving responses either as standard JSON-RPC payloads or as streaming chunks using the text/event-stream format when incremental execution updates are required.

Transport Feature	Local stdio	Remote SSE (2024-11-05)	Streamable HTTP (2025-03-26)
Network Scope	Local host only	Cloud / SaaS / WAN	Cloud / SaaS / WAN
Endpoint Design	Standard I/O pipes	Dual (/sse and /messages)	Single unified endpoint
Session Model	Process lifecycle	Stateful persistent stream	Stateless or resumable sessions
Proxy Compatibility	Not applicable	Requires custom buffer tuning	Native HTTP reverse proxying
Authentication	Environment variables	HTTP Headers / OAuth	Standard HTTP Authorization headers
Scalability	Single machine	Limited by open sockets	Highly horizontally scalable

Bifrost accommodates both modern Streamable HTTP and legacy SSE transports across upstream and downstream connections. This bidirectional compatibility ensures that platform engineers can connect newly published SaaS endpoints while continuing to support earlier MCP client runtimes without code modifications.

Authentication and Authorization Patterns for Remote SaaS Tools

Securing remote MCP servers requires decoupling client identity from upstream service identity. When an engineering team relies on multiple external platforms, asking developers to authenticate independently to each service creates administrative gridlock and invalidates zero-trust security postures.

A production-ready MCP gateway addresses authentication across two distinct boundaries: downstream client-to-gateway authorization and upstream gateway-to-server authentication.

+------------------------------------------------------------------------------------+
|                         MCP AUTHENTICATION BOUNDARIES                              |
+------------------------------------------------------------------------------------+
| [Client]  ---(Bearer Virtual Key)---> [ Bifrost Gateway ] ---(OAuth 2.0 / PAT)---> [SaaS Server]|
|                                                                                    |
| Identity: Developer or Service        Control: Token Mapping & Scopes              Identity: Enterprise Service Account
+------------------------------------------------------------------------------------+

Downstream Authentication: Virtual Keys

Clients authenticate to Bifrost using virtual keys. A virtual key is an internal credential generated by the gateway that maps an inbound request to a specific team, budget, rate limit, and set of tool permissions. Instead of configuring developer environments with API keys for GitHub, Linear, and internal databases, developers receive a single Bifrost virtual key.

Upstream Authentication: OAuth 2.0 with PKCE and Vault Storage

When communicating with remote SaaS MCP servers, the gateway handles upstream authentication through several standardized patterns:

1. Enterprise Service Accounts: The gateway retrieves centralized API credentials from secret management systems such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, injecting them into outbound HTTP requests automatically.
2. Dynamic OAuth 2.0 with PKCE: For SaaS providers requiring per-user or tenant-level authorization, the gateway implements OAuth 2.0 flows with Proof Key for Code Exchange (PKCE) and automatic token refresh. The gateway stores refresh tokens securely, preventing sensitive credentials from reaching client machines.
3. Protected Resource Metadata (PRM): Following the updated MCP authorization specification, the gateway inspects upstream 401 Unauthorized responses containing PRM documents, facilitating automated token acquisition against upstream identity providers.

By abstracting these flows, engineering teams can configure Bifrost with federated authentication, turning internal enterprise microservices and protected SaaS endpoints into governed MCP tools without writing custom authentication wrappers.

Granular Governance: Tool Filtering and Virtual Keys

Exposing every tool registered across dozens of SaaS servers to every user degrades model accuracy and exposes critical systems to unintended actions. If an AI coding agent is connected to a Jira server, a GitHub server, and a production PostgreSQL server, a prompt injection or hallucination could cause the model to invoke destructive database operations instead of browsing tickets.

Bifrost enforces MCP tool filtering directly at the gateway layer. Administrators define strict allow-lists and deny-lists that bind directly to virtual keys, teams, or operational roles.

+-------------------------------------------------------------------------+
|                    BIFROST TOOL FILTERING PIPELINE                      |
+-------------------------------------------------------------------------+
| Upstream SaaS Inventory:                                                |
| [github_search, github_commit, linear_create_issue, db_drop_table]      |
|                                 |                                       |
|                                 v                                       |
| Bifrost Virtual Key Rules:                                              |
| Virtual Key: `vf-dev-frontend-102`                                      |
| Allowed: ["github_search", "linear_create_issue"]                       |
| Denied:  ["github_commit", "db_*"]                                      |
|                                 |                                       |
|                                 v                                       |
| Exposed to Client Context:                                              |
| Only [github_search, linear_create_issue] visible to the LLM             |
+-------------------------------------------------------------------------+

By applying granular filtering, Bifrost ensures that:

• Agents See Only Relevant Schemas: Tools outside the virtual key's allow-list are excluded from the client handshake, preserving context window tokens and minimizing attention dispersion.
• Unauthorized Executions Are Blocked Instantly: If an agent attempts to execute a restricted tool (for example, by predicting a known function name), the gateway intercepts the JSON-RPC request and returns a structured permission failure without forwarding traffic upstream.
• Tool Groups Standardize Access: Administrators can bundle individual capabilities into MCP tool groups, allowing platform teams to grant read-only developer bundles or operational SRE bundles across multiple remote servers with a single policy assignment.

Beyond routing and tool access policies, Bifrost applies centralized governance and security controls (virtual keys, budgets, guardrails, and audit logs) across all traffic, and Bifrost Edge extends that same governance and security to AI traffic on employee machines, with endpoint enforcement on each device.

Extending Remote MCP Governance to Developer Desktops with Bifrost Edge

Centralizing remote MCP servers at the gateway level protects server-side agentic workflows, but it leaves an unaddressed vulnerability on developer workstations. In practice, software engineers install coding agents and desktop interfaces (such as Claude Desktop, Cursor, or OpenCode) directly on their corporate laptops. Without endpoint visibility, users frequently wire remote SaaS tools directly into their local clients, bypassing the central gateway entirely.

This uncontrolled expansion of ungoverned tools is shadow AI. To mitigate this perimeter breakdown, Bifrost uses a combined architecture: the Bifrost AI gateway serves as the centralized policy engine and control plane, while Bifrost Edge extends that exact policy enforcement directly to the endpoint.

Currently in alpha, Bifrost Edge runs natively in the background on macOS, Windows, and Linux, operating out of the system tray or menu bar. Deployed fleet-wide through Mobile Device Management (MDM) platforms like Microsoft Intune, Jamf, Kandji, JumpCloud, and Omnissa Workspace ONE, Bifrost Edge automatically inventories all AI applications running on the machine.

Key capabilities delivered by Bifrost Edge include:

• Automated MCP Server Discovery: Edge continuously inspects configuration files for clients like Claude Desktop, Cursor, and Codex CLI, discovering which local and remote MCP servers are configured across the entire corporate fleet.
• Device-Level Policy Enforcement: Through MCP governance, administrators can approve or deny specific MCP servers from the Bifrost console. If an employee configures an unvetted or high-risk remote MCP server, Edge intercepts the connection on the device and blocks communication before any enterprise data is transmitted.
• Transparent Desktop Routing: Instead of requiring engineers to manually reconfigure base URLs, authentication tokens, and gateway proxy settings inside every desktop tool, Edge automatically routes desktop AI requests through the organization's central Bifrost deployment.
• Enterprise Guardrail Enforcement: Endpoint requests inherit the gateway's active guardrails, redacting corporate secrets, tokens, and personally identifiable information (PII) before prompts leave the developer's laptop.

+----------------------------------------------------------------------------------+
|                   COMBINED AI GATEWAY + BIFROST EDGE TOPOLOGY                    |
+----------------------------------------------------------------------------------+
|  EMPLOYEE WORKSTATION                     CORPORATE CLOUD INFRASTRUCTURE          |
|                                                                                  |
|  [ Claude Desktop / Cursor ]                                                     |
|             |                                                                    |
|             v                                                                    |
|  [ Bifrost Edge Agent ]   ---(Enforces Policy)---> [ Bifrost AI Gateway ]        |
|  (Discovers MCP tools,                             (Control Plane & Routing)     |
|   blocks denied servers,                                     |                   |
|   secures endpoints)                                         v                   |
|                                                  [ Remote SaaS MCP Servers ]     |
|                                                  (GitHub, Notion, Custom APIs)   |
+----------------------------------------------------------------------------------+

This integrated approach guarantees that the same compliance, budget tracking, and data loss prevention policies established within the central infrastructure apply uniformly to remote tools invoked from developer laptops.

Step-by-Step Implementation: Configuring Remote MCP Servers in Bifrost

Setting up a centralized remote MCP architecture with Bifrost involves declaring upstream connections, creating secure virtual keys, and configuring downstream clients to route through the gateway.

Step 1: Declare Upstream Remote MCP Servers

Upstream servers are defined within Bifrost's configuration file or managed dynamically through the administration web interface. Each upstream entry defines the transport type, the remote endpoint URL, and any necessary upstream authentication headers.

{
  "mcp": {
    "servers": {
      "github-remote": {
        "transport": "http",
        "url": "https://mcp.github.enterprise/mcp",
        "headers": {
          "Authorization": "Bearer env(GITHUB_ENTERPRISE_TOKEN)"
        }
      },
      "linear-tools": {
        "transport": "sse",
        "url": "https://mcp.linear.app/sse",
        "headers": {
          "Authorization": "Bearer env(LINEAR_API_KEY)"
        }
      },
      "internal-analytics": {
        "transport": "http",
        "url": "https://analytics-service.internal.net/mcp"
      }
    }
  }
}

Step 2: Establish Virtual Keys and Tool Allowlists

Next, configure a virtual key that defines allowed tools, token budgets, and rate limits for a specific consumer or engineering group.

{
  "virtual_keys": [
    {
      "name": "frontend-team-key",
      "key": "bf-frontend-prod-8f92a",
      "budget_monthly_usd": 500.00,
      "rate_limits": {
        "requests_per_minute": 120
      },
      "mcp_governance": {
        "allowed_servers": ["github-remote", "linear-tools"],
        "allowed_tools": [
          "github-remote:search_repositories",
          "github-remote:get_pull_request",
          "linear-tools:list_issues",
          "linear-tools:create_issue"
        ],
        "denied_tools": [
          "github-remote:merge_pull_request",
          "github-remote:delete_branch"
        ]
      }
    }
  ]
}

Step 3: Connect AI Clients to the Bifrost Gateway

Downstream clients connect to Bifrost as if it were a single, standard MCP server. For example, connecting Anthropic's Claude Code CLI tool to the central Bifrost gateway using the generated virtual key requires only a single CLI command:

claude mcp add-json bifrost '{
  "type": "http",
  "url": "https://gateway.internal.net/mcp",
  "headers": {
    "Authorization": "Bearer bf-frontend-prod-8f92a"
  }
}'

Similarly, engineering teams using the Cursor IDE can add the gateway within their .cursor/mcp.json configuration file:

{
  "mcpServers": {
    "bifrost-gateway": {
      "url": "https://gateway.internal.net/mcp",
      "headers": {
        "Authorization": "Bearer bf-frontend-prod-8f92a"
      }
    }
  }
}

When either client launches, Bifrost receives the handshake, checks the permissions tied to bf-frontend-prod-8f92a, and advertises only the approved tools from GitHub and Linear. Destructive operations like delete_branch are never visible to the model.

Monitoring and Auditability for Agent Tool Calls

In autonomous agent workflows, monitoring standard metrics like LLM prompt tokens and latency is insufficient. Platform engineers must also observe tool invocation parameters, execution latency, error rates, and payload content to ensure reliable operations and satisfy compliance standards like SOC 2, HIPAA, and ISO 27001.

Because all traffic routes through Bifrost, the gateway records structured events for every step of the MCP lifecycle:

1. Discovery Handshake: Tracks when clients request tool listings and logs the specific tools advertised to the session.
2. Tool Selection and Parameter Inspection: Captures the JSON-RPC invocation request, including the model identity, prompt session, chosen tool, and exact input arguments.
3. Execution Profiling: Records the latency incurred by the remote upstream server, network round-trip time, and the HTTP status code returned by the SaaS endpoint.
4. Result Redaction: Scans the upstream server's output payload against active security guardrails, redacting leaked database credentials, API tokens, or personal identifiers before forwarding the result to the LLM.

Bifrost exports this telemetry through native Prometheus metrics for infrastructure dashboards, alongside OpenTelemetry (OTLP) exporters compatible with Datadog, Honeycomb, and Grafana Tempo. For regulated environments, administrators can configure immutable audit logs that stream execution records directly to cloud object stores or security data lakes.

Frequently Asked Questions

What is the difference between local and remote MCP servers?

Local MCP servers run as child processes on the client machine using standard input/output (stdio) for communication, requiring local runtimes and stored secrets. Remote MCP servers operate over HTTP networks (using Streamable HTTP or Server-Sent Events), allowing tools to be hosted securely on cloud platforms, shared across teams, and integrated with enterprise authentication.

How does an AI gateway secure SaaS-hosted MCP servers?

An AI gateway acts as an intermediary reverse proxy that authenticates clients, verifies tool permissions, and securely injects upstream API credentials. By terminating client connections at the gateway, organizations avoid exposing service tokens to developer machines, block unapproved tool calls, and record comprehensive audit logs for all tool executions.

Why did the Model Context Protocol introduce Streamable HTTP?

The MCP specification added Streamable HTTP to replace the complex dual-endpoint Server-Sent Events (SSE) transport. Streamable HTTP unifies messaging into a single HTTP endpoint supporting standard POST requests and streaming responses, which simplifies load balancing, reduces connection overhead, and improves compatibility with enterprise network proxies.

Can an AI gateway restrict which MCP tools an agent can call?

Yes. AI gateways like Bifrost enforce granular tool filtering through virtual keys and access profiles. Administrators define allow-lists and deny-lists for individual tools or servers, ensuring that an agent's context window contains only authorized tools and preventing unauthorized or destructive tool execution.

How does Bifrost Edge prevent shadow remote MCP connections?

Bifrost Edge is a lightweight endpoint agent deployed via MDM across corporate workstations. It scans local developer configurations for AI tools like Claude Desktop, Cursor, and coding CLIs, discovers all configured MCP servers, and enforces centralized allow/deny policies directly on the machine before unauthorized data reaches external endpoints.

Does routing MCP traffic through a central gateway increase latency?

Centralizing traffic through an efficient gateway introduces negligible latency. Bifrost is compiled in Go and adds as little as 11 microseconds of overhead per request under sustained loads of 5,000 requests per second, making gateway processing imperceptible compared to standard network round-trip times and LLM inference generation.

Next Steps

As enterprise AI adoption expands from passive prompt-response chat to autonomous agentic architectures, managing external tool connectivity becomes a core infrastructure responsibility. Relying on point-to-point connections between desktop applications and third-party SaaS endpoints compromises access control, creates compliance liabilities, and leads to uncontrolled credential proliferation.

Consolidating tool connectivity through a centralized control plane provides the visibility and governance required to operate agents safely in production. Engineering teams evaluating gateway architectures can request a Bifrost demo to explore enterprise governance capabilities or review the open-source repository to deploy a local gateway instance.

Sources

• Model Context Protocol Specification - Official documentation of MCP transport mechanisms, including stdio, Server-Sent Events, and Streamable HTTP.
• Model Context Protocol Authorization - Official specification detailing OAuth 2.1 authentication, Protected Resource Metadata, and authorization handshakes.
• RFC 8707: Resource Indicators for OAuth 2.0 - IETF standard specifying target service URI parameters for securing distributed microservice authorization.
• Bifrost Documentation - Official technical documentation for the Bifrost AI and MCP gateway architecture, performance benchmarks, and governance controls.