Uncontrolled agent loops can silently exfiltrate data and amplify breaches across an entire environment.
When a loop repeatedly polls a database, runs SSH commands, or drives Kubernetes jobs, engineers often give it a static credential stored in a file or secret manager. The loop executes dozens of requests per minute, and because the credential never changes, the system trusts every call. If an attacker steals that credential, they inherit the same unrestricted access and can issue commands at scale before anyone notices. This scenario highlights the need for effective policy enforcement at runtime.
Teams usually try to tighten the identity that the loop presents, swapping a broad service account for a narrower role or using a short‑lived OIDC token. That step reduces the blast radius of a stolen secret, but the request still travels directly to the target system. The target sees a valid identity, executes the command, and returns data without any intermediate check. No audit trail is captured beyond the target’s own logs, no sensitive fields are masked, and there is no way to require a human approval before a destructive operation.
To close that gap, the enforcement point must sit in the data path, intercepting every request before it reaches the backend. hoop.dev is a layer‑7 gateway that proxies connections to databases, SSH hosts, Kubernetes clusters, and HTTP services. By placing hoop.dev between the agent loop and the target, policy enforcement becomes a built‑in capability of the connection rather than an afterthought.
How hoop.dev delivers policy enforcement
- hoop.dev records each session, capturing the full command stream and response payloads for replay and audit.
- hoop.dev masks sensitive fields in query results or API responses, ensuring that downstream logs never contain raw secrets.
- hoop.dev blocks commands that violate predefined guardrails, such as attempts to drop tables or delete namespaces.
- hoop.dev routes high‑risk actions to a just‑in‑time approval workflow, requiring a designated approver to consent before execution.
Why the gateway model matters
The gateway model respects the three‑tier attribution required for secure enforcement. First, setup, identity providers, OIDC tokens, and service accounts decide who the request is and whether it may start. Second, the data path, the hoop.dev proxy, is the only place that can actually enforce policies. Third, the enforcement outcomes, recording, masking, blocking, and approval, exist only because hoop.dev sits in that path. If you remove hoop.dev, the agent loop talks directly to the target and loses all of those guarantees.
Implementing the gateway for an agent loop
Deploy the hoop.dev gateway in the same network segment as the resources the loop accesses. The deployment can be started with the provided Docker Compose file, which also configures OIDC authentication out of the box. Register the target connection (for example, a PostgreSQL database) in the hoop.dev UI, supplying the service‑account credential that the gateway will use. The agent loop then points its client, psql, kubectl, or ssh, to the hoop.dev endpoint instead of the raw host.
Because the gateway holds the credential, the loop never sees the secret. The loop’s identity is still verified by the OIDC token, satisfying the setup requirement, while hoop.dev applies the policy checks defined in the admin console. All of this is described in the getting‑started guide and the broader learn section for deeper policy examples.