An offboarded contractor still has a personal SSH key stored in the shared vault, and a nightly CI job continues to push database schema changes using a hard‑coded service account. Access reviews are meant to catch such drift, but they often miss tool‑driven credentials because the review process looks at user accounts, not at the secrets embedded in scripts or automation pipelines. The security team receives an alert that a sensitive table was altered, but the logs show only the service account name, not the individual who triggered the change.
These kinds of incidents highlight the disconnect between the tools engineers use daily and the organization’s access‑review processes. When a tool, whether a CLI, a CI pipeline, or an interactive shell, carries a credential, the credential often outlives the person or purpose that created it.
Access reviews are supposed to answer the question, “Does this identity still need this permission?” In practice, reviews are performed on user accounts, groups, or roles, while the credentials embedded in tools remain invisible to the review workflow. The result is a blind spot where privileged access can be exercised without ever appearing on a reviewer’s checklist.
Why access reviews matter for tool use
Tool‑driven access bypasses the human‑in‑the‑loop step that most review programs rely on. A developer may invoke kubectl or psql from a laptop that stores a long‑lived token. A build server may run aws commands with an IAM key that never rotates. When an access‑review cycle runs, the auditor sees a role assignment but has no visibility into which automated process is actually exercising that role. Without that visibility, reviewers cannot make an informed decision about whether the permission should be retained.
Current practice leaves gaps
The typical starting state looks like this:
- Shared passwords or static API keys are checked into code repositories or stored in a central vault that many teams can read.
- Service accounts are granted broad, standing privileges that match the maximum need of any downstream job.
- Connections to databases, Kubernetes clusters, or SSH hosts are made directly from the client, bypassing any central enforcement point.
- Audit logs are either absent or limited to the target system, which records only the service account name, not the originating identity or intent.
These conditions satisfy the minimal requirement for an identity to start a request (the Setup layer), but they provide no place where policy can be applied. The request reaches the target directly, leaving the organization without real‑time approval, masking, or command‑level audit.
A gateway‑centric approach
Putting a Layer 7 gateway in the data path creates the only point where enforcement can happen. hoop.dev proxies connections to databases, Kubernetes clusters, SSH hosts, and HTTP services. Because every request flows through the gateway, hoop.dev can apply the controls that access‑review programs need.