An offboarded contractor’s CI job still holds a privileged password that a deployment script pulls from a secret store via PAM. The script runs nightly, connects directly to a production database, and writes rows without anyone seeing the command. The organization assumes the job is harmless because the credential was generated once and never changes.
In practice, many teams embed PAM‑derived secrets inside tool‑using agents, scripts, CI pipelines, or automation bots, that talk straight to the target system. The agents authenticate once, keep the password in memory, and reuse it for every execution. Because the connection bypasses any central control point, there is no record of which command was issued, no way to mask sensitive fields in responses, and no opportunity to require a human approval before a risky operation.
This pattern creates three hidden problems. First, the identity that launched the request is often a service account, not an individual, so accountability is lost. Second, the data path carries the credential end‑to‑end, meaning any compromise of the agent gives an attacker unrestricted access. Third, compliance audits struggle to prove who did what, because the session never leaves the agent’s process.
Why pam alone is not enough
pam provides a mechanism for privileged elevation, but it does not enforce runtime guardrails. When a tool‑using agent obtains a pam token, the token grants the agent full rights on the target until it expires. The request still reaches the database, SSH server, or Kubernetes API directly, without any intermediate check. No inline masking of secret columns, no just‑in‑time approval workflow, and no immutable audit trail are added by pam itself.
In other words, pam fixes the identity‑verification step but leaves the data path completely open. The organization still needs a place to inspect traffic, apply policies, and record outcomes before the request hits the protected resource.
Introducing hoop.dev as the data‑path gate
hoop.dev is a layer‑7 gateway that sits between identities and infrastructure. It receives the pam‑derived credential after the initial authentication step, then proxies the connection to the target service. Because hoop.dev is the only point where traffic passes, it can enforce every required control.
When a request arrives, hoop.dev validates the user’s OIDC token (the setup phase that decides who may start). After the identity is confirmed, the gateway becomes the sole enforcement layer. It can:
- Record each session for replay and audit, ensuring that every command is traceable.
- Mask sensitive columns or fields in real‑time responses, preventing secrets from leaking to downstream logs.
- Require just‑in‑time approval for high‑risk commands, pausing execution until a designated approver signs off.
- Block disallowed commands before they reach the target, reducing the blast radius of a compromised agent.
All of these outcomes exist only because hoop.dev sits in the data path. Without it, the setup phase, pam authentication and OIDC identity verification, cannot guarantee that the request will be inspected or recorded.
How the architecture fits together
The flow begins with a service account or CI job that authenticates to the organization’s identity provider. The provider issues an OIDC token that encodes the user’s groups and permissions. hoop.dev validates this token, maps the groups to allowed pam actions, and then establishes a short‑lived connection to the target using its own stored credential. The tool‑using agent never sees the raw password; it only talks to hoop.dev using standard client protocols (psql, ssh, kubectl, etc.).
This separation satisfies three critical security goals:
- Least‑privilege identity: The setup determines who may request access, but the gateway enforces the exact scope of each request.
- Runtime enforcement: All policy checks happen where the agent cannot tamper with them, the data path controlled by hoop.dev.
- Evidence generation: Because hoop.dev records every session and approval, teams have concrete logs for audits, incident response, and compliance reporting.
Getting started
Because hoop.dev is open source, organizations can deploy the gateway in a container or on Kubernetes and point their agents at it. The getting‑started guide walks through installing the gateway, configuring OIDC, and registering a PAM‑backed connection. For deeper policy examples, see the feature documentation.
FAQ
Does hoop.dev replace pam?
No. pam continues to provide the privileged credential. hoop.dev merely sits in front of the credential to add inspection, approval, and audit capabilities.
Can existing CI pipelines use hoop.dev without code changes?
Yes. Because the gateway speaks the same wire protocols, a pipeline can point its database client, ssh command, or kubectl invocation at the hoop.dev endpoint and retain its normal workflow.
Is the audit data stored securely?
hoop.dev writes session logs to a storage backend chosen by the operator. The logs are immutable from the perspective of the gateway, providing a reliable evidence trail for auditors.
Ready to see the code? View the source on GitHub and start building a pam‑aware, zero‑trust data path today.
