A common misconception is that an OIDC token alone can enforce fine‑grained, time‑bound access to a resource. In reality, the token only proves who you are; it does not control what you can do or when you can do it. Just-in-time access ensures that privileges are granted only for the exact moment they are needed and revoked immediately after.
When an MCP (Machine‑Control‑Plane) server needs to talk to services protected by Entra, the identity provider supplies a signed token that the server presents on each request. The token tells the target that the request originates from an authenticated entity, but it offers no runtime guardrails. Without an additional enforcement layer, any holder of the token can make unrestricted calls for as long as the token remains valid, widening the blast radius of a compromised server.
Why just-in-time access matters for MCP servers
Just-in-time access means granting the minimum privileges required for a single operation, and revoking them immediately after. For MCP servers, this approach reduces the window in which a malicious actor could abuse a stolen credential. It also satisfies audit requirements by providing a clear, time‑stamped record of who performed which action and whether that action was approved.
Entra supplies the identity and the initial authentication, but the enforcement point must sit on the data path between the MCP server and the target service. Only a gateway that can inspect the protocol payload can apply real‑time policies such as approval workflows, command blocking, or response masking.
Introducing an identity‑aware gateway for just-in-time access
hoop.dev is a Layer 7 gateway that sits between the MCP server and the Entra‑protected resource. It verifies the OIDC token issued by Entra, extracts group and attribute information, and then enforces policies before the request reaches the target.
Because hoop.dev operates at the protocol level, it can:
- Record every session for replay and audit.
- Require a human approval step for commands deemed risky.
- Mask sensitive fields in responses, protecting data at rest and in motion.
- Block disallowed commands before they are executed on the backend.
All of these enforcement outcomes exist only because hoop.dev sits in the data path. The Entra token alone does not provide any of them.
High‑level flow for MCP servers
1. The MCP server obtains an OIDC token from Entra after authenticating as a non‑human service account.
2. The token is presented to hoop.dev when the server initiates a connection.
3. hoop.dev validates the token, checks the server’s group membership, and applies just-in-time policies defined for that service account.
4. If the request matches a policy that requires approval, hoop.dev routes the request to a designated approver. Once approved, the request proceeds; otherwise it is denied.
5. The response passes back through hoop.dev, where any configured masking is applied, and the full session is recorded.
Configuring the gateway for Entra‑backed just-in-time access
Begin by deploying the gateway using the provided Docker Compose quick‑start or a Kubernetes manifest, depending on your environment. The deployment includes an agent that runs close to the target services, ensuring low‑latency inspection.
Next, register Entra as the OIDC identity provider in the gateway configuration. This step tells hoop.dev how to validate incoming tokens and which claims to use for policy decisions.
After the identity provider is set, define a connection representing the MCP server’s target service. In this definition you specify the host, port, and the credential that hoop.dev will use to talk to the backend. The MCP server never sees this credential; hoop.dev injects it when forwarding traffic.
Finally, create a just-in-time policy for the service account. The policy can specify a maximum session duration, required approval for specific command patterns, and which response fields should be masked. Enable session recording to capture a replayable audit trail.
All of these steps are documented in the getting started guide. The guide walks you through deploying the gateway, configuring Entra, and defining policies without exposing any low‑level command syntax.
Benefits of the hoop.dev approach
By placing enforcement at the data path, you gain a single source of truth for access decisions. The system automatically revokes privileges after each operation, dramatically shrinking the attack surface. Recorded sessions provide evidence for compliance audits, while inline masking prevents accidental data leakage.
Because the gateway mediates every request, you can introduce new policies, such as additional approvals for privileged commands, without touching the MCP server code. This separation of concerns accelerates security iterations and reduces operational risk.
Next steps
Review the learn page for a deeper dive into masking, approval workflows, and session replay. When you’re ready to provision the gateway in your environment, clone the repository and follow the installation instructions.
Explore the source code, contribute improvements, or raise issues at the project’s GitHub page: https://github.com/hoophq/hoop.
FAQ
Does hoop.dev replace Entra’s authentication? No. Entra remains the source of identity and token issuance. hoop.dev consumes those tokens and adds enforcement on the connection.
Can I use hoop.dev with other identity providers? Yes. Any OIDC‑compatible provider can be registered, but the example here focuses on Entra.
What happens if an approval is not granted? hoop.dev blocks the request and logs the denial, preserving a complete audit record of the attempted operation.
