Are your CI/CD pipelines silently widening your blast radius?
Most teams grant service accounts, build bots, and automation tokens full‑admin rights to speed up deployments. Those identities are created once, stored in secret managers, and then handed to every pipeline job without further scrutiny. The result is a single credential that can read production databases, push container images, or spin up cloud resources, all without a human ever looking at the request.
This approach satisfies the immediate need to get code from commit to production, but it creates a massive attack surface. If a malicious actor compromises a runner, they inherit every permission the non‑human identity carries. Because the credential lives outside any interactive session, there is no audit trail that shows who, or what, issued a destructive command. No inline data masking protects sensitive fields that might be streamed back to logs. And there is no point‑in‑time approval step that could stop a rogue deployment before it touches live services.
What organizations typically try to fix is the over‑privileged nature of these identities. Teams start by scoping the service account to a narrower set of namespaces or by rotating keys more frequently. While that reduces the raw permissions, the request still travels directly to the target system. The gateway that could enforce additional checks, such as command‑level approval, real‑time masking of secrets, or session recording, remains absent. In other words, the precondition of “least‑privilege non‑human identity” is met, but the enforcement layer that would actually limit blast radius is missing.
Reducing blast radius with non‑human identity controls
To truly contain the impact of a compromised automation token, the enforcement point must sit on the data path between the CI/CD runner and the infrastructure it talks to. That is where a Layer 7 gateway can intervene. By proxying every database query, Kubernetes exec, or SSH command, the gateway becomes the only place where policy can be applied.
hoop.dev records each session so that auditors can replay exactly what a pipeline did, down to the individual command. hoop.dev masks sensitive fields in responses, preventing secrets from leaking into log aggregation services. hoop.dev blocks dangerous commands before they reach the target, stopping destructive actions like dropping a database unless an explicit approval is granted. hoop.dev routes risky operations to a human approver, turning a blind automated step into an intent‑based workflow that requires a signed‑off decision.
All of these outcomes are possible only because the gateway sits in the data path. The identity system that issues the token, whether OIDC, SAML, or a static service account, decides who may start a request, but it does not enforce what the request can do. By placing hoop.dev between the runner and the target, you gain a single, auditable control surface that applies the same policies to every type of connection: PostgreSQL, MySQL, Kubernetes, SSH, or HTTP APIs.
Why the data path matters
When a pipeline runs a psql command, the client talks directly to the database server. If the service account is over‑privileged, the database sees the request as coming from a trusted identity and executes it without question. By routing that traffic through hoop.dev, the request is first inspected. The gateway can verify that the command matches a pre‑approved pattern, redact any column that contains a credit‑card number, and write a detailed audit entry before the database even sees the query.
The same principle applies to Kubernetes exec calls. A CI job that runs a kubectl exec to restart a pod would normally have cluster‑admin rights. With hoop.dev in place, the exec request is evaluated against a policy that permits only read‑only operations unless a manual approval is recorded. If the policy blocks the command, the pipeline fails fast, preventing a potential cascade of failures across the cluster.
Implementing the control surface
Start by deploying the gateway in a network segment that can reach all of your infrastructure targets. The official getting‑started guide walks you through a Docker‑Compose or Kubernetes deployment. Once the gateway is running, register each resource, your databases, Kubernetes clusters, and SSH hosts, as a connection in the system. The gateway stores the credentials, so the CI/CD runner never sees them.
For deeper guidance on policy authoring and masking, see the learn section.
Next, define policies that reflect the principle of least privilege for non‑human identities. For example, allow a build bot to read from a staging database but require an approval step for any write to production. Configure inline masking rules for columns that hold passwords or API keys. Finally, enable session recording so that every pipeline execution can be replayed during a post‑mortem.
FAQ
- Do I need to change my existing CI/CD scripts? No. The gateway works with standard clients such as psql, kubectl, and ssh, so pipelines continue to use the same commands.
- Can I still use existing service accounts? Yes. The gateway holds the credentials, and the service account token is presented to the gateway instead of the target.
- How does this help with compliance? hoop.dev generates evidence for audit programs by capturing per‑user logs, approvals, and masked data, which can be used to satisfy standards that require traceability of automated actions.
By moving the enforcement point to the data path, you turn a sprawling set of over‑privileged service accounts into a tightly controlled surface that limits blast radius, even when a non‑human identity is compromised.
Explore the open‑source repository on GitHub to get started.
