AI Build · 2026

A secure MCP gateway for marketing data

A digital marketing agency needed a single, secure server that would let its whole team use AI assistants to pull live data from Google Search Console, Google Business Profile, and Google Analytics — replacing fragile per-laptop setups with one access-controlled gateway, protected by two independent layers of authentication. I designed and built it, then handed it off documented and reproducible.

One hosted home for the team's reporting tools, reachable by everyone (and the occasional outside consultant) — and locked down so only authorized people can ever reach client data.

The challenge

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

The agency's team increasingly relied on AI assistants to pull reporting data from clients' Google marketing accounts. But the tools that connected the AI to that data — MCP servers — had to be installed and individually authenticated on each person's laptop. That created three problems.

• Fragility & inconsistency

  Every team member maintained their own copy, with their own credentials and their own breakages.

• No central control

  There was no clean way to grant or revoke access, or to see who could reach what.

• Sensitive data exposure

  Those credentials touched live client analytics, so scattering them across personal machines was a real risk.

The solution

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

We built a centralized gateway on a private server, with each tool 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: a team member 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 Google permission 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, we rely 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 was handed off with plain-language documentation the team 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, we 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 the team operates, not a setup they babysit.

• One-step access for the whole team.

  Team members connect once and their tools are ready. No per-laptop install, no individual credential dance, no one-off breakages to chase down.

• Access managed in seconds.

  Adding a teammate or an outside consultant — or removing them — is a single action in a dashboard, with removal taking effect within minutes.

• Client 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 on the team without 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 client 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