Many assume that simply placing an MCP gateway in front of a GCP service satisfies all access‑review requirements. They think the gateway’s authentication layer automatically records who accessed what, so they skip inspecting the underlying service. In reality, an MCP gateway only forwards traffic; it does not record sessions, redact responses, or pause for human approval. Auditors looking for concrete evidence, who connected, which commands ran, which data fields were returned, find a gap. The gateway alone cannot answer those questions.
Effective access reviews rely on three pillars:
- Identity verification at the start of a request.
- Control points where policy can be enforced.
- Immutable evidence that shows exactly what happened.
Identity verification usually happens through OIDC or SAML providers that issue tokens to callers. The MCP gateway validates those tokens, so the first pillar is satisfied.
The second pillar, enforcement, must sit on the data path. When traffic passes through the gateway directly to the backend, the gateway cannot block dangerous commands, request human approval, or mask sensitive fields. The request reaches the target unaltered, meaning the enforcement layer is effectively missing.
The third pillar, evidence, is the heart of an access review. Auditors require logs that are tamper evident, session recordings that can be replayed, and redacted output that protects personal data. Because an MCP gateway does not capture any of this, the evidence pillar remains empty.
Why access reviews need more than an MCP gateway
This is where a dedicated Layer 7 gateway becomes essential. hoop.dev is an open‑source, identity‑aware proxy that sits between the authenticated caller and the GCP resource. It consumes the same OIDC or SAML token, verifies the caller’s group membership, and then routes the request through a controlled data path.
Because hoop.dev is the only place the traffic can be inspected, it can enforce policy in real time. It can:
- Record every session for replay and audit.
- Mask or redact sensitive fields in responses before they reach the client.
- Require just‑in‑time human approval for high‑risk commands.
- Block disallowed commands outright.
All of these outcomes happen only because hoop.dev occupies the data path. The setup, deploying an agent near the target, configuring the connection, and defining OIDC identity sources, decides who may start a request, but hoop.dev produces the enforcement and evidence.
How hoop.dev fits into an MCP‑gateway workflow on GCP
When you already use an MCP gateway to expose a service, you can layer hoop.dev on top without changing client code. The flow becomes:
- The user authenticates with your corporate IdP and receives an OIDC token.
- The token reaches hoop.dev, which validates it and extracts group claims.
- hoop.dev checks the request against policies, possibly prompting a reviewer for approval.
- After approval, hoop.dev forwards the request through the existing MCP gateway to the GCP service.
- The response returns to hoop.dev, where masking or redaction occurs before it reaches the client.
- Throughout the exchange, hoop.dev records a complete, immutable session log.
This architecture ensures that every access review can be backed by concrete, searchable logs that include who performed the action, when it happened, and what data was exposed. The logs live outside the target service, satisfying the evidence requirement without adding load to the backend.
Benefits for access‑review programs
By placing a data‑path gateway in front of your MCP gateway, you gain:
- Automatic evidence collection: No manual log‑shipping or custom instrumentation is required.
- Fine‑grained control: Policies can target specific resources, fields, or commands.
- Reduced blast radius: Dangerous commands stop before they reach the target.
- Compliance readiness: Recorded sessions satisfy audit requirements for standards such as SOC 2 Type II.
All of these advantages come from the same open‑source project, keeping your stack simple and your security posture strong.
FAQ
What exactly is an MCP gateway?
An MCP (Model‑Control‑Proxy) gateway forwards traffic from a client to a backend while applying authentication. It does not inspect payloads, enforce fine‑grained policies, or record detailed session data.
How does hoop.dev capture the evidence needed for access reviews?
Because hoop.dev is the only component that sees the full request and response, it writes a complete, immutable log for each session. The log includes the caller’s identity, timestamps, commands issued, and any masked fields.
Do I have to replace my existing IdP or OIDC provider?
No. hoop.dev acts as a relying party; it validates the tokens issued by your existing IdP and uses the group claims to drive its policies. Your identity infrastructure stays unchanged.
Is hoop.dev compatible with all GCP services behind an MCP gateway?
hoop.dev supports the major GCP targets that can be reached via supported protocols (PostgreSQL, MySQL, SSH, HTTP, etc.). As long as the service is reachable through the MCP gateway, hoop.dev can proxy the traffic.
For a quick start, see the getting‑started guide. Detailed feature documentation is available on the learn site.
Ready to add reliable access‑review evidence to your MCP‑gateway architecture? Explore the open‑source code and contribute at github.com/hoophq/hoop.
