When every CI/CD job runs with exactly the permissions it needs, you can ship code fast without fearing accidental overreach. In that ideal state, a build step that pushes a container image can write to the registry, but it cannot list all buckets in the account, and a test runner that queries a database cannot drop tables it never touched. By enforcing least-privilege boundaries at each stage, the result is a clear audit trail, predictable blast radius, and confidence that a compromised pipeline cannot pivot to unrelated services.
In practice, many teams hand a single service account to the entire pipeline. The account often carries broad cloud-admin or database-admin rights because it is easier to grant once than to manage per-stage scopes. The CI runner then impersonates that account for every step, from linting to deployment. When a malicious actor or a buggy script gains access to the runner, it inherits all those privileges. The pipeline can read secret stores, delete resources, or exfiltrate data, all without any additional check.
Why least privilege still fails with agent impersonation
The root of the problem is that impersonation happens after the identity check. The pipeline authenticates once, receives a token that represents a high-privilege service account, and then reuses that token for every downstream connection. The setup, OIDC or SAML authentication, service-account provisioning, and role assignment, decides who the request is, but it does not enforce what each individual operation may do. The request still reaches the target directly, carrying the same wide-scope credential, and there is no audit of which command actually executed.
Because the enforcement point is missing, you cannot apply just-in-time approval for a risky database migration, you cannot mask sensitive columns returned by a query, and you cannot record the exact sequence of commands for later review. In short, the pipeline’s broad token defeats the intent of least privilege.
Putting the gateway in the data path
To restore true least-privilege guarantees, the enforcement must sit where the traffic flows. That is the role of a Layer 7 access gateway. By positioning the gateway between the CI runner and the target service, every request is inspected, authorized, and optionally recorded before it reaches the backend.
hoop.dev provides that data-path enforcement. It proxies connections to databases, Kubernetes clusters, SSH hosts, and HTTP services. When a CI job attempts to open a PostgreSQL session, the request first passes through hoop.dev. The gateway checks the user’s identity, consults policy, and decides whether the specific query is allowed. If the query matches a rule that requires approval, hoop.dev routes it to a human reviewer. If the query contains a column marked as sensitive, hoop.dev masks the value in the response before it reaches the pipeline. Every command and its result are stored as a replayable session.
How the three layers work together
- Setup: Identity providers (Okta, Azure AD, etc.) issue short-lived tokens to the CI runner. Service accounts are created with the minimum static permissions needed for the gateway itself, not for the individual jobs.
- The data path: hoop.dev sits in front of each target. It is the only place where policy enforcement can occur because the runner never contacts the backend directly.
- Enforcement outcomes: hoop.dev records each session, masks sensitive fields, blocks disallowed commands, and can trigger just-in-time approvals. Those outcomes exist solely because the gateway intercepts the traffic.
Practical steps for CI/CD pipelines
- Define fine-grained roles for each pipeline stage (build, test, deploy) in your identity provider.
- Configure the pipeline to request a token for the specific stage role instead of a single all-purpose service account.
- Register each target (PostgreSQL, Kubernetes, SSH) with hoop.dev and attach policies that map stage roles to allowed operations.
- Enable session recording and inline masking for any data that should never appear in logs.
- Set up approval workflows for high-risk actions, such as schema migrations or production deployments.
When the pipeline runs, the CI runner authenticates, receives a scoped token, and then talks to the target through hoop.dev. The gateway enforces the policy you defined, ensuring that the job never exceeds its intended permissions.
Getting started
Start by deploying the gateway with the official getting-started guide. The documentation walks you through registering a PostgreSQL connection, creating a policy that allows SELECT on read-only tables, and enabling session replay. For deeper policy examples and best-practice advice, explore the learn section of the site.
FAQ
Does hoop.dev replace my existing CI secret manager?
No. hoop.dev protects the connection after authentication. Your secret manager still stores the static credentials that the gateway uses to reach the backend.
Can I use hoop.dev with existing pipelines without code changes?
Yes. The pipeline continues to use the same client binaries (psql, kubectl, ssh). The only change is the endpoint, point it at the gateway instead of the raw host.
What happens if a job tries to run an unauthorized command?
hoop.dev blocks the command, logs the attempt, and optionally forwards it for human approval before execution.
Ready to see how a gateway can lock down your CI/CD pipelines? Explore the open-source repository on GitHub and start building a least-privilege pipeline today.
