When a contract developer hands over a Claude Agent SDK that talks to internal services, the organization often assumes the risk ends at the hand‑off. In reality, the agent continues to run in CI pipelines, on stale VMs, or inside long‑lived containers, reaching for databases and internal APIs with the same static token it received during onboarding. The result is a growing web of autonomous AI agents that each hold broad privileges, operate without oversight, and can be difficult to locate when something goes wrong.
This uncontrolled proliferation is what security teams call agent sprawl. Each instance of the Claude SDK becomes a moving target: the credential it carries may be copied, the process may be duplicated, and the network path it uses bypasses any central policy enforcement. When a breach or misconfiguration occurs, investigators have no single point of view, no audit trail, and no way to stop a rogue command before it reaches the target system.
At its core, agent sprawl is a problem of missing runtime governance. The SDK itself is capable of authenticating to a database, an SSH host, or an HTTP endpoint, but the authentication is typically performed with a static secret that is baked into the container image or injected via an environment variable. The identity that the agent presents is therefore a non‑human, service‑level identity that is granted standing access. While the identity may be scoped to a particular role, the enforcement of that scope happens only at the point where the secret is validated – inside the target system. The gateway that the SDK talks to directly is the only place where policy could be applied, yet in most deployments there is none.
Why the existing setup leaves the door open
Even when you adopt best‑practice IAM policies – least‑privilege roles, short‑lived tokens, and role‑based groups – the Claude Agent SDK still initiates a direct network connection to the resource. The request travels straight from the container to the database or SSH host, carrying the credential unchanged. Because the gateway is absent, the following gaps remain:
- No real‑time audit of which command was issued, by which agent, and when.
- No inline data masking, so sensitive fields in query results can be exfiltrated by a compromised agent.
- No just‑in‑time approval workflow; a dangerous operation can execute immediately.
- No session recording, making post‑mortem analysis labor‑intensive.
These gaps exist despite a solid identity foundation. The missing piece is a Layer 7 proxy that sits on the data path and enforces policy before the request reaches the target.
How hoop.dev provides the missing control plane
Enter hoop.dev. It is a Layer 7 gateway that runs as a network‑resident agent and proxies every connection that the Claude SDK attempts. By configuring the SDK to point at the hoop.dev endpoint instead of the raw database host, all traffic is forced through the gateway. This design makes hoop.dev the only place where enforcement can happen, satisfying the architectural requirement for runtime governance.
Because hoop.dev sits in the data path, it can apply a suite of controls that directly address agent sprawl:
- Session recording. hoop.dev records each interaction, preserving the exact command, response, and identity of the invoking agent. The recordings are stored outside the agent’s process, giving auditors a reliable replay source.
- Inline data masking. Sensitive columns – such as credit‑card numbers or personal identifiers – are masked in real time before they leave the gateway, preventing a compromised agent from seeing raw values.
- Just‑in‑time approval. When a command matches a risky pattern (for example, a DROP DATABASE statement), hoop.dev routes the request to an approver for manual consent, blocking execution until approval is granted.
- Command‑level audit. Every SQL statement, SSH command, or HTTP request is logged with the agent’s identity, enabling precise accountability.
- Credential isolation. The gateway holds the target credentials; the Claude SDK never sees them, eliminating secret leakage from the container.
All of these outcomes are possible only because hoop.dev is the gateway that inspects traffic at the protocol layer. If the gateway were removed, the Claude SDK would resume direct connections with no audit, no masking, and no approval – the very gaps we set out to close.
Deploying hoop.dev is straightforward. The quick‑start guide walks you through a Docker‑Compose deployment that includes OIDC authentication, masking policies, and guardrails out of the box. Once the gateway is running, you register the target resource (for example, a PostgreSQL instance) and grant the Claude SDK a scoped identity that can request access through hoop.dev. The SDK then authenticates to hoop.dev with an OIDC token, and hoop.dev validates the token, checks group membership, and enforces the policies defined for that resource.