Are you confident that your iam policies truly protect the tools your engineers reach?
In many organizations the reality is far messier. Engineers often share a static database password or an SSH key that lives in a shared vault, a spreadsheet, or even a plain‑text file. The same credential is used day after day to connect directly to production services. Because the connection goes straight from the client to the target, there is no central point that can see what commands are run, no way to hide sensitive fields in query results, and no record that can be replayed after the fact. The result is a blind spot that invites accidental data exposure, lateral movement, and compliance gaps.
Applying iam to this scenario sounds like a solution: grant each user a role, limit the permissions on the credential, and rely on group membership to enforce least‑privilege. In practice, iam alone does not stop the underlying problem. The credential still travels to the target unchanged, the gateway that could inspect traffic is missing, and any privileged command runs unchecked. The request reaches the database, the Kubernetes API, or the SSH daemon directly, leaving the organization without audit trails, without inline data masking, and without a way to require a human approval before a destructive operation.
Why iam alone isn’t enough for tool use
iam provides identity verification and static permission checks. It tells the system who is making a request and what static actions the role is allowed to perform. What it does not provide is context about how the request is executed. When a developer runs psql with a shared password, iam cannot see the actual SQL statements, cannot mask credit‑card numbers returned by a query, and cannot stop a DROP TABLE before it reaches the database. The enforcement point is missing, so privilege creep and accidental misuse remain possible.
The missing control layer
To close the gap, enforcement must sit on the data path itself. The gateway that proxies the connection becomes the only place where traffic can be inspected, masked, or blocked. This is where the organization can apply just‑in‑time approvals, record every session for replay, and guarantee that the underlying credential never leaves the controlled environment. The gateway also respects the iam decisions made in the setup phase – it knows which user is associated with each request because the identity token has already been validated.
Introducing hoop.dev as the data‑path gateway
hoop.dev fulfills the missing control layer. It is a layer‑7 gateway that sits between the authenticated identity and the target tool – whether that tool is a PostgreSQL database, a Kubernetes cluster, an SSH server, or an internal HTTP API. The gateway holds the credential, so the user or automation never sees it. Once a request arrives, hoop.dev applies a series of enforcement outcomes: