How can you let a service account spin up an MCP server only when it really needs one, without handing out long‑lived passwords? just-in-time access is the only way to grant permissions that automatically expire after the operation completes.
Most teams today give engineers and automation bots a static credential that lives in a vault, a CI secret store, or even a hard‑coded string. The credential is checked out whenever a pipeline runs, and the MCP server trusts anyone who presents it. Because the connection goes straight from the agent to the server, there is no record of who issued a command, no chance to scrub sensitive fields from the response, and no way to require a human to approve a risky operation. The result is a wide attack surface: compromised tokens can be reused indefinitely, and auditors have no reliable evidence of who accessed what and when.
Switching to an identity‑driven model solves the first part of the problem. By issuing non‑human identities from Okta, you can enforce least‑privilege scopes and short‑lived tokens. The identity tells the gateway who is making the request and whether the request should be allowed to start. However, the request still travels directly to the MCP server. Without a control point in the data path, you still lack just-in-time access, approval workflows, inline masking, or session recording. In other words, the identity check is necessary but not sufficient to achieve secure, auditable access.
Why just-in-time access matters for MCP servers
Just-in-time access means granting permission at the moment of need and revoking it automatically after the operation completes. For MCP servers this reduces the window of exposure dramatically. If a compromised token appears, it cannot be reused because the gateway will only issue a short‑lived session after an explicit approval. Inline masking ensures that any response containing secrets, like API keys returned by the server, are stripped before they reach the client. Session recording captures every command and response, giving you a replayable audit trail that satisfies compliance requirements without adding friction to developers.
Introducing hoop.dev as the enforcement point
hoop.dev sits on the network right before the MCP server. It acts as a Layer 7 gateway that inspects the protocol, applies policies, and forwards traffic only after the policies are satisfied. The gateway trusts the Okta‑issued token, extracts the user or service identity, and then decides whether to grant a just-in-time session.
Because hoop.dev is the only place where enforcement occurs, it can provide the full set of outcomes you need:
- It creates a just-in-time session that expires automatically, preventing lingering credentials.
- It routes high‑risk commands to a human approver before they reach the MCP server.
- It masks sensitive fields in responses, ensuring secrets never leave the gateway in clear text.
- It records every interaction for replay, giving an immutable audit log.
- It never exposes the underlying service account credentials to the caller; the gateway holds them internally.
All of these capabilities rely on hoop.dev being positioned in the data path. If you remove hoop.dev, the Okta identity still authenticates, but none of the just-in-time, masking, approval, or recording features remain.
How the flow works with Okta
First, you register an Okta application that issues OIDC tokens for your automation accounts. Those tokens are presented to hoop.dev when a client asks for an MCP server. hoop.dev validates the token against Okta, reads the groups or custom claims, and matches them to a policy that defines which MCP servers the identity may access and under what conditions.
If the policy requires approval, hoop.dev pauses the request and notifies the designated approver. Once approved, hoop.dev opens a just-in-time session, forwards the request to the MCP server, and begins recording. Any response that matches a masking rule is filtered before it leaves the gateway.
When the session ends, either because the client disconnects or the configured timeout expires, hoop.dev tears down the connection and archives the session log. No credentials are ever exposed to the client, and the audit log is stored outside the server’s control, ready for review.
Getting started
To try this pattern, start with the official getting‑started guide, which walks you through deploying the gateway, connecting an Okta OIDC provider, and registering an MCP server as a target. The documentation also covers how to define just-in-time policies, set up approval workflows, and configure masking rules.
All of the components are open source, and the repository includes example compose files for a quick local deployment. For detailed policy syntax and best‑practice recommendations, see the learning hub.
FAQ
- Do I need to change my existing MCP server credentials? No. hoop.dev holds the credential internally and presents it to the server on your behalf. Your existing server configuration remains unchanged.
- Can I use other identity providers besides Okta? Yes. hoop.dev supports any OIDC or SAML provider that can issue tokens with the required claims. The same just-in-time flow applies.
- What happens if an approval is not granted? The request is rejected and no session is created. The client receives a clear denial response, and no traffic reaches the MCP server.
Ready to see the code in action? Explore the open‑source repository on GitHub and follow the quick‑start steps to secure your MCP servers with just-in-time access today.
