MCP Gateway: Run Your MCP Servers Behind the API Gateway You Already Own

Most MCP servers ship the same way. Someone writes a small service, points it at an internal system, drops a shared bearer token into an environment variable, and exposes it to an agent. It works on the first try, which is exactly the problem. That service is now a side door into a production system. No quota, no per-caller identity, no audit trail, while every REST endpoint next to it is governed by a gateway that handles all three.

The architecture question underneath is simple to state and easy to put off: which component authenticates the tool call? For teams on Google Cloud, that answer now has more than one credible shape. It's worth deciding on purpose rather than inheriting whatever the first prototype happened to do.

What "gateway-fronted MCP" actually means

Model Context Protocol is how an agent discovers and invokes tools. Two methods carry most of the weight: tools/list, which tells the agent what it can do, and tools/call, which does it. A hand-rolled MCP server implements both itself, holds the backend credential itself, and enforces whatever limits its author remembered to write.

Gateway-fronted MCP moves that work onto infrastructure you already operate. Apigee's model, first announced in preview on December 10, 2025, takes an OpenAPI specification and turns each operation into a tool. The proxy uses /mcp as its basepath, and it's bundled into an API product so identity and quota policies apply (Google Cloud). MCP in Apigee reached general availability on March 31, 2026, including for organizations running Data Residency and VPC Service Controls (release notes).

The consequence is that the credential question moves. The gateway authenticates the calling agent, the API product defines which tools that agent can even see, and the backend call travels the policy path you already review.

Why the hybrid release changes the recommendation

Apigee hybrid 1.17.0, released September 14, 2026, added MCP support as an optional feature. It's off by default and has to be explicitly enabled in configuration (hybrid release notes). Here's the detail that matters for regulated customers: the MCP gateway's data plane runs inside the customer's own Kubernetes cluster, and MCP request traffic never leaves that cluster (Apigee MCP overview).

Configuration is pulled, not pushed. A sidecar inside the cluster fetches tool configuration; the Apigee control plane never initiates a connection inbound. The sidecar reuses the existing apigee-watcher identity, so no new Google service account or IAM role is needed, just a one-time per-organization control-plane grant (Google developers blog).

For teams who previously declined managed MCP endpoints on data-residency grounds, that's a different conversation than the one available six months ago.

The reference pattern we'd deploy

For a customer already running governed APIs on Google Cloud, the default shape looks like this:

• Start from the OpenAPI spec, not from a new service. If the capability the agent needs is already a REST operation, it can become a tool without new code holding new credentials.
• Give every agent its own identity. The gateway authenticates the caller; the agent does not inherit a human's token or a service-wide secret.
• Define entitlement with an API product. Tool-level access control in Apigee uses the existing API product concept: you list the specific tool operations a caller is entitled to, optionally with a per-tool quota, and discovery is filtered so a tools/list call returns only the tools in that caller's product (Google developers blog).
• Keep agentic traffic observable. Deployed MCP Discovery Proxies are ingested into API hub with an 'MCP' API style, and API insights offers 'API style' and 'MCP tool name' filters, so agent traffic can be separated from ordinary REST traffic in performance, error and latency views (same source).
• Layer content controls on top. Google positions Cloud Data Loss Prevention for classifying sensitive data returned by tools and Model Armor against prompt injection and jailbreaking (Google Cloud).

Per-tool quota also works as a spend control. When each agent's tool calls are metered and attributable, agentic traffic stops being an unbounded line on the bill and becomes traffic you can forecast, the same discipline Cloud Companion applies to SKU- and project-level spend, now extended to what your agents are doing.

Why a shared token is the wrong default

The MCP authorization specification is prescriptive here: an MCP server MUST NOT pass through the token it received from the client, and clients MUST implement the RFC 8707 resource parameter so tokens are audience-bound to a specific server (MCP specification).

