MCP Gateway

Overview

MCP Gateway is the corporate entrance to internal Model Context Protocol servers at Spotware. AI clients — ChatGPT-style connectors, IDE agent clients, coding agents — reach internal tools through one authenticated, policy-governed gateway rather than a scatter of per-server proxies. Every tool call that arrives through it is authorized before it executes, leaves an audit trail, and — where the backend acts on the caller's behalf — executes as the named user with that user's own permissions.

It is built on ToolHive, Stacklok's open-source enterprise MCP platform, deployed as Kubernetes operator resources under GitOps — and building it turned into a second, public project: a stream of upstream bug reports, root-cause analyses, and pull requests against ToolHive itself, including a first merged contribution credited in the v0.46.0 release notes.

The Problem

The Model Context Protocol made it easy to put a tool server in front of an AI client. It did not make it safe. The first generation of internal MCP deployments ran behind per-server reverse proxies with a shared secret each: no per-user identity, no per-tool authorization, no audit trail — an AI client that could reach a server could do everything that server could do, as nobody in particular. That is an acceptable posture for a demo and an unacceptable one for tools that read and write real business systems.

The Solution

• One entrance, two authentication boundaries. Client-to-gateway: OAuth 2.1 with PKCE through an embedded authorization server that federates the corporate identity providers — several different IdP types, each endpoint minting its own JWT with a deliberately minimal claim set. Gateway-to-backend: handled per endpoint, from network isolation with no forwarded credential to per-user credential forwarding where the backend needs to act as the caller.
• Policy-as-code authorization before every tool call. Authorization is expressed in Amazon Cedar policies and evaluated per individual tool invocation — deny by default, forbid overrides permit — so "who may call which tool" is a reviewed, versioned artifact rather than tribal knowledge.
• Audited invocations, bound to the caller. Every call through the gateway is logged as the person who made it, and where the backend acts on the caller's behalf it executes with that caller's own upstream permissions — the difference between an AI integration you can adopt and one you must forbid.
• GitOps delivery, reproducible credentials. The whole gateway is declarative Kubernetes custom resources: changes go through review and CI, manifests are diffed before apply, and every credential is reproducible from configuration rather than existing only in a live cluster. Authorization-server state survives pod restarts through a dedicated persistence layer, verified by killing pods and checking that sessions live.
• A five-gate proof-of-concept discipline. Before rollout, five pass/fail gates were run and recorded: the OAuth handshake, authorization enforcement, in-cluster backend reachability, upstream isolation, and full per-user authorization end to end through a real AI client. Infrastructure earned its way into production; it did not drift there.

What Runs Behind It

The gateway fronts the internal MCP estate as it grows. The AIR API retrieval backbone and the YouTrack MCP Server both reach AI clients through it, the corporate analytics connector runs behind it as well, and the PeopleForce MCP Server arrives behind it next — in two deployments, because its data demands two different sensitivity postures. One governed entrance, many tools: the point of a gateway is that the next MCP server inherits the security model instead of re-inventing it.

Fixing the Platform Upstream

Connecting real AI clients to a young platform surfaces defects no test suite has met yet. Those went upstream rather than into local patches. Between July and August 2026 I filed eight issues against stacklok/toolhive — each with a full reproduction and, where I could pin it, the responsible source line — and five are resolved upstream as of this writing. Two grew into pull requests of my own after the maintainers invited contributions — #6283 and #6284, both under review — and a third, #6400, took on a defect the maintainers had filed themselves: merged, and credited in the v0.46.0 release notes as my first contribution to the project. I also validated a maintainer's fix against my own production scenario before it merged (the confirmation), got a stale, incorrectly closed issue reopened with new evidence and followed it with a pull request of my own (#6288, under review), and filed two backport requests against the official MCP Python SDK (#3142, #3150). Every link is public and checkable.

My Role

I designed and built the gateway from nothing: the endpoint topology, the identity federation, the Cedar policy model, the GitOps pipeline, and the persistence design, then debugged it live against real clients until every gate passed. The upstream trail is part of the same discipline — when the platform under you is wrong, the fix belongs where every other user of that platform benefits from it, with the evidence attached. For the broader role context, see AI Product Manager at Spotware.