Static credentials give attackers a foothold that lasts until someone notices, and they completely defeat just-in-time access controls.
Most teams that integrate MCP gateways embed long‑lived API keys or service‑account tokens directly in application code, CI pipelines, or configuration files. Those secrets travel unchanged from developer machines to production containers, and they are never revoked unless an incident forces a manual rotation. The result is a permanent bridge between any compromised identity and the underlying model‑serving infrastructure.
When a key leaks, an adversary can issue unlimited generation requests, extract proprietary prompts, or consume costly compute resources. Because the connection bypasses any checkpoint, there is no record of who issued the request, what data was returned, or whether the operation complied with policy. Even organizations that schedule periodic key rotation still expose a wide attack surface during the interval between rotations.
Just‑in‑time access promises to replace static secrets with short‑lived, request‑scoped tokens that expire as soon as the operation finishes. It narrows the window of opportunity and ties each request to an identity. However, granting a temporary token does not by itself create visibility, enforce content policies, or stop a malicious command from reaching the MCP service.
What remains missing is a control point that sits between the identity provider and the MCP gateway, inspects every request, enforces approval workflows, masks sensitive payloads, and records the full session for later review. Without that data‑path enforcement, just‑in‑time access alone cannot guarantee that a request is safe, auditable, or reversible.
Why the data path matters
Placing a gateway in the communication flow creates a single enforcement surface. The gateway validates the identity token, checks the requested operation against policy, and can either allow, block, or route the request for manual approval before it reaches the MCP service.
Introducing hoop.dev as the enforcement layer
hoop.dev is a Layer 7 gateway that proxies connections to MCP gateways. It sits in the data path, receives the user’s OIDC or SAML token, and determines whether the request satisfies the just‑in‑time policy. Because the gateway is the only point where traffic is inspected, it can enforce a full set of controls.
hoop.dev records each session, providing a replayable audit trail that ties every request back to the originating identity. It masks sensitive fields in responses, ensuring that downstream logs or screenshots never expose confidential prompts or results. When a request exceeds a predefined risk threshold, hoop.dev routes it to an approver and blocks execution until explicit consent is recorded. All of these outcomes happen because hoop.dev sits in the data path, not because the identity system or the MCP service is changed.
The setup phase still relies on standard identity providers: OIDC, SAML, or service‑account tokens define who can start a request and what scopes are allowed. Those tokens are never enough on their own; they simply tell hoop.dev who is asking. The gateway then applies just‑in‑time approval, inline masking, command blocking, and session recording before the request ever reaches the MCP target.
How the workflow looks
- A developer authenticates with the corporate IdP and receives an OIDC token.
- The developer’s client contacts hoop.dev, presenting the token.
- hoop.dev validates the token, checks the requested MCP operation against policy, and decides whether to grant a short‑lived credential.
- If the operation is low‑risk, hoop.dev issues a temporary credential and forwards the request to the MCP gateway.
- If the operation is high‑risk, hoop.dev pauses the request, notifies an approver, and only forwards once approval is recorded.
- During the session, hoop.dev masks any fields marked as sensitive and records the full request/response flow.
- After the session ends, the recorded audit can be replayed for compliance or incident investigation.
Getting started
To try this pattern, follow the getting‑started guide and review the feature documentation for details on configuring just‑in‑time policies, approval workflows, and masking rules.
FAQ
What exactly is just-in-time access?
It is the practice of issuing short‑lived, request‑scoped credentials that expire as soon as the operation completes, reducing the attack window compared to permanent secrets.
How does hoop.dev enforce just-in-time access for MCP gateways?
hoop.dev validates the caller’s identity, checks the request against policy, and either issues a temporary credential or requires manual approval before forwarding the request to the MCP service.
Does hoop.dev store any permanent credentials?
No. All long‑lived secrets remain in the gateway’s configuration, and every request receives a transient credential that is never persisted beyond the session.
Explore the open‑source repository on GitHub
