← Blog

MCP Gateway vs Direct Connection: Why Gateways Matter for Security

15 Research Lab
mcp-safetydefenseguardrails

Most MCP tutorials show direct connections: the agent connects to a server, fetches tools, and calls them. This is fine for development. In production, it is a security gap.

Direct Connection Model

In a direct connection, the agent's MCP client communicates with each MCP server independently. The agent has full access to every tool every server exposes. There is no centralized enforcement point.

Problems with direct connections:

  • No unified authentication. Each server implements its own auth (or none).
  • No cross-server authorization policy. Tool access is all-or-nothing per server.
  • No centralized logging. Audit trails are scattered across servers.
  • No content scanning. Tool descriptions and responses reach the model unexamined.
  • Server compromise gives immediate, full access to the agent.
  • Adding or removing servers requires client-side configuration changes.

Gateway Model

A gateway sits between the agent and all MCP servers. The agent connects to one endpoint (the gateway), which proxies requests to backend servers.

What the gateway provides:

Single authentication point. The agent authenticates once with the gateway. The gateway authenticates with backend servers using service-level credentials.

Unified authorization. One policy engine evaluates all tool calls. Rules span across servers. You can create policies like "this agent can read from Server A and write to Server B, but not the reverse."

Content scanning. Every tool description and response passes through the gateway. Injection detection runs on all content before it reaches the model.

Centralized audit. Every tool call is logged in one place with consistent formatting. Receipt chains provide tamper evidence.

Hot-swappable backends. Add or remove MCP servers without reconfiguring the agent. The gateway abstracts server topology.

Architecture

Agent --> Gateway --> MCP Server A
                 --> MCP Server B
                 --> MCP Server C

The gateway acts as a reverse proxy with security policy enforcement. From the agent's perspective, it talks to one MCP server (the gateway). The gateway fans out to backends.

Authensor's control plane implements this pattern. It exposes an MCP interface to agents and proxies to backend tool servers with full policy enforcement, content scanning, and audit logging.

Performance Considerations

A gateway adds one network hop. For SSE-based transports, this adds 1-5ms of latency per request. For most agent applications, this is negligible compared to LLM inference time (hundreds of milliseconds to seconds).

The gateway can cache tool definitions to avoid re-fetching on every connection. It can also batch audit log writes to reduce I/O overhead.

When Direct Connection Is Acceptable

Local development with stdio transport, where the MCP server is a child process and the attack surface is your own machine. Single-user, single-server setups with no sensitive data access. Everything else should route through a gateway.