A Guide to Just-in-Time Access in Tool Use

When an offboarded contractor’s SSH key remains on a production server, any future connection using that key instantly inherits full admin rights. The same pattern repeats when CI pipelines store long‑lived API tokens or when a developer is granted a broad service‑account role that never expires. Those static secrets give anyone who discovers them unfettered entry into critical systems.

Providing just-in-time access to tools can eliminate that lingering risk, but most teams still rely on standing credentials because they are simple to manage. The result is a gap between identity verification and actual command execution: an authenticated user can reach the target database, Kubernetes cluster, or remote host directly, without any gate that records what was done, masks sensitive fields, or forces a human approval before a dangerous operation runs.

Why the precondition alone is insufficient

Implementing a non‑human identity, such as a service account token issued by an IdP, covers the “who” part of the request. It tells the system which principal is making the call and can enforce least‑privilege scopes at token issuance time. However, the request still travels straight to the backend resource. No audit trail is captured, no inline data masking occurs, and there is no mechanism to pause a command for review. In other words, the identity check is necessary but not sufficient for a secure just‑in‑time workflow.

Introducing a data‑path gateway

Placing a Layer 7 gateway between the identity layer and the target resource creates the enforcement point that the precondition lacks. The gateway inspects every protocol message, applies policy, and logs the interaction before it reaches the backend. This is where just-in-time access becomes enforceable.

hoop.dev provides that gateway. It sits on the network, proxies connections to databases, Kubernetes clusters, SSH servers, and HTTP APIs, and enforces policies at the protocol level. Because the gateway holds the credential, the client never sees the secret. The gateway can:

• Record each session for replay and audit.
• Mask sensitive fields in query results or command output.
• Require a just‑in‑time approval workflow before executing high‑risk commands.
• Block disallowed commands outright.
• Scope access to a single operation or a short time window.

All of these enforcement outcomes exist only because hoop.dev sits in the data path. If the gateway were removed, the same identity token would still allow direct access, but none of the above protections would be applied.

How the model works in practice

When a developer needs to run a migration against a PostgreSQL instance, they request access through the gateway. The request is tied to their identity, and a short‑lived session token is minted for that specific operation. The gateway forwards the connection to the database using its own stored credentials, while simultaneously logging every statement and masking any column marked as sensitive. If the migration includes a destructive “DROP DATABASE” command, hoop.dev can pause the request and route it to an approver for confirmation.

Similarly, a CI job that needs to push a Docker image can be granted just‑in‑time write access to an internal registry. The job authenticates to the gateway, which then proxies the request, records the push, and ensures no secret environment variables are leaked in logs.

Common pitfalls and how to avoid them

One frequent mistake is to assume that issuing short‑lived tokens alone solves the problem. Tokens still travel directly to the backend unless a gateway intercepts the traffic. Another trap is to place the gateway inside the same host that runs the workload; a compromised host could then bypass the gateway. The recommended pattern is to run the gateway as a network‑resident service, ideally on a separate node or as a sidecar that the workload cannot reconfigure.

Teams also sometimes forget to define which data fields require masking. Without explicit masks, sensitive columns appear in logs and session replays. Defining a data‑classification policy and feeding it to hoop.dev ensures that any response containing personal identifiers or secret keys is automatically redacted before storage.

Design considerations for scale

Because hoop.dev operates at Layer 7, it can handle many concurrent connections without becoming a bottleneck, provided it is deployed with sufficient resources. Horizontal scaling is achieved by adding more gateway instances behind a load balancer; each instance shares the same policy store, so approvals and audit data remain consistent. When scaling, ensure that the underlying credential store is also highly available, otherwise a single point of failure could interrupt access.

hoop.dev records each session and retains the audit trail for the configured retention period, allowing teams to review activity long after the connection ends.

Getting started

To try this approach, follow the getting‑started guide and review the feature documentation for details on policy configuration, approval workflows, and session replay.

FAQ

Is just‑in‑time access compatible with existing CI pipelines?

Yes. The gateway can issue short‑lived tokens that CI jobs use just like any other credential, without changing the pipeline code.

Does the gateway store any user secrets?

No. The gateway holds the service‑side credential only; users never see it, and all secrets remain inside the protected network.

Can I audit who ran which command after the fact?

hoop.dev records each session, so you can replay the exact command sequence and see the associated identity.

Explore the source code and contribute on GitHub.