Just-in-time access for MCP servers on GCP

Do you need just-in-time access to your MCP servers on GCP without handing out permanent keys?

Most teams that run AI models on Google Cloud provision a service‑account key, copy it into CI pipelines, and share the same JSON file with every engineer who touches the model. The key lives on laptops, in container images, and sometimes in version‑control histories. Because the credential never expires, any compromised workstation gives an attacker unfettered access to the MCP server for as long as the key remains valid. There is no central log of who ran which inference, no way to verify that a request complied with policy, and no mechanism to stop a dangerous command before it reaches the server.

Even when organizations adopt identity‑aware proxies or short‑lived tokens for other workloads, the connection to an MCP server often remains a direct TCP stream. The request still reaches the target unmediated, so the system cannot enforce just-in-time approval, mask sensitive fields in model responses, or capture a replayable audit trail. In other words, the core problem, granting temporary, policy‑driven access while preserving full visibility, remains unsolved.

hoop.dev fills that gap by becoming the mandatory data path for every MCP request. It sits as a Layer 7 gateway between the caller’s identity and the GCP‑hosted MCP server. The gateway authenticates the user via OIDC or SAML, checks group membership, and then decides whether to allow the connection, require an approval workflow, or block the request outright. Because all traffic passes through the gateway, hoop.dev can apply inline masking to response payloads, enforce command‑level policies, and record a complete session for later replay.

Implementing just-in-time access for MCP servers on GCP

The first piece of the puzzle is the setup. Engineers obtain an identity from an OIDC provider, Google Workspace, Okta, Azure AD, or any SAML source. The identity token proves who the caller is and carries group claims that the gateway uses to make authorization decisions. This step decides who may even attempt a connection, but it does not enforce any runtime policy on its own.

Next, the data path is established by deploying the hoop.dev gateway inside the same VPC or subnet that hosts the MCP service. An agent runs alongside the MCP server, holding the service‑account credential that the gateway uses to speak to GCP. Users never see that credential; the gateway presents it on their behalf after a successful policy check. Because the gateway is the only point where traffic can be inspected, it is the sole place enforcement can happen.

Once the gateway is in place, hoop.dev delivers the required enforcement outcomes:

• It grants just-in-time access only after the request satisfies a defined approval workflow, reducing the window of exposure.
• It records each interaction with the MCP server, producing a replayable audit log that shows who ran which prompt and what the model returned.
• It masks sensitive fields, such as API keys embedded in model responses, before they reach the caller, protecting downstream systems.
• It can block commands that match a risky pattern, preventing accidental data exfiltration or destructive actions.

All of these outcomes exist because hoop.dev sits in the data path; removing the gateway would instantly eliminate the approval step, the session recording, and the masking capability.

Why the gateway model matters for AI workloads

AI inference often involves proprietary prompts and confidential results. A single leaked response can expose trade secrets or personal data. By forcing every request through a central proxy, organizations gain a single point of control that can be audited, approved, and sanitized in real time. The approach also aligns with the principle of least privilege: engineers receive temporary rights that disappear as soon as the session ends, and the underlying service‑account key never leaves the protected network.

Getting started

To try this architecture, start with the official getting‑started guide. It walks you through deploying the gateway with Docker Compose, configuring OIDC authentication, and registering an MCP server as a connection. The learn section provides deeper coverage of approval policies, masking rules, and session replay.

FAQ

Is a separate service‑account still required? Yes. The gateway holds the credential that authenticates to GCP on behalf of callers. The credential is never exposed to users.

Can I use existing IAM roles for the MCP server? The gateway can be configured to assume a least‑privilege IAM role that only allows the necessary MCP API calls.

What happens if the gateway is unavailable? Because all traffic must pass through the gateway, requests are rejected until the service is restored, preventing accidental direct access.

Ready to explore the code, contribute improvements, or run your own instance? Visit the hoop.dev repository on GitHub and follow the contribution guidelines.