Implementations still fall short of it. CVE-2026-59822 was an authentication bypass in LiteLLM's MCP endpoint: a failed key check fell back to an empty auth object, so any fabricated Bearer token produced an authenticated session. In plain terms, anyone could pretend to be a legitimate user and walk past the login entirely. It's rated 8.8 High on CVSS 4.0 and affects versions below 1.84.0. CISA added it to the Known Exploited Vulnerabilities catalog on September 2, 2026 (WorkOS). An auth path that degrades open is exactly the failure mode a gateway exists to prevent, because the MCP gateway's auth path is the one you already test.

Where this pattern stops working

We'd rather you hear the limits from us than discover them in week three.

An MCP gateway only governs traffic routed through it. MCP servers configured inside desktop applications and local coding agents never touch your proxy. OWASP tracks this as MCP09, 'Shadow MCP Servers', and the scale of the surface is easy to underestimate: the MCPCorpus dataset cited in a 2026 MCP threat-modeling write-up catalogs 13,875 MCP servers crawled from the open web, along with 300 clients (Maxim). Gateway-fronting fixes the server side, not the endpoint side.

Gateway-generated tools are OpenAPI transcriptions. Operations become tools. Workflow-shaped tools that don't map to a single REST operation, and MCP capabilities outside tool invocation, still call for a purpose-built server alongside the pattern.

Protocol depth is worth verifying. Solo.io's Christian Posta argued that building an MCP gateway on Apigee meant hand-parsing JSON-RPC with ExtractVariables and JavaScript policies, which breaks down on arrays of tool calls and per-tool schema validation (Solo.io). That piece predates native support, so read it for the protocol-mismatch reasoning rather than current product status. Still, confirm how deep the native authorization goes for your specific tools.

Transport-layer auth doesn't stop prompt injection. Unit 42 has demonstrated attack vectors through MCP sampling, including covert tool invocation, where hidden tool calls and file system operations run without the user's awareness or consent (Unit 42). Those attacks live inside legitimate, authenticated traffic.

Deployment limits are real. API hub only manages tool-to-operation mappings, policy changes still happen in Apigee, and an MCP proxy deployed from API hub can go to a single environment only (API hub docs). Check the current limitations pages for your release before committing to a design.

Choosing where the call is authenticated

There is more than one MCP gateway option on Google Cloud, and they are not interchangeable.

• Apigee (managed), the mature path when you already run Apigee and want MCP governed exactly like your REST estate.
• Apigee hybrid 1.17.0+, the same model with the data plane in your own cluster. Enabling it is a Helm operation: enableMcpServer: true in overrides.yaml, with the apigee-operator chart upgraded before apigee-org. Get the order wrong and you'll get a successful upgrade and no MCP pods. Enabling or disabling triggers a staged canary release of runtime pods, so Google advises a maintenance window (Google developers blog).
• API Gateway, lighter weight, announced in Public Preview on September 24, 2026. tools/list is unauthenticated by default, publishing tool names and input schemas to anyone who asks, and API keys can't secure that method; Google recommends requiring a JWT in production. A gateway serves up to 1,000 tools (Google developers blog).
• Agent Gateway, a different control entirely: it governs agentic traffic in both directions. It assigns each agent a SPIFFE ID via Agent Identity secured with mTLS and DPoP, and checks an Agent Registry of approved agents, tools and MCP servers before allowing connections (Google Cloud docs).

Most architectures need two answers, not one: how tool calls reach your systems, and what your agents are permitted to call outward. Lifecycle status differs across these options, GA for Apigee MCP, Public Preview for API Gateway as of late September 2026, and that mix should shape what you put in front of production traffic this quarter.

What to do with this

If you are standing up Claude agents on a Google Cloud estate, write the connector architecture down before the first server ships. Four questions cover most of it: which component authenticates the call, where the backend credential lives, how entitlement is expressed, and whether tool traffic shows up in the same analytics plane as everything else. If you already run Apigee hybrid, the governed answer may be a configuration change and a maintenance window rather than a platform build.

That design review is the first hour of our custom MCP connector work, and it's worth having whether or not we run it with you.