When access reviews for computer use are continuously enforced, every workstation session is provably authorized, every command is logged, and any sensitive output is automatically hidden from eyes that should not see it. In that world, auditors can verify that only the right people performed the right actions, and security teams can intervene before a mistake becomes a breach.
Access reviews are the process of confirming that a user’s right to use a particular computer or service is still valid at the moment of use. For laptop‑based developers, remote engineers, and automated agents, the review must happen at the exact second a connection is opened, not weeks later in a spreadsheet.
Why access reviews matter for computer use
Most organizations still rely on static local accounts, shared admin passwords, or long‑lived service credentials to let engineers log into workstations. Those credentials are often copied across machines, stored in plain‑text files, or embedded in scripts. The result is a sprawling attack surface: if a single password leaks, an attacker can hop between dozens of machines without any record of what they did.
Beyond credential sprawl, the lack of real‑time review means that privileged actions – installing software, exporting databases, or changing firewall rules – happen without any gate. Even well‑intentioned engineers can run a destructive command by mistake, and there is no immutable audit trail to prove who did what.
What the current setup gets wrong
In many teams, the only guard is the initial login prompt. Identity providers issue a token, the workstation trusts the token, and the user is handed a shell. From that point onward the request travels directly to the operating system, bypassing any enforcement point. The setup decides who may start a session, but it does not inspect the commands that follow, does not mask data that appears on the screen, and does not retain a replayable record of the interaction.
Because the enforcement boundary is missing, two gaps remain open: first, there is no way to approve a risky operation before it runs; second, there is no systematic way to capture the session for later review. The organization is left with a false sense of security – the identity check passed, but nothing else is guaranteed.
How a data‑path gateway enables continuous access reviews
hoop.dev sits in the data path between the user and the workstation. It acts as an identity‑aware proxy that terminates the user’s connection, applies policy, and then forwards the allowed traffic to the target machine. Because every packet passes through hoop.dev, it can enforce the same controls that a true access review requires.
hoop.dev records each session, preserving a replayable log that shows every keystroke and output line. It masks sensitive fields – such as passwords or personal identifiers – in real time, so that logs never expose data that should remain private. When a command matches a risky pattern, hoop.dev blocks it before it reaches the OS. For operations that need human sign‑off, hoop.dev routes the request to an approver and only continues once approval is granted.
Because the gateway is the sole point where traffic is inspected, the enforcement outcomes exist only because hoop.dev is present. Remove hoop.dev and the session would flow directly to the workstation, losing all of the above guarantees.
Setting up the identity foundation
The first step is to configure an OIDC or SAML identity provider – for example Okta, Azure AD, or Google Workspace – and issue short‑lived tokens to users and service accounts. The token tells hoop.dev who is requesting access, but the token alone does not enforce any rule. hoop.dev reads the token, extracts group membership, and uses that information to decide whether a request may proceed to the next stage.
Least‑privilege grants are defined in the identity provider, ensuring that a user only receives the claims needed for their role. However, without a data‑path gateway, those claims cannot be turned into real‑time policy decisions.
Enforcement outcomes that matter
- hoop.dev records every interactive session, giving auditors a complete replayable history.
- hoop.dev masks sensitive output on the fly, preventing accidental exposure in logs.
- hoop.dev blocks dangerous commands before they reach the operating system.
- hoop.dev requires just‑in‑time approval for high‑risk actions, adding a human check at the moment of execution.
- hoop.dev isolates credentials from the user, so the agent never sees the underlying secret.
All of these outcomes are achieved because the gateway sits in the data path; they cannot be obtained by identity configuration alone.
Getting started
To try this approach, follow the getting started guide which walks you through deploying the gateway, registering a workstation target, and connecting via your usual SSH client. The learn section provides deeper coverage of session recording, inline masking, and approval workflows.
FAQ
Do I need to change my existing SSH keys? No. hoop.dev holds the credential for the target machine, so users continue to authenticate with their identity provider instead of a static SSH key.
Can I retroactively audit sessions that happened before hoop.dev was deployed? Only sessions that pass through the gateway are recorded. Historical activity outside the data path remains outside the audit scope.
Is the gateway a single point of failure? hoop.dev can be run in a highly available configuration; the documentation explains clustering and fail‑over patterns.
Explore the source code and contribute on GitHub.
