When a contractor leaves a project, the scripts they wrote for CI still run nightly, and the service accounts they created continue to poll internal APIs. The same pattern repeats when a feature team spins up a fleet of short‑lived agents for a data‑migration job, only to forget to retire them once the job finishes. Over time the environment accumulates dozens of agents, each with its own credential set, each capable of reaching databases, Kubernetes clusters, or internal HTTP services directly.
That accumulation is what security teams call *agent sprawl*. It creates three hidden dangers. First, the credential surface area explodes: every token, password, or key stored on a host becomes a potential entry point. Second, visibility disappears; because each agent talks straight to the target, there is no single log that shows who ran what command and when. Third, policy enforcement becomes impossible – there is no place to inject approval workflows, mask sensitive fields, or block dangerous commands before they hit the resource.
Most organizations address the problem by tightening IAM policies on each service account or by manually revoking credentials after a job completes. Those steps are necessary, but they stop at the identity layer. The request still travels directly to the target, bypassing any audit, masking, or just‑in‑time (JIT) approval. In practice that means a rogue or compromised agent can still execute destructive queries, delete pods, or exfiltrate data without ever being noticed.
Why a centralized data‑path control is required
Identity and provisioning (the Setup) decide who may start a connection. They can enforce least‑privilege roles, OIDC‑based authentication, and short‑lived tokens. However, without a control point that sits between the agent and the resource, those decisions cannot be enforced on the actual traffic. The enforcement outcomes, command‑level audit, inline data masking, JIT approvals, and session recording, must happen where the data flows, not just at the token‑validation stage.
How a Layer 7 gateway solves agent sprawl
Enter a Layer 7 gateway that proxies every connection to infrastructure. The gateway runs an agent inside the customer network, holds the credentials for the target service, and presents a single, identity‑aware endpoint to all orchestrated agents. Because every request passes through the gateway, it becomes the only place where policy can be applied.
hoop.dev implements exactly this pattern. It sits in the data path and intercepts the wire‑protocol of each supported target, PostgreSQL, MySQL, SSH, Kubernetes exec, HTTP APIs, and more. When an orchestrated agent initiates a session, hoop.dev validates the user’s OIDC token, maps group membership to a policy, and then decides whether to allow the connection, require an approval, or mask certain fields in the response.
Enforcement outcomes that only the gateway can provide
- Session recording: hoop.dev records every command and response, storing a replay‑able audit trail that survives the lifetime of the agent.
- Inline data masking: sensitive columns such as credit‑card numbers or personal identifiers are redacted in real time before they reach the orchestrating process.
- Just‑in‑time approvals: high‑risk operations (e.g., DROP DATABASE, privileged pod deletion) are routed to a human approver and only proceed after explicit consent.
- Command blocking: patterns that match a deny list (e.g., destructive shell commands) are stopped before they reach the target.
- Identity‑driven access: policies are expressed in terms of groups, roles, or service accounts, ensuring that a compromised token cannot exceed its intended scope.
Putting the pieces together
The workflow looks like this:
- Provision an OIDC identity provider (Okta, Azure AD, Google Workspace, etc.) and configure groups that reflect the orchestration responsibilities.
- Deploy the gateway using the quick‑start Docker Compose or a Kubernetes manifest. The gateway runs a local agent that holds the credentials for each target resource.
- Register each infrastructure endpoint (database, Kubernetes cluster, SSH host) in the gateway configuration. The gateway stores the service credentials; agents never see them.
- When an orchestrated job starts, it authenticates to the gateway with its OIDC token. hoop.dev validates the token, consults the policy, and either grants a session, asks for approval, or denies the request.
- During the session, hoop.dev records every interaction, masks sensitive data, and enforces command‑level guards.
This pattern eliminates agent sprawl because every agent, regardless of how it was created, must pass through the same enforcement point. The result is a clean audit trail, reduced blast radius, and the ability to retire agents without worrying about lingering credentials.
Getting started
For a hands‑on walkthrough, see the getting‑started guide. It walks you through deploying the gateway, configuring OIDC, and registering a PostgreSQL instance. The learn section provides deeper coverage of masking policies, approval workflows, and session replay.
FAQ
Does hoop.dev replace existing IAM policies?No. It complements them. IAM still decides who can obtain a token; hoop.dev decides what that token can do once it reaches a resource.Can I use hoop.dev with existing CI pipelines?Yes. CI jobs authenticate with an OIDC token and then connect through the gateway just like any other client.What happens to the recorded sessions?Sessions are stored in a configurable backend. They can be replayed for forensic analysis or compliance reporting.
Ready to bring order to your orchestration layer? Explore the source code and contribute on GitHub.
