Many assume that an Entra‑issued token alone can grant an MCP server unrestricted access, but the token is only an identity claim. In reality, just-in-time access requires a gate that evaluates each request at the moment it is made.
In practice, engineers often embed a long‑lived service account token in the MCP client configuration and let the process talk directly to the server. The token is shared across many pipelines, rarely rotated, and there is no central point that can verify whether the request should be allowed at that moment. Because the connection bypasses any gate, every command runs with the same privileges, and no one can tell which user or automation triggered a particular query.
This arrangement creates three concrete problems. First, the principle of least privilege is violated: a single credential grants broad rights that exceed any single job’s need. Second, there is no real‑time approval workflow; a risky operation can be executed without a human sign‑off. Third, the lack of an audit trail means that after a breach or mistake, investigators cannot reconstruct who did what and when.
What organizations typically try to fix is the identity side: they move to Entra, assign group memberships, and generate short‑lived OIDC tokens for each automation. That step ensures the request originates from a known identity, but the request still travels straight to the MCP server. Without an intervening control plane, the request remains unexamined, un‑approved, and un‑recorded.
Enter a layer‑7 gateway that sits in the data path between Entra identities and the MCP server. This gateway enforces just-in-time access, requires approval for privileged commands, masks sensitive response fields, and records every session for replay. The product that provides this capability is hoop.dev.
How just-in-time access works with Entra
The first step is to configure Entra as the identity provider. Engineers register an OIDC application in Entra, define the groups that represent different privilege levels, and configure the gateway to trust tokens issued by that application. When an automation or a human user wants to talk to an MCP server, it obtains a short‑lived token from Entra and presents it to the gateway.
Setup – Entra identity and least‑privilege grants
Entra decides who the request is and whether it may start. The token carries the user’s or service account’s group claims, which the gateway reads to map the identity to a policy. Because the token expires quickly, the window for misuse is limited, and the policy can require that only members of a specific group are eligible for just-in-time elevation.
The data path – placing the gateway
The gateway is deployed as a network‑resident agent near the MCP servers. All traffic from the client to the server is forced through this agent. Because the gateway sits on the wire, it can inspect the MCP protocol, enforce policies, and decide whether to allow a command to proceed. No command reaches the server without first passing the gateway’s checks.
Enforcement outcomes – what hoop.dev does
hoop.dev records each session, storing a replayable log that shows every request and response. When a command matches a high‑risk pattern, hoop.dev blocks it before it touches the server. If a request requires elevated privileges, hoop.dev routes the operation to a human approver; the request only continues after explicit consent. For queries that return sensitive data, hoop.dev masks the fields in real time, so downstream consumers never see raw values. All of these outcomes exist only because hoop.dev sits in the data path.
Because the gateway holds the credential needed to talk to the MCP server, the client never sees the password or API key. This separation means that even a compromised client cannot extract the underlying secret, reinforcing the “agent never sees the credential” principle.
Operational flow for just-in-time access
- Developer or CI system requests an Entra token for a specific role.
- The token is presented to hoop.dev when opening an MCP connection.
- hoop.dev evaluates the request against the policy attached to the token’s groups.
- If the policy requires approval, hoop.dev pauses the request and notifies an approver.
- After approval, hoop.dev forwards the command to the MCP server, applying any inline masking.
- The entire interaction is recorded for later replay.
By centralising these steps, teams gain visibility, control, and the ability to enforce just-in-time access without rewriting existing client code. The approach works for any MCP server that communicates over a supported protocol, and the same gateway can protect databases, Kubernetes clusters, or SSH endpoints with identical policy definitions.
Getting started
To try this architecture, follow the getting‑started guide for a quick Docker Compose deployment. The guide walks you through registering an Entra application, configuring group‑based policies, and launching the gateway alongside an MCP server. For deeper policy design, the learn section explains how to write masking rules and approval workflows.
All configuration details, source code, and contribution guidelines are available in the open‑source repository. Explore the hoop.dev GitHub project to see the full implementation and start customizing the solution for your environment.
FAQ
- Does just-in-time access increase latency? The gateway adds a small, predictable round‑trip for each request, but because it runs close to the target server the impact is minimal compared with the security benefit.
- Can I use existing Entra groups? Yes. hoop.dev reads the group claims from the token, so any group you have defined in Entra can be mapped to a policy.
- What happens if the gateway is unavailable? Requests are blocked until the gateway recovers, ensuring that no operation can bypass the enforcement layer.
