When a vendor can sit at a workstation and run commands, the organization faces vendor risk, including data exfiltration, system compromise, and costly compliance penalties. The financial impact of a single breach can dwarf the expense of preventative controls.
In many environments the reality is far worse than that headline. Teams often grant vendors a shared local account, a static password written on a sticky note, or a permanent SSH key that lives on the machine for months. The vendor logs in directly to the target server, executes arbitrary commands, and leaves no trace of what was run. There is no central log of the session, no approval workflow, and no way to hide sensitive fields that appear in query results. The result is a blind spot: the organization cannot prove who did what, cannot stop dangerous operations, and cannot protect confidential data when a vendor’s actions are unchecked.
Why vendor risk is hard to manage
Even when a policy mandates that vendors use non‑human identities or that access be scoped to the minimum set of resources, the enforcement usually stops at the identity provider. The token or role tells the system *who* is connecting, but it does not control *what* the connection can do once it reaches the host. Without a control point on the actual data path, the request still reaches the server directly, bypassing any audit, masking, or approval step. The organization is left with a compliance gap: it can claim that only approved identities exist, yet it cannot demonstrate that each privileged action was reviewed or recorded.
This gap is the core of vendor risk. The precondition – a federated identity, least‑privilege grants, and a defined vendor account – solves the identity problem but leaves the execution problem wide open. The vendor can still run destructive commands, view unmasked customer data, and exit without any evidence of their activity. To truly mitigate vendor risk, enforcement must happen where the traffic actually flows.
A gateway that puts enforcement in the data path
hoop.dev sits between the vendor’s client and the target infrastructure. By proxying the connection, it becomes the only place where traffic can be inspected, approved, masked, or recorded. Because hoop.dev is the data‑path component, every enforcement outcome originates there.
Session recording and replay
hoop.dev records each vendor session from start to finish. The recorded stream can be replayed by auditors or security teams, providing undeniable evidence of every command and response. Without this recording, the organization would have to rely on fragmented system logs that often omit interactive sessions.
Inline data masking
When a vendor runs a query that returns sensitive columns, hoop.dev can mask those fields in real time. The vendor sees only the allowed subset of data, while the underlying system still processes the full result set. This prevents accidental leakage of personal or proprietary information during routine troubleshooting.
Just‑in‑time approval
For high‑risk operations, such as schema changes, privileged user creation, or access to production clusters, hoop.dev can pause the request and route it to an approver. The approver reviews the intent, grants a temporary token, and the operation proceeds. If the request is not approved, hoop.dev blocks it before any command reaches the target.
Command‑level blocking
Policies can be defined to reject dangerous commands outright, such as destructive database commands or privileged system utilities. Because hoop.dev inspects the protocol payload, it can stop the command before the server executes it, reducing the blast radius of a rogue vendor action.
All of these capabilities rely on the gateway being the sole enforcement point. The identity provider supplies the who, but hoop.dev supplies the how and the why of enforcement.
Getting started with a secure vendor workflow
To adopt this approach, begin by deploying hoop.dev in a network segment that can reach the resources vendors need to access. The official getting started guide walks through a container‑based deployment, OIDC configuration, and agent installation. Once the gateway is running, register each target, database, SSH host, or HTTP endpoint, and define the vendor‑specific policies that govern masking, approval, and command blocking.
After the gateway is in place, create a vendor identity in your IdP, assign it the minimal group membership, and let hoop.dev enforce the rest. The result is a clear audit trail, protected data, and a workflow that stops risky actions before they happen.
Frequently asked questions
- Does hoop.dev replace my existing IAM system? No. hoop.dev consumes the identity information from your IdP and adds a layer of enforcement on the data path. Your existing IAM policies still define who can request access.
- Can I see the recorded sessions without installing additional software? Yes. The recorded sessions are stored in a searchable store that can be accessed through the web UI or API documented in the learn section. No extra agents are required on the client side.
- Is the gateway itself a single point of failure? hoop.dev can be deployed in a highly available configuration using multiple instances behind a load balancer. The architecture guide in the docs describes how to achieve redundancy.
By moving enforcement to the data path, organizations turn a vague vendor risk problem into a concrete, auditable control set. hoop.dev provides the necessary gateway to make that shift.
View the source code and contribute on GitHub.
