When every MCP request is issued with a short‑lived token under a just-in-time access model, approved on demand, and automatically recorded, the system behaves as if a guard is standing at the door: no stale credentials linger, no unexpected calls slip through, and every interaction is traceable for audit.
In many organizations, the reality looks very different. Engineers bake permanent API keys into MCP configuration files, share those keys across teams, and allow any service account to invoke the MCP endpoint at any time. The result is a flat‑out trust model where a compromised secret gives an attacker unrestricted access to the model serving pipeline, and there is little visibility into who called what and when.
Why just-in-time access matters for MCP
Just-in-time access means granting the minimum privilege needed for a single operation, and revoking it automatically after the operation completes. For an MCP server, this translates into issuing a token that is valid for a few minutes, tied to a specific user or automation identity, and optionally gated by an approval workflow. The benefits are clear:
- Reduced blast radius – a leaked token expires quickly.
- Clear accountability – each request can be linked to an identity and an approval event.
- Compliance‑ready evidence – auditors can see who accessed the model, when, and under what policy.
Implementing just-in-time access, however, is not just a matter of swapping a static key for a short‑lived one. The request still travels directly to the MCP service, which means the service itself must be trusted to enforce expiry, record the call, and apply any masking rules. If the service is compromised or mis‑configured, those guarantees disappear.
The missing enforcement layer
What you can control in the setup phase is the identity source. By configuring OIDC or SAML with your corporate IdP, you ensure that every token presented to MCP carries a verified subject, group membership, and optional claims for just-in-time policies. You can also provision service accounts with the narrowest possible IAM permissions. This setup decides who may start a request, but it does not enforce what happens once the request leaves the identity provider.
Without a dedicated data‑path component, the request reaches MCP directly. At that point there is no central place to:
- Validate that the token is still within its short‑lived window.
- Require an on‑demand approval before the operation proceeds.
- Record the full request and response for later replay.
- Mask any sensitive fields that MCP might return, such as internal model identifiers.
Those enforcement outcomes only appear when a gateway sits between the identity layer and the MCP endpoint.
hoop.dev as the enforcement point
hoop.dev is a Layer 7 gateway that proxies connections to infrastructure services, including MCP. It sits in the data path, inspects the wire‑protocol, and applies policy before the request reaches the target. Because hoop.dev is the only place the traffic passes, it can guarantee the just-in-time access guarantees you need.
Setup: You configure your corporate IdP (Okta, Azure AD, Google Workspace, etc.) as an OIDC provider for hoop.dev. Tokens issued by the IdP are presented to hoop.dev, which validates the signature and extracts the identity attributes. You also define service accounts with the narrowest possible permissions for the MCP connector.
The data path: When a client calls the MCP endpoint, the request is routed through hoop.dev. The gateway checks the token’s expiry, looks up any required approval workflow, and decides whether to forward the request. Because the gateway is the only place the traffic is visible, it can enforce just-in-time policies consistently.
Enforcement outcomes: hoop.dev records each MCP session, capturing the full request and response for replay. It masks sensitive fields in the response according to your policy, ensuring that downstream logs never contain raw identifiers. If a command is deemed unsafe, hoop.dev blocks it before it reaches MCP. In all cases, the agent never sees the underlying credential – hoop.dev holds it and presents a short‑lived token on the agent’s behalf.
What to watch for when enabling just-in-time access for MCP
- Token lifetime vs. workflow latency: Choose an expiry short enough to limit exposure but long enough to accommodate human approval when required.
- Approval granularity: Define policies that require approval for high‑impact model operations (e.g., changing inference parameters) while allowing low‑risk calls to proceed automatically.
- Audit completeness: Verify that hoop.dev’s session logs include both request metadata and response payloads you need for compliance.
- Masking policy scope: Identify which fields in MCP responses must be redacted and configure hoop.dev to mask them consistently.
- Agent placement: Deploy the hoop.dev agent close to the MCP service to minimize latency and avoid network segmentation issues.
- Fail‑open vs. fail‑closed: Decide how the system should behave if hoop.dev becomes unavailable – typically a fail‑closed posture is safest for security.
- Scaling considerations: Ensure the gateway can handle the peak request rate of your MCP workloads without becoming a bottleneck.
Addressing these points early prevents the common pitfalls of “just‑in‑time” projects that end up with broken approvals or missing audit trails.
Getting started
To try this approach, follow the getting‑started guide for hoop.dev. The documentation walks you through deploying the gateway, connecting it to your IdP, and configuring an MCP connector with just‑in‑time policies. For deeper policy examples, see the learn section where masking and approval workflows are described in detail.
Frequently asked questions
Can I use an existing OIDC provider?
Yes. hoop.dev acts as a relying party, so any OIDC‑compliant IdP can issue the tokens that drive just‑in‑time decisions.
How does hoop.dev record MCP sessions?
hoop.dev captures the full request and response at the protocol layer, stores the data in a durable log, and makes it available for replay or audit queries.
What happens if an approval is denied?
hoop.dev blocks the request before it reaches MCP and returns an informative error to the caller. No partial execution occurs.
Ready to see just‑in‑time access in action? Explore the source code and contribute on GitHub.
