A mature organization sees every piece of work broken into discrete tasks, each with a clear reviewer who validates that the required permissions are appropriate before any code runs or data moves. In that world, access reviews are an integral checkpoint that prevents excess privilege from ever touching production resources.
In practice, most teams still assign work by carving out tickets or tickets in a backlog and then handing the ticket to an engineer who already holds a standing set of credentials. Those credentials are often shared service accounts, long‑lived SSH keys, or admin database users that give the assignee far more power than the task requires. The hand‑off happens without a formal review, and the engineer can execute any command the account permits. No audit trail records which command was run for which task, and no one can prove that the access matched the intent of the work.
This gap creates three concrete problems. First, over‑privileged accounts expand the blast radius of a simple mistake or a compromised credential. Second, compliance programs that require evidence of “least‑privilege access” struggle to produce the necessary logs because the system never records who approved a particular permission. Third, incident responders waste time reconstructing who did what, because the connection between a task and the exact commands executed is missing.
What we need is a way to bind an access review directly to the task decomposition process. The review must happen before the request reaches the target system, and the enforcement point must be able to block, approve, or mask operations in real time. Simply adding a checklist in a ticketing tool does not provide the enforcement that prevents misuse; the request still travels straight to the database, SSH server, or Kubernetes API without any guardrails.
That enforcement belongs in the data path, the exact place where the request passes from the user to the infrastructure. hoop.dev fulfills this role. It sits as a Layer 7 gateway between identities and resources, inspecting traffic at the protocol level. Identity is supplied via OIDC or SAML, so the gateway knows which user or service account is making the request. Before the request is forwarded, hoop.dev can require an access review, route the request to an approver, record the entire session, and apply inline masking to any sensitive fields that appear in responses.
Because hoop.dev is the only component that sits in the data path, the enforcement outcomes, session recording, just‑in‑time approval, command‑level blocking, and real‑time masking, exist only because hoop.dev is present. The setup (OIDC tokens, IAM roles, service accounts) decides who may start a connection, but without hoop.dev the connection would reach the target directly, bypassing any audit or approval. By inserting hoop.dev, every task‑driven request is forced through a single, policy‑driven gateway that can enforce the access review before any command touches the backend.