MCP gateway

What it is

An MCP gateway is an intermediary. Agents connect to the gateway as one MCP server; the gateway reaches the systems behind it. The MCP security guidance uses the term "MCP proxy server" for a server that connects clients to third-party APIs, and the OWASP MCP cheat sheet recommends using an MCP proxy or gateway to enforce isolation policies between servers.

Gateways come in two broad shapes. Some aggregate other MCP servers and relay their tools. Others call the vendors' own APIs directly and present them as tools.

Why it matters

Without a gateway, every agent connects to every system separately. Each connection has its own credential, its own idea of permissions and its own log, and nobody can answer "what did our agents do yesterday, and what did it cost?" A gateway gives one place to hold secrets, decide what each agent may do, stop runaway spending and keep the record.

How it works

1. The agent authenticates to the gateway with its own credential, never a vendor's.
2. For each call, the gateway resolves who is calling and checks the call against that caller's policy.
3. It uses its own stored credential for the vendor; the MCP specification forbids passing the client's token through to the upstream API.
4. It applies rate limits and budgets, sends the request, records the outcome and returns the result.

Example

A managed service provider gives its triage agent one gateway URL. Behind it are the PSA, the RMM, Microsoft 365 and the accounting system. The agent's key may read everything and create tickets, but resetting a password waits for an engineer's approval.

Common pitfalls

• A relay with no policy. A gateway that only multiplexes tools hands the agent hundreds of definitions and every permission of every credential behind it.
• One shared credential. If every agent uses the same upstream token, there is no least privilege and no per-agent record.
• The confused deputy. A proxy that uses a static OAuth client ID with a third-party authorisation server must get the person's consent for each dynamically registered client, as the MCP security guidance requires.
• Tool overload. Relaying every tool of every server recreates the problem the gateway was meant to solve. See tool overload.

How actionlake handles it

As an MCP gateway, actionlake calls each vendor's API directly through a signed service file. An agent holds an actionlake key, never a vendor token; the credentials sit in a vault. Every call passes the same checks: the key's scope, its spending cap (refused before the request is sent), any approval rule, then the vendor's rate limit. The outcome goes into a hash-chained ledger with the agent's stated reason. The agent sees eight tools whether one system is connected or a hundred, and ask can join across systems in one call. See the platform and the trust page.