How MCP Gateways Work and Why They Concentrate Risk

An LLM gatewayLLM Gateway🛡️A reverse proxy that sits between applications and model providers, holding the real provider API keys, issuing virtual keys to applications, and enforcing budgets, routing and logging. It is a credential concentrator: compromising one gateway can expose every provider relationship an organization has. is a reverse proxy that sits between your applications and the model providers they call. A Model Context Protocol gateway is the same idea applied to tools: it sits between an AI agent and the systems the agent is allowed to act on. When one product does both jobs, as LiteLLM does, a single authentication mistake exposes every model key and every tool connection the organization has plugged in. That is what the CVE-2026-59822 bypass that CISA added to its Known Exploited Vulnerabilities catalog in September 2026 demonstrated, and it is why the fix mattered more than the CVSS score implied.

What an LLM Gateway Actually Holds

The pitch for a gateway is operational. Instead of every team embedding its own OpenAI, Anthropic, Azure or Gemini key in application config, the organization runs one proxy. Applications get a virtual key issued by the proxy. The proxy holds the real provider keys, enforces per-team budgets and rate limits, logs usage, and can swap models without touching application code.

Read that list from an attacker's perspective. The gateway holds:

• Every upstream provider credential the organization uses, usually with high spending limits because they are shared.
• A database of virtual keys, team assignments and model routing, which maps out who uses what.
• A master key that can mint new virtual keys and change configuration.
• Often a cloud IAM role, because the container needs one to reach a managed model endpoint or a secrets store.

Wiz's honeypotHoneypot🛡️A decoy system deployed to be attacked so defenders can observe exploitation attempts safely. Honeypot networks give early warning that a vulnerability has moved from theoretical to actively exploited, often before official catalogs like CISA KEV confirm it. research on the LiteLLM attacks recorded attackers reading the master key directly out of the running Python process and harvesting the tables that store model configuration and verification tokens. They were not guessing at the value of the target. A gateway is a credential concentrator by design, and the concentration is the feature.

What MCP Adds

The Model Context Protocol is a standard for giving a language model access to tools. An MCP server exposes a set of named tools, each with a schema, and a client can list them and invoke them. The tools are arbitrary code: query a database, open a ticket, read a repository, send a message, call a cloud API. The protocol has a stdio transport for local processes and an HTTP transport, called Streamable HTTP, for remote servers.

An MCP gateway aggregates many MCP servers behind one endpoint. The agent connects to the gateway, the gateway authenticates the agent, applies whatever access policy it has, and forwards tool calls to the right upstream server. In LiteLLM the gateway lives under the `/mcp/` route and can address specific servers by path or by an `x-mcp-servers` header.

This is where the two functions compound. The model gateway concentrates credentials. The MCP gateway concentrates capabilities. An attacker who gets an authenticated session on the MCP route does not need to steal a key to do damage; they can call the tools directly, using whatever upstream credentials the gateway already holds for each one. The GitHub advisory for CVE-2026-59822 described the impact as exactly that: list and invoke configured MCP tools and access the services exposed through them.

How Authentication Is Supposed to Layer

A well-built gateway makes two independent authentication decisions on every MCP request. The first is admission: does this caller hold a valid gateway credential? The second is upstream: what credential should be presented to the MCP server the call is going to?

The upstream side can be configured several ways. The gateway can hold a static credential for the server, perform its own OAuthOAuth🛡️An open standard authorization protocol that allows applications to access user resources without exposing passwords, using tokens instead of credentials. flow and manage the token, or pass the client's own token through untouched. LiteLLM's documentation describes a transparent mode, `auth_type: true_passthrough`, that forwards the client's Authorization header verbatim with no gateway admission at all, and a delegated mode, `auth_type: oauth_delegate`, that checks the gateway's own key first and forwards a separate upstream bearer.

The design is sound as long as each mode is applied only to the servers configured for it. The bug was in the boundary between modes.

Where the Fallback Broke

The vulnerable code handled a request roughly like this. Validate the Authorization header as a LiteLLM key. If that raises a 401 or 403, assume the caller must be using OAuth passthrough for some upstream server, swallow the error, and continue with an empty identity object. The empty identity was then treated as an authenticated session.

Two things were wrong. The fallback did not check whether the target server was actually configured for OAuth passthrough. And an earlier check that exempted OAuth discovery endpoints from authentication matched the string `.well-known` anywhere in the URL rather than at the start of the path, so it could be triggered by a query parameter. The fix commit made the fallback conditional on every targeted server being configured with `auth_type=oauth2`, resolved from the request path or header, and made the discovery exemption match only paths that begin with `/.well-known/`. If the target cannot be resolved, the new code returns nothing and the request is denied.

This is a fail-openFail-Open🛡️A design flaw in which a control that cannot complete its check grants access instead of denying it. In authentication, a missing key or failed lookup that results in access being allowed turns a security check into a rubber stamp. pattern, and it has a family. The JFrog Artifactory bypass from the previous week accepted a phantom default join keyJoin Key🛡️A shared secret that the services of a distributed application use to authenticate to each other when joining a deployment. If the software falls back to a predictable value when no key is set, attackers can forge service credentials — the flaw class behind the 2026 Artifactory authentication bypass. when none was configured. Both bugs share a root cause: a failed check was interpreted as "some other mechanism must be handling this" rather than "deny." The general treatment is in How Default Secrets and Phantom Credentials Break Authentication.

Why Concentration Changes the Threat Model

Concentration is not wrong. Centralizing keys is better than scattering them, because a central store can be rotated, monitored and budgeted. But concentration moves a component into a different tier of risk, and the operational practices have to move with it. Three consequences follow.

Blast radius is organization-wide. A compromised application key leaks one application's access. A compromised gateway leaks every provider relationship and every tool connection at once, which is why recovery starts with rotating the master key, every virtual key, every upstream key and the database password.

The tool surface turns data access into action. A model that can read a document is a confidentiality problem. A model that can call a tool that writes to a ticketing system, a repository or a cloud account is an integrity problem, and an anonymous session on the MCP route inherits every write permission the tools have. The specific controls are in How to Lock Down a Self-Hosted LLM Gateway.

Prompt injectionPrompt Injection🛡️An attack that embeds instructions in content a language model will process, so the model takes actions the operator did not intend. In blind prompt injection the attacker cannot see the output and instead confirms execution through a side channel such as a DNS callback to a domain they control. becomes a network-reachable input. Wiz's honeypots recorded blind prompt-injection attempts that used DNS callbacks to confirm execution. Once an MCP gateway is reachable, the content that flows through the tools is attacker-influenced input to a system that can take actions.

Practical Takeaways

Treat the gateway as a Tier 0 asset, in the same class as the identity provider. Do not expose the MCP route to any network that does not need it; the advisory's own workaround was to block `/mcp/` at the reverse proxy. Give each MCP tool its own narrowly scoped upstream credential. Log every tool invocation with the caller identity so that an anonymous session would show up. And when a fast-moving project ships a security fix, upgrade on a vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. timeline rather than a feature timeline. The governance argument for that is made in Treating AI Infrastructure as Privileged Infrastructure.