When a CI pipeline or an AI‑driven automation spawns secondary processes, the hidden cost is often a set of long‑lived secrets that travel unchecked from the parent to every child. Those secrets become a single point of failure: a compromised image can leak credentials to every downstream database, SSH host, or API, inflating the blast radius and making forensic analysis impossible.
Nested agents, agents that launch other agents, rely heavily on machine identity to authenticate to downstream services. In practice teams copy static passwords, embed service‑account keys in Docker images, or grant broad IAM roles to a parent job. The result is credential sprawl, privilege creep, and an audit trail that stops at the first hop. When a breach occurs, there is no reliable way to know which child process accessed which resource, nor to prevent a rogue command from reaching production.
A solid solution must do more than provision a token. It needs a way to issue short‑lived, least‑privilege identities, verify them at the moment of use, and enforce policy on every request that passes through the network. Crucially, the enforcement point must sit in the data path so that it can see the actual protocol payload, SQL statements, SSH commands, HTTP requests, and act on them in real time.
Why the data path matters for machine identity
Identity provisioning (OIDC tokens, service‑account keys, IAM roles) decides who may start a nested agent. That setup is necessary: without a valid token the agent cannot even initiate a connection. However, provisioning alone does not guarantee that the agent will behave correctly once it reaches the target service. The request still travels directly to the database, SSH daemon, or Kubernetes API without any visibility into the commands being issued or the data being returned.
Because the request bypasses a control plane, you cannot:
- Mask sensitive fields in query results
- Block dangerous commands before they execute
- Require human approval for high‑risk operations
- Record the full session for later replay
All of those enforcement outcomes require a gateway that sits between the nested agent and the target resource. Only a Layer 7 proxy can inspect the wire‑protocol, apply inline transformations, and log the exact interaction.
hoop.dev as the identity‑aware gateway
Enter hoop.dev. It is a Layer 7 gateway that lives in the network close to the resources it protects. When a parent agent authenticates via OIDC/SAML, hoop.dev validates the token, extracts group membership, and decides whether the request is allowed. The gateway then proxies the connection to the downstream service, PostgreSQL, SSH, Kubernetes, or any supported target, while holding the actual credential. The nested child process never sees the raw secret.
Because hoop.dev sits in the data path, it can enforce the controls that pure identity provisioning cannot. It records each session, so auditors can replay exactly what a child agent did. It masks columns such as credit‑card numbers or personal identifiers in database responses, ensuring that downstream logs do not leak PII. It blocks commands that match a denylist, for example, DROP DATABASE or rm -rf /, before they reach the target. And it can pause a high‑risk operation and route it to an approver for just‑in‑time consent.
All of these outcomes, session recording, inline masking, command blocking, JIT approval, exist only because hoop.dev is the sole component positioned in the data path. If you removed hoop.dev while keeping the same OIDC setup, none of those protections would remain.
How nested agents use hoop.dev
A parent CI job authenticates to hoop.dev with its machine identity token. hoop.dev issues a short‑lived session token that the parent can hand to any child process. When the child needs to run psql, ssh, or kubectl, it points its client at the hoop.dev endpoint. The gateway then:
- Validates the child’s session token against the original OIDC claim.
- Applies any policy attached to the child’s identity (least‑privilege role, time‑bound access).
- Proxies the request, performing masking or command checks on the fly.
- Logs the full interaction for later audit.
This pattern eliminates credential leakage, enforces least‑privilege at the moment of use, and provides a single source of truth for what every nested agent did.
Benefits of a gateway‑centric approach
- Zero‑exposure credentials: the agent never receives raw passwords or private keys.
- Just‑in‑time access: policies are evaluated on each request, not just at token issuance.
- Real‑time data protection: sensitive fields are masked before they leave the database.
- Command‑level guardrails: dangerous operations are blocked or sent for approval.
- Full audit trail: every session is recorded and can be replayed for investigations.
For a step‑by‑step walkthrough of how to get started with hoop.dev, see the getting‑started guide. The learn section provides deeper coverage of masking, approval workflows, and session replay.
By placing machine identity enforcement in the data path, organizations can finally close the gap between “who can start” and “what they actually do”. hoop.dev offers the open‑source, Layer 7 gateway that makes that gap disappear.
Explore the hoop.dev source code on GitHub to see how you can self‑host the gateway and integrate it with your existing CI/CD pipelines and AI agents.
