An MCP gateway so agents never see your credentials

Thirteen steps. That is what a guide published by tech-insider.org on October 7 proposes for setting up an MCP gateway that sits between AI agents and the credentials they need to do their job. It starts from a problem anyone who has configured a local MCP server will recognise straight away: the API key ends up written in plain text inside a configuration file. There it is within reach of the agent itself and of any process that can read that disk.

This is not a minor detail. Every MCP server added to `claude_desktop_config.json` or to Claude Code usually carries its own `env` block with a GitHub token, a payment provider key or database credentials. With three or four servers configured, a development laptop can end up holding more production secrets than many servers.

What an MCP gateway is and what it solves

The idea is simple to explain and somewhat more laborious to build. The client (Claude Desktop, Claude Code or any other compatible host) stops talking directly to each MCP server and handing it credentials. Every call goes through an intermediary instead. That gateway is the only component that knows the secrets: it injects them into the outgoing request and returns only the tool result to the model.

The agent never sees the token. If a prompt injection gets the model to try to dump its configuration or forward environment variables, there is nothing to leak from its side.

Beyond hiding keys, a centralised gateway makes possible things that are hard to achieve in a scattered deployment:

Rotation without touching clients: a key is changed in one place, not on every team member's laptop.
Per-tool permissions: you can decide that an agent may read issues but not merge, even if the underlying token has broader scope.
Audit log: every call is recorded with who made it, which tool was used and when, something local MCP servers almost never offer.
Immediate revocation: if an agent behaves strangely, its access is cut at the gateway without having to chase down copies of credentials.

Why it is happening now

The protocol already supports OAuth-based authorisation for remote servers, and more and more providers publish hosted MCP servers with their own login. But for many teams the reality is still mixed: remote servers with OAuth sit alongside local servers launched with `npx` or `uvx` that expect an environment variable. The gateway brings order to that mix without waiting for every provider to migrate.

Agent usage has also changed scale. With subagents launched in parallel, hooks running commands on every event and plugins that install their own MCP servers, the ways a credential can slip out have multiplied over the past year. The fact that a guide needs thirteen steps already suggests this is not fixed by editing one line of a configuration file.

Who it makes sense for

Not everyone needs a gateway. A developer using a couple of read-only MCP servers on their own machine may get by with the system secret manager and some discipline. The pattern starts to pay off in other cases:

Teams where several people share the same MCP servers with company credentials.
Agents running on servers or in CI, with nobody present to approve each action.
Organisations with compliance requirements that have to prove who accessed which system and when.
Integrations with customer data, where a leak does not stop at a scare: it has to be reported.

The cost should not be forgotten. A gateway is one more piece of infrastructure to maintain, monitor and protect. If it goes down, every agent loses its tools; if someone compromises it, they get every secret in a single place. Network isolation, encrypted storage and short-lived tokens reduce that risk, but they do not eliminate it.

What we have seen in real projects

In the Claude integrations we build for clients, this conversation tends to come up at a predictable moment: when the pilot works and someone asks how to take it to production with twenty users. That is when credentials spread across configuration files stop being a convenience and turn into a problem. Separating from the start who reasons (the model) and who holds the keys (the gateway or a vault) avoids having to rebuild the architecture later.

Before copying the steps as they are, we recommend reading the full guide on tech-insider.org. Every stack has its quirks, and the useful part is the design reasoning more than the specific recipe.

We think the MCP gateway will become as common in agent deployments as an API gateway in front of a backend is today. The sooner teams accept that the model should not touch secrets, the fewer surprises there will be later.