A common misconception is that an MCP server can be exposed to any service account without oversight; in reality, unchecked access creates silent data leaks, and approval workflows are often missing. Teams often grant a service account permanent permissions and let applications talk directly to the server, assuming that the static credential is sufficient for security.
This direct‑connect model leaves three critical gaps. First, there is no gate that can ask a human to approve a request before it reaches the MCP server. Second, every call is logged only on the client side, making it hard to prove who did what. Third, the credential lives in the application process, so a compromised container can reuse it indefinitely.
Why a simple identity fix is not enough
Moving to non‑human identities, such as workload‑specific OIDC tokens, is a necessary step. It lets you assign each service its own least‑privilege role and eliminates the practice of sharing long‑lived keys. However, the request still travels straight from the workload to the MCP endpoint. The gateway that could enforce policies is missing, so the three gaps above remain.
In this state, the setup decides who may start a connection, but it provides no place to enforce approval, mask sensitive responses, or record the session. Without a data‑path enforcement point, the organization cannot guarantee that every interaction with the MCP server follows a vetted workflow.
Introducing hoop.dev as the enforcement layer
hoop.dev is a Layer 7 gateway that sits between identities and the MCP server running on GCP. When a workload initiates a connection, the traffic is routed through the hoop.dev gateway instead of going directly to the server. The gateway reads the OIDC token, validates the groups, and then applies the configured policy before the request is forwarded.
Because hoop.dev is the only component that can see the request in transit, it can enforce approval workflows. If a policy requires human sign‑off for a particular operation, such as creating a new model or accessing a protected dataset, hoop.dev pauses the request, notifies the designated approver, and only forwards the request once approval is recorded. This ensures that no privileged action happens without explicit consent.
At the same time, hoop.dev records every session, providing a replayable audit trail. The recorded data includes who initiated the request, the exact commands sent, and the responses returned. This evidence is stored outside the workload, so even if the workload is compromised, the audit remains intact.
How the architecture fits GCP
Deploy the hoop.dev gateway in the same VPC or subnet where the MCP server lives. The gateway runs as a container or a Kubernetes pod, and an agent runs on the same network node as the MCP service. You register the MCP server as a connection in hoop.dev, supplying the host address and the credential that the gateway will use to talk to the server. Because the credential is stored only inside the gateway, the workloads never see it.
Identity is handled through any OIDC provider that GCP trusts, Google Workspace, Azure AD, Okta, etc. hoop.dev acts as the relying party, verifying the token and extracting group membership. Those groups drive the approval workflow policies you define in the UI or configuration.
When a workload calls the MCP server, the request first reaches the hoop.dev gateway. The gateway checks whether the operation matches a rule that requires approval. If it does, hoop.dev creates an approval request, routes it to the appropriate reviewer, and blocks the forward until the reviewer clicks approve. Once approved, the gateway forwards the request to the MCP server, records the interaction, and returns the response to the workload.
Getting started
To try this pattern, start with the official getting‑started guide, which walks you through deploying the gateway, registering a GCP‑hosted MCP server, and configuring an approval rule. The guide also shows how to connect your workloads using standard client tools without any code changes.
For deeper details on policy definition, session replay, and masking capabilities, explore the learning hub.
FAQ
- Do I need to change my application code to use hoop.dev? No. The gateway speaks the same wire protocol as the MCP server, so existing clients work unchanged.
- Can I enforce approvals only for specific commands? Yes. Policies can target individual operations, allowing you to require approval for high‑risk actions while letting low‑risk calls flow freely.
- Where are the audit logs stored? hoop.dev writes session records to its configured storage backend, keeping them separate from the workload that generated the request.
Ready to add approval workflows to your GCP‑hosted MCP servers? Explore the open‑source repository on GitHub and start building a more controlled access layer today.
hoop.dev on GitHub
