When service accounts and automation tokens linger unchecked, they become hidden doors that inflate the cost of access reviews and open the door to privilege creep.
Traditional access review processes are built around human users: managers, engineers, contractors. The same rigor rarely extends to the identities that power CI/CD pipelines, background jobs, or automated bots. Those non‑human identities often carry long‑lived secrets, are granted broad permissions, and operate without the same visibility that a human login generates.
Because they are not tied to a person’s lifecycle, service accounts can survive the departure of the team that created them, outlive the code that needs them, and accumulate permissions through incremental grants. When auditors ask for evidence, the answer is frequently “we don’t have a record of which pipeline used which credential.” The result is a noisy, manual effort to hunt down stale tokens, or worse, a false sense of compliance.
What to watch for in non‑human identities
Effective access reviews start with a clear inventory and a set of guardrails that keep automation in line with the principle of least privilege. Key signals to monitor include:
- Static secrets stored in code repositories or configuration files.
- Service accounts that have not been rotated in the past 90 days.
- Permissions that exceed the exact API calls required by a pipeline stage.
- Orphaned accounts that are no longer referenced by any CI/CD job.
- Cross‑environment credentials that are reused between development, staging, and production.
Each of these items creates blind spots for access reviewers. Without a single point that can observe every request, you cannot reliably answer whether a given service identity accessed a database, a Kubernetes cluster, or an internal HTTP API during a specific deployment.
Why a data‑path gateway is required
The missing piece is a control surface that sits on the actual traffic flow between the automation and the target resource. Identity verification (OIDC or SAML) tells the system who is making the request, but it does not enforce what the request can do, nor does it record the exact commands that were issued. To turn a vague inventory into actionable evidence, the enforcement must happen where the data moves.
That enforcement point is a Layer 7 gateway that proxies every connection. By placing the gateway in the data path, you gain the ability to:
- Validate each request against up‑to‑date policies.
- Require just‑in‑time approval for risky operations.
- Mask sensitive fields in responses before they reach logs or downstream tools.
- Record a complete session that can be replayed during an audit.
Introducing hoop.dev as the enforcement layer
hoop.dev fulfills exactly this role. It runs a network‑resident agent that fronts databases, Kubernetes clusters, SSH endpoints, and internal HTTP services. When a CI/CD job initiates a connection, the request passes through hoop.dev, which inspects the wire‑protocol, applies policy checks, and logs the interaction.
Because hoop.dev is the active gatekeeper, it can produce the evidence needed for reliable access reviews. Every session is tied to the non‑human identity that presented the OIDC token, and the logs show which commands were executed, which data fields were masked, and whether any approval step was required. This granular audit trail eliminates the guesswork that typically plagues service‑account reviews.
How hoop.dev improves access reviews
With hoop.dev in place, access reviewers gain three concrete advantages:
- Visibility. Each service account’s activity is recorded in a searchable log, making it easy to spot unused credentials or unexpected access patterns.
- Control. Policies can enforce least‑privilege scopes on a per‑request basis, automatically revoking excess permissions without changing the underlying service account.
- Evidence. The recorded sessions provide evidence that can be presented to auditors, reducing the effort required to demonstrate compliance with internal or regulatory access‑review mandates.
Because the gateway sits between the CI/CD pipeline and the target, it does not require any code changes in the pipeline itself. Engineers continue to use their familiar tools (kubectl, psql, ssh), while hoop.dev silently enforces the policies that keep access reviews accurate.
Getting started
To add this capability to your environment, follow the getting‑started guide and review the feature documentation for details on policy configuration, session recording, and inline masking. The project is open source and hosted on GitHub, where you can explore the code, raise issues, or contribute enhancements.
Explore hoop.dev on GitHub
FAQ
What counts as a non‑human identity?
A non‑human identity is any credential used by automation rather than a person, service accounts, CI/CD tokens, bot users, or machine‑to‑machine certificates.
How does hoop.dev tie activity back to a specific pipeline?
Each request presents an OIDC token that includes the service account’s name and the groups it belongs to. hoop.dev logs that token alongside the captured session, so reviewers can filter activity by pipeline name or job ID.
Do I need to modify my CI/CD scripts?
No. hoop.dev works as a transparent proxy. Your scripts continue to invoke the same CLI tools; the only change is the network endpoint they point to (the hoop.dev gateway).
