A common misconception is that simply authenticating an agent runtime is enough to guarantee zero trust. In reality, authentication is only the first step; without a controlled data path, an agent can still exfiltrate data, run unauthorized commands, or bypass policy entirely.
Most teams today launch agent processes with long‑lived credentials stored in config files or environment variables. The agent talks directly to the target service – a database, a Kubernetes API, or an SSH daemon – using those credentials. Because the connection is direct, the organization loses visibility into what the agent actually does. There is no central point to enforce command‑level policies, mask sensitive fields in responses, or require a human approval before a risky operation runs. Auditors see only the fact that a credential existed; they cannot prove which queries were executed or whether data was leaked.
Why the traditional model fails
Even when an identity provider issues short‑lived tokens, the token is handed to the agent and then used unchanged against the target. The token itself does not stop the agent from issuing any command the credential allows. Without a gateway, the following gaps remain:
- **No runtime audit** – every query or command passes unrecorded.
- **No inline data protection** – sensitive columns or files are returned in clear text.
- **No just‑in‑time approval** – high‑impact actions execute without a second set of eyes.
- **No revocation point** – revoking a token does not stop an already‑established TCP stream.
These gaps directly contradict the core tenets of zero trust, which demand continuous verification, least‑privilege enforcement, and full observability at the point of access.
Zero trust requirements for agent runtimes
To bring an agent runtime into a zero‑trust posture, three pillars must be satisfied:
- Identity‑driven admission: the runtime must present a verifiable identity token before any connection is allowed.
- Data‑path enforcement: every packet must traverse a control plane that can inspect, approve, or block operations in real time.
- Evidence collection: the system must record each request, response, and decision for replay and audit.
Only when all three are present can an organization claim true zero trust for its agents.
Putting the data path under control
The missing piece in most deployments is a dedicated gateway that sits between the agent and the target. This gateway becomes the sole place where policy is enforced. It does not replace identity providers; it consumes the identity token, validates it, and then decides whether the requested operation complies with policy. Because the gateway owns the network connection, it can:
- Block commands that match a deny list before they reach the backend.
- Require a human approver for actions flagged as high risk.
- Mask or redact sensitive fields in responses, ensuring that downstream logs never contain raw secrets.
- Record the full session, including timestamps, user, command, and outcome, so that replay is possible.
All of these enforcement outcomes exist only because the gateway sits in the data path.
How hoop.dev delivers zero trust
hoop.dev implements the exact architecture described above. It acts as an identity‑aware proxy for agent runtimes, handling OIDC or SAML tokens, then forwarding traffic to the target only after applying zero‑trust checks. Because hoop.dev is the only component that sees the clear‑text protocol, it can enforce command‑level policies, perform just‑in‑time approvals, and mask data on the fly. Each session is recorded and stored for replay, giving teams the evidence they need for audits.
Setup begins with defining non‑human identities – service accounts, OIDC client IDs, or SAML assertions – that represent each agent runtime. Those identities are scoped to the minimum set of resources the runtime needs. The gateway then validates each token, maps it to a policy, and decides whether to allow the connection.
When a request reaches the gateway, hoop.dev inspects the wire‑level payload. If the command matches a deny rule, hoop.dev blocks it immediately. If the operation is flagged as privileged, the request is routed to an approval workflow where an authorized engineer can approve or reject it. Responses that contain sensitive columns are masked according to policy before they are sent back to the agent. Throughout the entire exchange, hoop.dev records every step, creating a comprehensive audit trail.
Because hoop.dev runs as a network‑resident agent inside the customer’s environment, the credentials used to talk to the backend never leave the control plane. The agent runtime never sees the secret, satisfying the “never see the credential” promise of zero trust.
For a quick start, see the hoop.dev getting started guide. The learn section provides deeper explanations of masking, approval workflows, and session replay.
FAQ
Does hoop.dev replace my existing identity provider?
No. hoop.dev consumes tokens issued by your IdP and uses the identity information to drive its own policies. It does not act as an IdP.
Can I use hoop.dev with existing agent runtimes without code changes?
Yes. Agents continue to use their standard client libraries (psql, kubectl, ssh, etc.) and simply point to the hoop.dev endpoint. The gateway handles all inspection and enforcement.
What happens if an agent is compromised?
Even a compromised runtime can only act within the limits imposed by hoop.dev. Unauthorized commands are blocked, privileged actions require approval, and every action is recorded for forensic analysis.
Explore the source code on GitHub to see how the gateway is built and to contribute improvements.
