When tool‑using agents operate under a clear, auditable policy, they never expose hidden data or make unauthorized calls, and every decision is traceable.
In reality, many automation scripts, CI/CD runners, and AI‑assisted assistants run with static secrets that grant them broad read and write rights. The agents are written once, deployed everywhere, and then left to act on whatever they encounter. Over time they evolve into what the security community calls shadow ai: hidden decision‑making that bypasses human intent, leaks sensitive fields, and leaves no evidence of who triggered a change.
This lack of visibility is especially dangerous when the agent interacts with databases, Kubernetes clusters, or remote shells. A single misplaced credential can let the agent enumerate tables, delete pods, or open reverse shells without any approval workflow. Because the request travels directly from the agent to the target, there is no place to inspect the payload, enforce least‑privilege checks, or mask confidential columns.
Why the current setup still falls short
Even if you adopt strong identity providers, enforce role‑based access control, and rotate secrets regularly, the enforcement point remains at the identity layer. The setup, OIDC tokens, service accounts, IAM roles, decides who may start a connection, but it does not inspect what the connection actually does once it reaches the resource. The request still reaches the database or the Kubernetes API directly, meaning there is no audit trail of the commands issued, no inline masking of sensitive response fields, and no just‑in‑time approval for risky operations.
In this state, the shadow ai problem persists because the enforcement outcomes, command‑level audit, real‑time data masking, session recording, are simply not possible. Without a dedicated control surface in the data path, you cannot guarantee that every query, pod exec, or SSH command complies with policy.
Placing enforcement in the data path with hoop.dev
hoop.dev is a Layer 7 gateway that sits between the agent and the target infrastructure. By routing every connection through hoop.dev, the gateway becomes the only place where enforcement can happen. It inspects the wire‑protocol, applies policy checks, and records the interaction before the request ever reaches the backend service.
Because hoop.dev is the active component in the data path, it can:
- Record each session, retaining an audit trail that can be replayed through the UI or exported for external analysis.
- Mask sensitive fields in database responses, preventing accidental exposure of credentials or personal data.
- Block dangerous commands, such as DROP DATABASE or privileged pod exec, before they are executed.
- Require just‑in‑time human approval for high‑risk actions, ensuring that no privileged operation proceeds without oversight.
- Enforce per‑user, per‑session policies that are derived from the identity token verified at setup time.
All of these enforcement outcomes exist only because hoop.dev sits in the data path. If you removed hoop.dev, the same identity setup would still allow the agent to act unchecked, proving that the gateway is the essential control surface.
How the architecture addresses shadow ai
When a tool‑using agent initiates a connection, it first presents an OIDC token to hoop.dev. The gateway validates the token, extracts group membership, and maps it to a policy that defines which commands are allowed, which fields must be masked, and which actions require approval. The agent never sees the underlying credentials stored by hoop.dev, eliminating credential sprawl.
During the session, every request passes through hoop.dev’s inspection engine. If the request matches a policy that requires masking, the gateway rewrites the response on the fly, ensuring that downstream systems never see raw sensitive data. If the request attempts a prohibited operation, hoop.dev blocks it and logs the attempt. For actions that cross a risk threshold, the gateway triggers an approval workflow; the request stalls until an authorized reviewer grants permission.
Because the gateway records the full transcript, auditors can later verify that the agent behaved exactly as policy dictated. This evidence satisfies compliance programs that demand per‑user logs, even though the underlying system (the database, Kubernetes, or SSH server) does not provide such granularity on its own.
Getting started
Deploying hoop.dev is straightforward: a Docker Compose file can spin up the gateway and a network‑resident agent in minutes. The official getting‑started guide walks you through configuring OIDC authentication, registering a target, and defining a basic policy. For deeper dives into masking, approval workflows, and session replay, explore the learn section of the documentation.
FAQ
What is the difference between a static secret and hoop.dev’s credential handling? With a static secret, the agent stores and reuses the credential, exposing it to compromise. hoop.dev stores the credential centrally and injects it only for the duration of an authorized session, so the agent never sees the raw secret.
Can hoop.dev block a command without stopping the entire session? Yes. The gateway can selectively reject individual commands, such as a DROP TABLE, while allowing the rest of the session to continue, preserving workflow continuity.
Is there a way to review past sessions? hoop.dev records each session, retaining an audit trail that can be replayed through the UI or exported for external analysis, providing a complete audit record.
For the full source code and contribution guidelines, visit the GitHub repository.
