Why least privilege matters for MCP
Imagine a contractor who was off‑boarded last week but whose personal access token for the MCP (Model‑Control‑Plane) service is still valid. The token grants blanket rights to list models, modify deployments, and read raw training data. Because the token is not scoped, the contractor can issue any command the MCP API accepts, and every request flows directly to the backend without any visibility from the security team. The result is a massive blast radius: a single over‑privileged token can exfiltrate proprietary datasets, alter production pipelines, and hide the activity behind legitimate client libraries.
Least privilege for MCP means granting each identity only the exact operations it needs to perform its job. A data‑science engineer might need to invoke run on a specific model, while a CI job only requires the ability to fetch model metadata. By narrowing permissions, you reduce the attack surface and make accidental misuse easier to detect.
Current practice leaves the data path unguarded
Most teams rely on OIDC or SAML tokens issued by an identity provider, then pass those tokens straight to the MCP client. The setup phase, creating a service account, assigning it to a group, and issuing the token, covers the Setup category. It decides who is making the request, but it does not enforce any constraints on the request itself. The request travels from the client to the MCP endpoint over TLS, and the MCP server processes it without any intermediate checkpoint.
This architecture satisfies authentication, yet it fails to provide any of the outcomes that true least‑privilege enforcement requires. There is no place to inspect the command before it reaches the MCP service, no way to record the exact payload for later review, and no mechanism to redact sensitive fields in responses. In other words, the data path remains completely open.
Embedding enforcement in the data path
The missing piece is a gateway that sits between the identity token and the MCP service. The gateway becomes the sole point where policy can be applied, where commands can be approved or rejected, and where every interaction can be logged. This is the Data Path requirement: enforcement must happen where the request is proxied, not merely at the identity layer.
When the gateway is in place, the following outcomes become possible:
- hoop.dev records each MCP session, providing a replayable audit trail.
- hoop.dev masks sensitive fields, such as API keys or private model weights, in responses before they reach the caller.
- hoop.dev enforces just‑in‑time approval for high‑risk commands, requiring a human reviewer to sign off.
- hoop.dev blocks disallowed commands at the protocol level, preventing them from ever reaching the MCP backend.
- hoop.dev stores a session log that auditors can replay.
All of these enforcement outcomes exist only because hoop.dev occupies the data path. Remove the gateway and the guarantees disappear, even though the same OIDC token and group membership remain unchanged.