A former contractor still holds a hard‑coded token that lets a CI job talk to an internal MCP gateway. The job can issue prompts that cause the gateway to retrieve proprietary data and ship it to an external LLM. The organization never sees that the token was used, nor does it know what data left the network.
That scenario illustrates a classic source of vendor risk. MCP gateways sit at the boundary between internal services and large language models. When a vendor supplies the gateway, the organization often hands over broad credentials so the model can call internal APIs. The result is a single secret that, if leaked or misused, opens a direct path to sensitive workloads.
Many teams grant that secret as a static API key or a long‑lived service account. The key is stored in CI pipelines, configuration files, or even Docker images. No per‑request checks exist, and no audit trail records which prompts were sent or what responses were returned. In practice the vendor can issue arbitrary commands, retrieve database rows, or trigger code execution without any visibility.
Replacing the static secret with an OIDC‑based identity token is a step in the right direction. Engineers can now assign a short‑lived token to a specific CI job, and the identity provider can enforce group membership. However, the request still travels straight from the job to the MCP gateway and onward to the internal service. The data path contains no guardrails: there is still no place to mask personally identifiable information, no workflow to require human approval for risky operations, and no guaranteed session recording.
The missing piece is a dedicated data‑path enforcement layer. By inserting a proxy that sits between the identity token and the target service, every request can be inspected, enriched with policy decisions, and logged for later review. That proxy becomes the only point where vendor‑supplied code can interact with internal resources.
hoop.dev fulfills that role. It acts as an identity‑aware proxy that validates OIDC or SAML tokens, maps group claims to fine‑grained policies, and then forwards traffic to the MCP target. Because the gateway lives on the same network segment as the internal service, the vendor never sees the underlying credentials. The gateway can apply inline data masking, block commands that match a deny list, and route high‑risk prompts to an approval workflow before they reach the target.
When hoop.dev sits in the data path, vendor risk drops dramatically. Every session is recorded, providing a replayable audit trail that shows exactly which prompts were issued and what responses were returned. Sensitive fields such as credit‑card numbers or internal identifiers can be redacted in real time, preventing accidental exposure to the LLM. If a prompt attempts a destructive operation, hoop.dev can halt the request and require a human reviewer to approve it, turning an uncontrolled action into a governed one.
To adopt this approach, teams should deploy the gateway using the provided Docker Compose quick‑start, register the MCP endpoint as a connection, and configure OIDC authentication against their identity provider. Policies are then defined based on group membership, specifying which users may invoke which prompts, which responses require masking, and which actions need approval. The documentation walks through each step, from agent deployment to policy creation.
For a hands‑on walk‑through, see the getting‑started guide. The learn section contains deeper explanations of masking, approval workflows, and session replay.
FAQ
- What does hoop.dev protect that OIDC alone does not? OIDC only proves who the caller is. hoop.dev sits in the data path and enforces what the caller may do, masks data, and records every interaction.
- Can I still use existing CI pipelines? Yes. CI jobs obtain short‑lived OIDC tokens and send them to the gateway just as they would to the MCP endpoint today. The gateway adds the missing controls without changing the job logic.
- Does hoop.dev store any credentials? The gateway holds the service credentials required to talk to the internal target, but those credentials never leave the network segment. Users and agents never see them.
Explore the source code, contribute improvements, and see how the community secures MCP gateways at GitHub.
