AI Build · 2026

A secure MCP gateway

MCP servers are how AI assistants reach live data — but the default way to run them is installed and individually authenticated on each person's laptop. This is the architecture I use instead: one hosted, access-controlled gateway, protected by two independent layers of authentication. The build shown here put a team's Google Search Console, Business Profile, and Analytics connectors behind it; my own personal MCP servers run on the same pattern.

One hosted home for the connectors, reachable from any device or AI client that's been invited — and locked down so only authorized people can ever reach the data behind it.

The challenge

A tool on every laptop, a credential on every laptop.

The moment more than one person — or more than one device — needs an MCP server, the default setup breaks down: each machine gets its own install, its own authentication, its own copy of the credentials. That creates three problems.

• Fragility & inconsistency

  Every person maintains their own copy, with their own credentials and their own breakages.

• No central control

  There is no clean way to grant or revoke access, or to see who can reach what.

• Sensitive data exposure

  The credentials open live private data, so scattering them across personal machines is a real risk.

The solution

One encrypted address. Two layers that should never be conflated.

The gateway is a centralized server with each MCP connector isolated in its own container behind a single encrypted web address. The architecture separates two concerns that are easy to confuse — identity (who may use the server) and data permission (what the server may read).

A reverse proxy terminates HTTPS and routes traffic; a lightweight authorization gate enforces the OAuth 2.1 login on every request before any connector runs. The result is a clean data flow: someone asks their AI assistant a question → the request hits one secure address → it's checked for a valid login → it's routed to the right connector → the connector uses its stored upstream credential (here, a Google one) to fetch the data → the answer returns the same way.

Identity is handled by a managed provider with Google sign-in and an invite-only policy. Each connector holds its own Google credential, authorizing it to read only its one service — and those credentials live only on the server, in locked-down files, never in shared code.

The separation

Who may use it, and what it may read, are different questions.

• Identity — who may use the server

  Every request must carry a valid login, handled by a managed identity provider with Google sign-in and an invite-only policy. Access is granted or revoked per person from a dashboard.

• Data permission — what the server may read

  Each connector holds its own Google credential, authorizing it to read only its one service’s data. These live only on the server, in locked-down files, never in shared code — and a person logging in never sees or touches them.

Technical highlights

Standards at the front door, depth behind it.

• Standards-based access control.

  Front-door authentication is OAuth 2.1 with dynamic client registration and PKCE, so modern AI clients can connect and self-register — while the server validates every token it receives before any connector runs.

• Defense in depth.

  A locked-down firewall (only encrypted web traffic and a protected admin channel), HTTPS everywhere, key-only server administration, per-person identities, and Google credentials that never leave the server.

• Pragmatic revocation.

  Rather than bolt on a fragile per-request check, the gateway relies on short-lived logins: when someone is removed, their renewal is cut off and access ends within minutes — the standard, robust OAuth pattern, tunable if a tighter window is ever needed.

• Reproducible & documented.

  The entire setup is version-controlled and containerized, so it can be rebuilt or moved without guesswork — and it ships with plain-language documentation anyone can operate from.

A note on real-world problem-solving

Two issues that proved the value of clean separation.

A recurring credential expiry on one connector was diagnosed not as a server fault but as a Google project still in “testing” mode — a configuration fix, not a code one. And when an initial approach to instant revocation hit a limitation in how the tokens were scoped, I chose the proven, reliable pattern over a brittle workaround.

Because identity and data-permission were kept as distinct layers, each problem was isolated and resolved without destabilizing the rest of the system.

The outcome

A gateway you operate, not a setup you babysit.

• One-step access for everyone.

  People connect once and their tools are ready, from any AI client on any device. No per-laptop install, no individual credential dance, no one-off breakages to chase down.

• Access managed in seconds.

  Adding a person — or removing them — is a single action in a dashboard, with removal taking effect within minutes.

• Data protected end-to-end.

  Encryption in transit, a hardened server, per-person access, and credentials that stay put. The sensitive material never scatters across personal machines.

• Built to hand off.

  Fully documented and reproducible, so the gateway can be operated, extended, or migrated by anyone — not just the person who built it.

Stack: Ubuntu VPS · Docker · Caddy (reverse proxy + automatic TLS) · Python MCP servers (Search Console, Business Profile, Analytics) · WorkOS AuthKit (OAuth 2.1 + Google sign-in) · Let's Encrypt · Google APIs.

Build one for your org

Give AI access to your data without scattering the keys.

If your team is wiring AI assistants into live data one laptop at a time — or you want one access-controlled place that AI clients can reach without the credentials ever leaving your server — that's the conversation. Thirty minutes, and I'll come with a point of view.

Or write me directly: hello@joekim.info