An offboarded contractor’s service account still lives in a CI pipeline that pushes code through an MCP gateway. The token attached to that account can reach every internal database, Kubernetes cluster, and internal API because the gateway holds a single set of credentials for all of them. When the contractor’s access should have vanished, the pipeline continues to run, silently expanding the organization’s attack surface.
This scenario illustrates why “least privilege” is more than a checklist item. It is a runtime guarantee that every identity can only perform the actions it was explicitly allowed to, and only for the duration it needs them. In environments that rely on MCP gateways, the gateway itself becomes the focal point for privilege enforcement. If the gateway is mis‑configured, it can become a single point where overly broad permissions accumulate, defeating the purpose of least privilege.
What an MCP gateway does
An MCP (Model‑Control‑Proxy) gateway sits between an identity – whether a human, a CI job, or an AI‑driven agent – and the target service. It terminates the client’s protocol (PostgreSQL, SSH, HTTP, etc.) and forwards the request to the backend after applying any configured policies. The gateway holds the service credentials, so callers never see them directly. This design removes secret sprawl from code repositories and simplifies credential rotation.
From a privilege‑management perspective, the gateway offers two immediate benefits:
- It centralises authentication, allowing a single OIDC or SAML token to be used for many downstream services.
- It provides a place to insert policy checks before the request reaches the target.
However, those benefits are only realised when the gateway is part of a broader enforcement architecture. Without additional controls, the gateway merely forwards traffic, and any token that can reach the gateway inherits the union of all downstream permissions.
Why least privilege remains a challenge with an MCP gateway
The core problem is that the gateway itself does not enforce the fine‑grained rules required for least privilege. It solves the “where do we store credentials?” problem, but it leaves the request path open:
- Requests still travel directly to the target service once the gateway hands them off.
- There is no built‑in audit of which user ran which command, nor any masking of sensitive response fields.
- Approval workflows, just‑in‑time (JIT) elevation, and command‑level blocking are missing by default.
In practice this means that an over‑scoped token – for example, a service account granted roles/editor on a GCP project – can be used to issue any command through the gateway, from dropping a database to reading all logs. The gateway does not automatically trim that scope down to the specific operation the caller intended.
How hoop.dev completes the enforcement loop
hoop.dev positions itself as the data‑path layer that sits directly in front of the MCP gateway. By proxying every connection, hoop.dev can inspect the wire‑level protocol, apply policy decisions, and only then forward the request to the downstream service.
When a user or agent presents an OIDC token, hoop.dev validates the token, extracts group membership, and matches the request against a policy store. If the request exceeds the least‑privilege bounds defined for that identity, hoop.dev blocks the command before it reaches the target. For operations that are borderline – such as a schema change on a production database – hoop.dev can trigger an approval workflow, requiring a human reviewer to explicitly grant the action.