Zero Trust for Tool-Using Agents

Many assume that a tool‑using agent can be trusted simply because it runs inside the corporate network, but zero trust tells us that location alone is insufficient.

Tool‑using agents include CI runners, automated scripts, AI‑driven assistants, and any non‑human process that talks to databases, SSH servers, or internal APIs. They are granted credentials so they can perform deployments, run migrations, collect metrics, or answer user queries. When those agents are compromised or mis‑configured, they become a direct conduit for credential theft, lateral movement, and data exfiltration. The danger is amplified because agents often run with broad permissions that were granted for convenience rather than strict need.

Zero trust considerations for tool‑using agents

Zero trust demands that every request be verified, that access be limited to the minimum required, and that activity be continuously monitored. For agents this translates into three practical requirements:

• Identity that reflects intent. Each agent should present a non‑human identity (a service account, OIDC token, or SAML assertion) that is tied to a specific job function.
• Just‑in‑time, least‑privilege permissions. Permissions must be scoped to the exact resources and commands the agent needs, and they should be granted only for the duration of the task.
• Full visibility and enforcement. Every command, query, and response must be observable, and risky actions must be blocked or routed for approval before execution.

Organizations can meet the first two items by configuring OIDC providers, defining fine‑grained roles, and limiting token lifetimes. However, without a control point on the data path the request still travels directly to the target system. That direct path leaves three gaps:

• No audit of what the agent actually did once the connection is open.
• No ability to mask sensitive fields in query results.
• No mechanism to pause or reject a dangerous command before it reaches the backend.

These gaps persist even when the setup stage has correctly identified the agent and limited its token. The missing piece is a gateway that sits between the identity verification step and the target resource.

hoop.dev as the data‑path enforcement layer

hoop.dev provides exactly that layer. It is a Layer 7 gateway that proxies connections to databases, SSH servers, Kubernetes clusters, and internal HTTP services. The gateway validates the agent’s OIDC or SAML token, maps group membership to the permissions defined in the setup stage, and then forwards the traffic to the target.

Because the traffic passes through hoop.dev, the gateway can enforce zero‑trust policies in real time. Specifically, hoop.dev records each session for replay, masks sensitive data in responses, blocks commands that violate policy, and can trigger a human approval workflow for high‑risk actions. All of these outcomes exist only because hoop.dev sits in the data path; without it, the agent would communicate directly with the backend and none of these controls would be possible.

Enforcement outcomes you get from hoop.dev

• hoop.dev records every command and response, providing a reliable audit trail.
• hoop.dev masks fields such as credit‑card numbers or personal identifiers before they reach the caller.
• hoop.dev blocks destructive commands like DROP DATABASE unless an approved exception is supplied.
• hoop.dev routes risky queries to an approval queue, allowing a security analyst to intervene before execution.
• hoop.dev makes session replay available for incident investigations.

These capabilities give security teams the visibility and control required by a zero‑trust model while still allowing agents to operate autonomously.

How the pieces fit together

The setup phase decides who the request is. You configure an OIDC provider, create a service account for the CI runner, and assign it a role that only allows read‑only access to a specific database schema. This step is necessary but not sufficient; it does not enforce anything on the traffic itself.

The data path is where hoop.dev lives. By placing the gateway between the agent and the database, it becomes the only place where policy can be applied. All enforcement outcomes, audit, masking, command blocking, and approval, are produced by hoop.dev.

When an agent initiates a connection, hoop.dev validates the token, checks the requested operation against the policy, and either forwards the request, masks the response, or pauses for approval. The agent never sees the underlying credentials, and the organization retains a complete record of what was done.

Getting started

To try this approach, follow the getting started guide and review the feature documentation for details on configuring agents, defining policies, and enabling session recording. The open‑source code is available on the GitHub repository.

FAQ

Do I need to change my existing CI pipelines?

No. hoop.dev works with standard client tools (psql, kubectl, ssh) so pipelines can continue to use the same commands; the gateway intercepts the traffic transparently.

Can I enforce different policies for different agents?

Yes. Policies are tied to the identity presented by the agent, so you can grant read‑only access to one service account and full admin rights to another, each enforced by hoop.dev.

What happens if hoop.dev is unavailable?

Because hoop.dev is the only path that grants access, an unavailable gateway simply blocks traffic. This behavior aligns with zero‑trust expectations: no fallback to uncontrolled direct connections.