When a CI/CD pipeline silently spawns additional agents, the organization loses visibility into who actually touched production resources, and audit teams spend hours chasing phantom credentials. The hidden cost is not just wasted effort; it can translate into compliance gaps, unexpected data exposure, and a false sense of security. Because access reviews rely on a complete audit trail, the presence of hidden agents undermines their effectiveness.
Most pipelines start with a build runner that checks out code, then hand off to a deployment job. That job often creates a short‑lived container which, in turn, runs a third‑party tool that opens an SSH session to a database. Each hop introduces a new service identity, but the access‑review process typically looks only at the top‑level service account that started the pipeline.
Reviewers therefore see a single entry, "ci‑runner@company.com", and assume all downstream actions are covered by that one grant. In reality, the container may be using a different IAM role, and the SSH session may be authenticating with a static key that never appears in the original request. This mismatch makes it impossible to confirm that the principle of least privilege is being respected, and it creates blind spots for detecting lateral movement.
To close the gap, an organization needs a control point that sits on every request, captures the full chain of identities, and enforces policy before any command reaches the target system. The control must be able to record each session, require just‑in‑time approvals for risky operations, and mask secrets that appear in responses. Only with that level of visibility can an access‑reviewer trace a request from the initial CI trigger all the way to the final database query.
hoop.dev provides exactly that data‑path enforcement. It acts as a Layer 7 gateway that proxies connections from users, CI runners, and nested agents to the underlying infrastructure. Because every request passes through the gateway, hoop.dev can apply inline masking, block disallowed commands, and route suspicious actions to an approval workflow before they are executed.
When a nested agent attempts to connect, hoop.dev records the originating identity, the intermediate service account, and the final target. The audit trail therefore shows a complete picture: "ci‑runner" launched a container, the container’s agent authenticated as "deploy‑svc", and that agent opened an SSH session to "db‑prod". Reviewers can query the logs, replay the session, and see exactly which approvals were granted, even if the underlying credentials were never exposed to the human operator.
The surrounding setup, OIDC federation, least‑privilege service accounts, and role‑based provisioning, determines who may start a request, but it does not enforce any guardrails on its own. By placing hoop.dev in the data path, the organization adds the missing enforcement layer that turns identity information into actionable policy decisions.
Because hoop.dev owns the enforcement outcomes, it can guarantee that every session is recorded, that sensitive fields are masked in real time, that just‑in‑time approvals are required for privileged commands, and that any disallowed command is blocked before it reaches the target. These capabilities exist only because the gateway sits between the agent and the resource; without it, the same setup would leave the pipeline fully exposed.
For teams that need reliable access‑reviews, this architecture means they can answer three critical questions quickly: who initiated the pipeline, which downstream agents actually performed the actions, and whether each step was approved and logged. The resulting evidence is concise, audit‑ready, and suitable for auditors.
Getting started is straightforward. Follow the getting‑started guide to deploy the gateway, configure OIDC authentication, and register your CI/CD resources. The learn section provides deeper detail on session recording, inline masking, and approval workflows.
Why access reviews struggle with nested agents
Nested agents break the one‑to‑one mapping between a user identity and a resource interaction. When a pipeline launches a temporary container that runs its own agent, the original credential is no longer the one that touches the database. Access‑review tools that only look at the top‑level token miss the intermediate identities, leading to incomplete reports and potential over‑privilege.
How hoop.dev restores visibility
hoop.dev forces every hop to pass through the gateway, turning the invisible chain into an observable sequence. The gateway logs each hop, applies policy, and can require a human approver before a privileged command is executed. Because the gateway is the only place where enforcement occurs, reviewers can trust the recorded data.
FAQ
- Do I need to modify my CI scripts to use hoop.dev? The gateway works with standard clients (git, kubectl, psql, ssh). You point your scripts at the gateway endpoint instead of the raw target, and the rest is handled by the proxy.
- Can hoop.dev mask secrets that appear in command output? Yes, the gateway can redact configured fields in real time, ensuring that logs and replay sessions never expose credentials.
- What happens if a nested agent tries to bypass the gateway? Because the gateway holds the only credential for the target, any direct connection without the proxy will be rejected by the resource’s authentication layer.
Explore the source and contribute on GitHub.
