Many engineers assume that a permanent service‑account token is sufficient to run an MCP server on Kubernetes, but that approach ignores just-in-time access requirements. In reality, static credentials give every holder unrestricted cluster access and leave no record of what was done. Typical deployments hand out a kubeconfig file that contains a long‑lived token, assign a cluster‑wide role, and let developers connect directly to the API server. The connection bypasses any approval workflow, the commands are not recorded, and sensitive responses are streamed in clear text. If a compromised token lands in the hands of an attacker, the blast radius can be catastrophic. What teams really need is just-in-time access: a user should receive a short‑lived, narrowly scoped credential only at the moment a specific MCP server is invoked. The request still travels straight to the Kubernetes API server, but without a control point the request cannot be inspected, approved, or logged.
A protocol‑aware gateway placed between identity and the cluster can enforce this model.
A dedicated gateway can implement exactly this pattern, becoming the sole data‑path for every request, inspecting each call, issuing short‑lived credentials, recording activity, and masking sensitive fields before the response reaches the client.
Setup: identity and provisioning
First, configure an OIDC or SAML provider (Okta, Azure AD, Google Workspace, etc.) as the source of user tokens. The provider authenticates the engineer and returns a JWT that includes group membership. hoop.dev validates the token, extracts the identity, and maps groups to the permissions required for a particular MCP server. This step determines who the request is and whether it may start, but it does not enforce any runtime guardrails.
The data path: hoop.dev as the gateway
All traffic to the Kubernetes API server, including calls that reach an MCP server pod, is forced through hoop.dev. An agent runs inside the same network segment as the cluster, and the gateway proxies the request at the protocol level. Because the gateway sits in the data path, it is the only place where enforcement can happen.
When a user initiates a connection, hoop.dev checks the request against the just‑in‑time policy. If the policy allows the operation, hoop.dev issues a short‑lived token that is scoped to the specific MCP server and the exact operation. The token is never exposed to the user; the gateway forwards the request using its own service‑account credential.
Enforcement outcomes delivered by hoop.dev
- hoop.dev grants just‑in‑time credentials that expire after the approved session.
- hoop.dev records each command and response, creating a replayable audit trail.
- hoop.dev masks sensitive fields, such as secrets returned by the MCP server, before they reach the client.
- hoop.dev blocks disallowed commands in real time, preventing accidental or malicious actions.
- hoop.dev routes high‑risk operations to a human approver, ensuring intent‑based access.
These outcomes exist only because hoop.dev sits in the data path. Without the gateway, the static token would continue to provide unrestricted access, and none of the above controls would be enforceable.
Why just‑in‑time matters for MCP servers
MCP servers often expose internal data models or trigger downstream workflows. Granting permanent access to them increases the risk of data leakage and unintended side effects. By requiring a just‑in‑time grant, teams limit exposure to the exact moment of need, reduce the attack surface, and gain full visibility into who performed which operation.
Because the gateway records every interaction, auditors can retrieve concrete evidence of access without relying on indirect logs. The inline masking feature ensures that even privileged users never see raw secret values unless explicitly authorized.
Getting started
To try this pattern, follow the getting‑started guide for deploying the hoop.dev gateway and agent. The documentation explains how to connect the gateway to your OIDC provider, register a Kubernetes cluster, and define just‑in‑time policies for MCP servers. For deeper details on policy syntax and masking options, see the learn page.
FAQ
How does just‑in‑time access differ from a permanent service account?
Just‑in‑time access grants a temporary, narrowly scoped credential only for the duration of a specific operation. A permanent service account provides ongoing, broad permissions that cannot be revoked per request.
Does hoop.dev record commands executed against an MCP server?
Yes, hoop.dev records each request and response, creating a replayable session log that can be inspected for compliance or forensic analysis.
Can I require manual approval for certain MCP operations?
hoop.dev can route high‑risk commands to a designated approver before the gateway forwards them to the cluster, ensuring that privileged actions are explicitly authorized.
Next steps
Explore the source code and contribute on GitHub. The repository includes example policies and deployment manifests to help you secure your MCP servers with just‑in‑time access.
