Are you confident that every computer you log into respects your organization’s iam policies?
Current reality of computer access
Most teams still rely on a mix of local administrator accounts, shared passwords, and static service credentials that sit on workstations or in password vaults. An engineer may copy a password from a spreadsheet, paste it into an RDP client, and gain unrestricted access to a machine. The same credential often grants entry to multiple servers because administrators prefer convenience over granular control. Teams limit auditing to occasional log file reviews, and they rarely record which command was run, which data was displayed, or who approved the session.
These practices leave a large attack surface. If a password leaks, it exposes every system that trusts it. If an employee leaves, revoking a single account does not guarantee removal of cached credentials on other machines. The lack of real‑time visibility lets suspicious activity go unnoticed until after damage occurs.
Why iam alone isn’t enough
Implementing iam by assigning users to groups, creating role‑based policies, and provisioning service accounts is a necessary first step. It tells the identity provider who may request a connection and under what conditions. However, the endpoint itself remains the enforcement point. When a user launches an SSH or RDP client, the request travels directly to the target computer, bypassing any central control plane.
Because the connection bypasses a gateway, the system cannot apply just-in-time approval, block dangerous commands, or mask sensitive fields that appear in a terminal session. The endpoint still sees the raw credential, and the system does not create an immutable audit trail for each keystroke or response. In short, iam defines who may ask for access, but without a data path enforcement layer, the request reaches the resource unchecked.
hoop.dev as the enforcement layer
hoop.dev provides the missing data path that sits between the identity system and the computer you are trying to reach. It acts as a layer 7 gateway that proxies SSH, RDP, and other remote‑access protocols. Users authenticate through an OIDC or SAML provider; hoop.dev validates the token, reads group membership, and then decides whether the request may proceed.
Once the request is authorized, hoop.dev holds the credential for the target computer. The user never sees the password or private key. The gateway then forwards the traffic, inspecting each protocol message in real time. Because the gateway is the only place the traffic passes, hoop.dev can enforce several outcomes:
- Just-in-time access: hoop.dev creates a short-lived approval window for each session, eliminating standing credentials.
- Inline data masking: hoop.dev redacts any response that contains credit‑card numbers, personal identifiers, or other regulated data before it reaches the user’s terminal.
- Command blocking: hoop.dev intercepts and rejects dangerous commands such as rm -rf / or privileged database queries.
- Session recording: hoop.dev captures every keystroke and screen output, stores it outside the target, and makes it replayable for forensic analysis.
All of these controls happen because hoop.dev occupies the data path. The iam system only tells hoop.dev who the caller is; hoop.dev decides what happens to the request.
Key enforcement outcomes
When hoop.dev sits in front of your computers, you gain concrete security benefits that iam alone cannot provide:
- Auditable evidence: hoop.dev generates a log for each session, recording the identity, time, commands issued, and any masked data.
- Reduced blast radius: because credentials are never exposed to the end user, a compromised workstation cannot be used to harvest passwords for other systems.
- Human oversight on high‑risk actions: hoop.dev automatically routes requests that match a risky pattern to an approver, ensuring privileged operations receive explicit consent.
- Compliance support: hoop.dev provides recorded evidence that auditors can review as proof that access to sensitive systems is governed, approved, and monitored.
For a quick start, see the getting‑started guide. Detailed feature descriptions are available in the learn section of the documentation.
FAQ
How does hoop.dev integrate with existing iam groups?
hoop.dev reads the groups attached to the OIDC token and maps them to policies that define which computers a user may reach and what actions are allowed during a session.
Does hoop.dev eliminate the need for local administrator passwords?
Yes. Because hoop.dev stores the target credentials and presents short‑in‑time tokens to the user, local admin passwords are no longer required on the workstation.
What evidence does hoop.dev provide for auditors?
hoop.dev includes the user identity, timestamps, command history, and any data‑masking events in each recorded session. It records the logs in a location separate from the target system, allowing the logs to be exported for audit reviews.
Ready to see how the gateway works in practice? Explore the source code and contribute on GitHub.
