In a well‑designed self‑hosted environment, privileged access is granted only when needed, every command is recorded, and sensitive data is hidden from eyes that don’t need it. No long‑lived passwords sit in plain‑text files, no engineers can bypass approval workflows, and audit logs provide a complete replay of every admin session.
This ideal is the promise of strong PAM (privileged access management). It reduces the risk of credential theft, limits lateral movement, and gives security teams the evidence they need for investigations.
Current practice in self‑hosted environments
Many teams start with a simple approach: a shared root password stored in a wiki, a static SSH key baked into every server, or a service account whose credentials are checked into source control. Those secrets are then used directly by developers, automation scripts, and third‑party tools. The result is a sprawling “secret sprawl” that is hard to rotate, impossible to audit, and a favorite target for attackers.
Because the connection goes straight from the user’s terminal to the target host, there is no place to intervene. Commands run unchecked, data returned by the system is fully visible, and there is no immutable record of who did what. If a breach occurs, the organization often discovers it only after the damage is done.
Why a data‑path gateway is required
Self‑hosting gives you control over the underlying servers, but it does not automatically provide a control plane for privileged actions. The setup layer, identity providers, OIDC/SAML tokens, service accounts, and least‑privilege role assignments, decides who may request access. However, without a gate that sits on the data path, those requests travel directly to the resource, leaving three critical gaps:
- There is no real‑time approval step; a request is honored as soon as the token is presented.
- Dangerous commands are executed without inspection, increasing the blast radius of a compromised account.
- Session data is never captured, so forensic analysis is impossible.
In other words, the setup alone is necessary but not sufficient for true PAM. The enforcement must happen where the traffic actually flows.
How hoop.dev fulfills PAM requirements
hoop.dev acts as a Layer 7 gateway that sits between the identity layer and the target infrastructure. It proxies connections to databases, Kubernetes clusters, SSH servers, and internal HTTP services. Because the gateway intercepts the protocol stream, it is the only place where policy can be enforced.
Setup: identity and least‑privilege
Engineers authenticate against an OIDC or SAML provider. The gateway validates the token, extracts group membership, and maps those groups to fine‑grained permissions. Service accounts and role‑based policies are defined so that each identity can request only the actions it truly needs.
Enforcement outcomes
Once the request reaches the gateway, hoop.dev applies several controls:
- Just‑in‑time approval: If a command exceeds a predefined risk threshold, the gateway pauses the request and routes it to a human approver.
- Inline data masking: Sensitive fields in query results, such as credit‑card numbers or personal identifiers, are redacted before they leave the gateway.
- Command blocking: Dangerous statements (for example, DROP DATABASE or privileged kubectl verbs) are rejected outright.
- Session recording: Every byte of the interaction is stored, enabling replay and forensic analysis.
- Credential isolation: The gateway holds the target credentials; the connecting user never sees them.
Because hoop.dev is the sole point of enforcement, each of these outcomes exists only because the gateway is in the data path. Remove the gateway and the protections disappear.
Benefits of a gateway‑centric PAM strategy
Deploying hoop.dev gives you a single source of truth for privileged activity. Audit teams receive logs that capture each command together with the identity that issued it and any associated approval event. Security engineers can limit the blast radius of a compromised credential by enforcing command‑level blocks and masking. Compliance auditors gain the evidence they need for standards that require detailed access logs, even though hoop.dev itself does not claim certification.
Since the gateway runs inside your own network, you retain full control over data residency and can integrate it with existing monitoring pipelines.
Getting started
To try this approach, follow the getting‑started guide for a quick Docker‑Compose deployment. The learn section provides deeper explanations of masking policies, approval workflows, and session replay.
Explore the source code on GitHub: https://github.com/hoophq/hoop.
FAQ
Is hoop.dev compatible with any identity provider?
Yes. It works with any OIDC or SAML provider, so you can keep your existing IdP while adding a privileged‑access gate.
Can I use hoop.dev for both human engineers and automation bots?
Absolutely. Both types of identities are authenticated the same way, and the gateway can enforce different policies based on group membership.
No. It complements them by ensuring that the credentials stored in a vault are never exposed to the client. The gateway retrieves the secret at runtime and presents it only to the target resource.
