When every request to act as an impersonated agent is granted only at the moment it is needed, just-in-time access tied to a verified identity, recorded, and automatically revoked after the task completes, the risk of credential leakage disappears.
Today many teams hand out long‑lived SSH keys, static service‑account passwords, or shared API tokens to automation agents. Those credentials are often copied into scripts, stored in plaintext, and reused across environments. Because the agents run with broad privileges, a single compromised key lets an attacker impersonate any user, jump laterally, and execute commands without any real audit trail. The convenience of “one key fits all” masks a massive blind spot: there is no per‑request approval, no visibility into who ran what, and no way to limit the scope of a single operation.
Even when organizations adopt non‑human identities, service accounts, OIDC client IDs, or short‑lived tokens, the request still travels directly to the target system. The gateway that the request passes through does not inspect the payload, does not enforce a policy that the request matches the declared intent, and does not record the session for later review. In other words, the setup fixes identity provenance but leaves the data path wide open, providing no just-in-time gating, no command‑level audit, and no real‑time masking of sensitive responses.
hoop.dev is built to sit in that data path and become the enforcement point for just-in-time access.
Why the data path must host the policy
In a secure architecture the only place a request can be examined, approved, or transformed is where it passes through a trusted proxy. hoop.dev fulfills that role by acting as a Layer 7 gateway between the identity source and the infrastructure target. The gateway validates the OIDC or SAML token, extracts the user’s groups, and then decides whether the request can proceed. Because the decision happens before the request reaches the database, Kubernetes API, SSH daemon, or HTTP service, hoop.dev can enforce policies that no downstream component can bypass.
All traffic is inspected at the protocol level. If a request tries to run a destructive SQL command, access a privileged Kubernetes namespace, or open an RDP session to a production host, hoop.dev can require an additional human approval step. If the command is safe, the gateway forwards it; if it is risky, it can block execution outright. This enforcement happens regardless of which service account the agent originally used, because the gateway does not trust the credential presented to the target, it trusts only the policy decision it makes.
Enforcement outcomes that only a gateway can provide
hoop.dev records every session, creating a replayable log that auditors can review. It masks sensitive fields in responses, such as credit‑card numbers or personal identifiers, so that even a privileged operator never sees raw data unless explicitly allowed. When a request exceeds a predefined risk threshold, hoop.dev routes it to an approver for just-in-time consent. It can also block commands that match a denylist, preventing accidental data loss before it happens. Each of these outcomes, session recording, inline masking, just-in-time approval, and command blocking, exists because hoop.dev sits in the data path; without that placement none of the controls would be enforceable.
Because the gateway holds the target credentials, the impersonating agent never sees them. The agent only presents its identity token to hoop.dev, and hoop.dev uses its own stored secret to talk to the backend. This separation eliminates the possibility of credential exfiltration from the agent process.
Operational benefits for teams fighting impersonation abuse
Deploying hoop.dev reduces the blast radius of a compromised service account. Instead of a stolen key giving unlimited access, the attacker must obtain a fresh approval for each high‑risk operation, and every action is captured for forensic analysis. Teams gain clear visibility into who performed which command, when, and against which resource. The inline masking feature helps meet data‑privacy requirements without modifying application code. Because the gateway is open source, organizations can run it inside their own network, inspect the code, and extend policies to match their risk model.
Getting started is straightforward. The documentation walks you through deploying the gateway with Docker Compose, configuring OIDC authentication, and registering a target such as a PostgreSQL instance or an SSH host. For deeper guidance on policy design and audit reporting, see the learn section and the getting‑started guide.
FAQ
- What exactly is just-in-time access? It is a model where a request is granted only for the duration of the specific operation, after a real‑time policy check and, if needed, a human approval.
- How does hoop.dev enforce just-in-time access without changing existing tools? The gateway proxies standard client connections (psql, kubectl, ssh, etc.) so existing workflows remain unchanged while the gateway inserts policy checks.
- Do I need to rewrite my applications to use hoop.dev? No. You point your existing client to the gateway endpoint; the gateway forwards traffic after applying its controls.
Explore the open‑source code and contribute to the project on GitHub.
