Many teams assume that giving a tool‑using agent a permanent credential is harmless because the agent only runs predefined jobs. In reality, that standing access creates a persistent blast radius that attackers can exploit the moment a secret is leaked.
Typical deployments store a long‑lived API token, SSH key, or database password in a CI/CD pipeline, a configuration file, or a secret manager with broad read permissions. The agent fetches the secret at start‑up, then talks directly to the target service, be it a PostgreSQL instance, a Kubernetes API, or an internal HTTP endpoint. No intermediary inspects the traffic, and the credential lives as long as the pipeline definition does.
This model leaves three critical gaps. First, any compromise of the pipeline repository instantly grants unrestricted access to the downstream resource. Second, because the connection bypasses a control plane, there is no record of which command was issued or which data was returned. Third, the agent can issue any command its credential permits, including destructive ones, without any human oversight. The result is a standing access pattern that silently expands the attack surface.
What organizations really need is a way to keep agents functional while eliminating the permanent credential that fuels standing access. The requirement is to retain the ability for automation to reach the target, but to force every request through a gate that can apply policies, request approvals, and capture evidence. Even after that gate is added, the request still travels to the backend service directly; the gate does not replace the service or rewrite its API.
hoop.dev satisfies that requirement by inserting an identity‑aware proxy between the agent and the resource. The gateway sits in the data path, so every packet, query, or command passes through it before reaching the target. Because hoop.dev is the only component that can see the request, it becomes the enforcement point for all subsequent controls.
When an automation job initiates a connection, hoop.dev first validates the OIDC or SAML token presented by the agent. After identity is confirmed, the gateway checks the request against a policy that can require just‑in‑time approval for privileged operations. If approval is needed, a designated reviewer receives a prompt; the request proceeds only after explicit consent. Regardless of approval, hoop.dev records the entire session, including each command and the corresponding response. For data that contains personally identifiable information, hoop.dev can mask sensitive fields in real time, ensuring that logs never expose raw values. If a command violates a rule, such as an attempt to drop a production database, hoop.dev blocks it before it reaches the backend. All of these outcomes, recording, masking, approval, and blocking, are performed by hoop.dev because it is the sole point where the traffic is observable.
The practical impact is a dramatic reduction in risk. Because standing access is replaced with just‑in‑time tokens, a leaked secret is useless without a valid approval flow. Auditors gain a complete trail of who did what, when, and why, satisfying evidence requirements for standards such as SOC 2. Security teams can replay any session to verify that no data exfiltration occurred, and developers retain the convenience of automated pipelines without sacrificing governance.
Teams interested in adopting this approach can start with the getting started guide to deploy the gateway and register a resource. The learn section provides deeper coverage of policy configuration, approval workflows, and masking strategies.
FAQ
Does hoop.dev eliminate the need for secret management?
No. Secrets still need to be stored for the gateway itself, but agents never receive them directly. hoop.dev retrieves the credential from its own secure store and presents it to the target on behalf of the agent.
Can existing CI/CD pipelines be used without code changes?
Yes. Because hoop.dev speaks the same wire protocols as the target services, pipelines can continue to use standard clients (psql, kubectl, curl, etc.) while routing traffic through the gateway.
What happens if an approval request is ignored?
If a request requires approval and no response is received within the configured timeout, hoop.dev denies the operation and logs the denial, preserving the audit record.
Explore the source code, contribute improvements, and see how the community extends the platform on GitHub.
