A recently offboarded contractor still has a daemon running on a build server, automatically pulling secrets and opening SSH tunnels to production databases.
In many organizations that run self‑hosted deployments, each team spins up its own agent to reach a specific resource. Those agents carry long‑lived credentials, are registered in ad‑hoc scripts, and rarely get decommissioned when the project ends. The result is a tangled web of processes that can reach any internal system without a single point of visibility.
Why agent sprawl hurts security
Agent sprawl expands the attack surface in three ways. First, every lingering credential becomes a potential foothold for an attacker who compromises a single host. Second, uncontrolled agents can chain together, allowing lateral movement across environments that were thought to be isolated. Third, without a central audit log, security teams cannot reconstruct who accessed what, when, or why.
What a proper control surface looks like
What teams really need is a way to keep the convenience of self‑hosted agents while eliminating uncontrolled proliferation. The ideal solution lets identities authenticate once, then enforces policies at the moment a connection is attempted. It also provides a single place to record every command, mask confidential fields, and require human approval for risky operations. Until that point, the request still travels directly to the target, bypassing any guardrails.
hoop.dev as the data‑path gateway
hoop.dev fulfills that requirement by acting as a Layer 7 gateway that sits in the data path between every identity and the infrastructure it reaches. Because the gateway proxies the wire‑protocol, it can inspect each request, enforce just‑in‑time approvals, apply inline masking, and capture a full session transcript before the traffic ever touches the backend service.
Just‑in‑time access and approvals
When a user launches a database client, hoop.dev first validates the OIDC token, checks group membership, and then decides whether the connection may proceed. If the request matches a policy that requires approval, the gateway pauses the session, routes the command to an approver, and waits for explicit consent. Only after consent does the traffic flow to the database, and hoop.dev logs the whole exchange.
Inline data masking
The gateway filters responses that contain credit‑card numbers, personal identifiers, or internal keys in real time. hoop.dev replaces those fields with placeholder values before they reach the client, ensuring downstream tools never see raw secrets.
Session recording and replay
hoop.dev records every session, from the initial handshake to the final quit command. hoop.dev stores the recordings outside the agent’s host, so audits can rely on reliable evidence. Teams can replay a session to see exactly which statements were run, which rows were returned, and whether any masked data was requested.
Scope access per identity
hoop.dev maps each OIDC group to a set of allowed target resources and permissible commands. When a user from the analytics group attempts to dump a production table, the gateway checks the policy and denies the operation if it exceeds the group’s privilege level. This fine‑grained mapping prevents broad tokens from being used across unrelated services.
Auditable approvals
For high‑risk actions such as schema changes or bulk deletions, hoop.dev triggers a workflow that notifies designated reviewers via email or chat. Reviewers can grant or deny the request with a single click, and hoop.dev records the decision alongside the session log. The record provides a clear audit trail for privileged operations.
Operational monitoring
Because every command passes through the gateway, you can feed the logs into a SIEM or alerting system. Unusual patterns, like repeated failed queries or attempts to access masked fields, generate real‑time alerts. The visibility into each request helps you detect compromised agents before they cause damage.
Policy as code
hoop.dev stores policies in a declarative format that lives alongside your infrastructure code. When you update a policy file and redeploy the gateway, the new rules take effect instantly for all agents. This approach lets you version‑control access decisions, review changes in pull requests, and roll back if a rule introduces an unexpected restriction.
Getting started
To begin, follow the self‑hosted quick‑start guide, which provisions the gateway, registers a connection, and connects your existing tools with no code changes. The documentation walks through OIDC integration, credential storage, and policy definition. For deeper details on masking rules and approval workflows, see the learn section.
FAQ
How does hoop.dev prevent new agents from being added without oversight?
Because every connection must pass through hoop.dev, any attempt to register a new agent triggers the gateway’s policy engine. If the policy does not allow the addition, hoop.dev blocks and logs the request.
Can existing agents still operate after hoop.dev is in place?
Existing agents continue to run, but hoop.dev intercepts their traffic. The gateway can reject commands that violate policies, so the agents cannot bypass the enforced controls.
What happens to logs if an agent is compromised?
hoop.dev stores the session logs outside the agent’s host, so compromising the agent does not erase the recorded evidence. Auditors can still replay the session to see what actions were taken.
Explore the source code and contribute on GitHub.
