Are you comfortable letting a CI job launch a chain of agents that can reach any service in your environment? In many pipelines the build runner authenticates once, then spawns a secondary process that talks to a database, another that talks to a Kubernetes cluster, and perhaps a third that invokes an internal HTTP API. Each step inherits the original credential and runs with the same privileges. The result is a single credential that can travel across multiple layers, making the effective blast radius of a single compromised CI token far larger than the token’s original scope.
This practice is common because teams prioritize speed. A developer pushes code, the CI system pulls a secret from a vault, and the job proceeds without additional approvals. The secret is cached in the runner’s memory, then handed off to child processes that act as “nested agents.” Those agents are not independent identities; they are extensions of the original CI identity. If an attacker compromises the runner, they instantly gain the ability to issue commands against every downstream service the pipeline touches, from the production database to the internal monitoring dashboard.
How nested agents expand the blast radius
The core problem is that the access control decision happens only at the initial authentication step. The CI system verifies the token, then hands the credential to the first agent. From that point onward there is no additional enforcement point. The credential flows unchecked through the chain, so any vulnerability in one stage – a mis‑configured script, a leaked environment variable, or a compromised container image – can be leveraged to reach the next target. The blast radius therefore grows with each nested agent, turning a single compromised CI token into a multi‑service compromise.
Even when organizations adopt least‑privilege policies for the initial CI token, the token often needs broad permissions to complete the build, test, and deploy phases. Those permissions are granted once, and the nested agents automatically inherit them. The pipeline therefore lacks fine‑grained, per‑operation checks, and there is no immutable audit trail that records which command was sent to which service at what time.
Why the current setup is insufficient
The usual mitigation is to tighten the initial token scope and to rotate secrets frequently. That addresses the identity layer – the setup – by ensuring only the right users can start a pipeline and that the token expires quickly. However, the setup alone does not stop a compromised runner from using the token to issue arbitrary commands on downstream services. The request still reaches each target directly, without a central point that can approve, mask, or systematically capture audit data for every operation. In other words, the pipeline still lacks a dedicated data‑path enforcement point where policies can be applied consistently across every nested agent.
What is missing is a gateway that sits between every agent and the resource it talks to, capable of inspecting the protocol, enforcing just‑in‑time approvals, masking sensitive fields, and recording the full session. Without that gateway, the blast radius remains uncontrolled, and any post‑mortem will have to rely on scattered logs that may not capture the full command sequence.
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, Kubernetes clusters, SSH hosts, and internal HTTP services. When a CI runner initiates a connection, hoop.dev authenticates the user via OIDC or SAML, then routes the traffic through its agent that lives inside the same network as the target resource. Because the gateway sits on the data path, it can enforce policies on every request that passes through, regardless of how many nested agents are involved.
hoop.dev records each session, so auditors can replay the exact sequence of commands that a pipeline executed. It can mask sensitive response fields in real time, preventing secrets from leaking into logs. It also supports just‑in‑time approvals, allowing a human to review a high‑risk command before it reaches the target service. Most importantly, because the enforcement happens at the gateway, the blast radius is limited to the scope defined in hoop.dev’s policies, not the original CI token’s broad permissions.
In practice, the CI pipeline is configured to talk to the gateway instead of directly contacting the database or Kubernetes API. The gateway holds the credential for the downstream service, so the pipeline never sees the secret. Each nested agent still runs, but every request they generate must pass through hoop.dev, where the policy engine can block, approve, or mask the operation. The result is a containment zone that reduces the effective blast radius of a compromised CI runner from “all services” to “only the services explicitly permitted by the gateway policy.”
Practical steps to reduce blast radius with hoop.dev
- Deploy hoop.dev as a network‑resident gateway in the same VPC or subnet as your critical services.
- Configure your CI runners to authenticate via OIDC/SAML and to connect only through the gateway.
- Define per‑service policies that require just‑in‑time approval for destructive commands, such as DROP DATABASE or kubectl delete.
- Enable session recording and real‑time masking for any responses that contain credentials or personal data.
- Review the recorded sessions regularly to verify that no unexpected commands were executed.
All of these controls are described in detail in the getting‑started guide and the broader learn section. The open‑source repository on GitHub contains the full deployment manifests and example policies.
FAQ
Does hoop.dev eliminate the need for secret rotation?
No. Secret rotation remains a best practice for the underlying services. hoop.dev complements rotation by ensuring that any use of a secret is recorded and can be approved in real time.
Can hoop.dev block a command that has already been sent by a nested agent?
Yes. Because hoop.dev sits on the data path, it can inspect the command before it reaches the target and reject it if the policy requires approval or if the command is deemed unsafe.
hoop.dev is designed to operate at wire‑protocol level with minimal latency. Real‑world deployments report only a modest overhead that is outweighed by the security benefits of reduced blast radius and full auditability.
Ready to tighten the blast radius of your CI pipelines? Explore the hoop.dev repository on GitHub and start building a data‑path defense that contains nested agents before they can cause widespread damage.
