When every service account, CI token, and machine identity is regularly examined, you know exactly which workloads have access, for how long, and whether any privilege is excessive. In that ideal world, access reviews for non‑human identities become a predictable, low‑friction part of the security lifecycle rather than a surprise audit that uncovers hidden keys.
Achieving that state is difficult because non‑human identities are not tied to a person who can be asked to confirm a need. They are created by automation, stored in configuration files, and often granted broad permissions that outlive the original use case. Without a systematic review process, credentials linger, permissions creep, and the attack surface expands unnoticed.
How teams actually manage service accounts today
Most organizations start with a simple approach: a developer checks a service account key into a repository, a CI pipeline references a static token, or an operations script embeds a long‑lived password. The credential is then used directly against the target resource, be it a database, a Kubernetes cluster, or an SSH host. Because the gateway sits nowhere in that flow, there is no place to enforce policy, no audit trail that shows which job issued a command, and no way to mask sensitive response fields. The result is a “wild west” of machine identities where anyone who can read the repo can impersonate a service, and the security team has no visibility into what those identities actually do.
What a proper access review process must achieve
A thorough access review for non‑human identities must answer three questions for each credential: who created it, what resource it can reach, and whether the granted permissions are still required. The process also needs to enforce a few technical controls: the request to the target must pass through a point where the organization can inspect, approve, or block the operation; every interaction should be recorded for later forensic analysis; and any sensitive data returned by the target should be hidden from the caller unless explicitly allowed.
Even when these questions are answered on paper, the actual request still travels straight from the automation job to the target. Without a data‑path enforcement layer, the organization cannot guarantee that the reviewed policy is applied at runtime. The request bypasses any audit mechanism, any inline masking, and any just‑in‑time approval workflow. In other words, the review process fixes the “who‑should‑have‑access” question but leaves the enforcement gap wide open.
Embedding access reviews in the data path
Placing a Layer 7 gateway between identities and infrastructure closes that gap. hoop.dev acts as an identity‑aware proxy that sits on the network edge, receives the request, validates the caller’s OIDC or SAML token, and then forwards the traffic to the target only after applying policy.
Setup – defining who may ask for access
In the setup phase, organizations configure OIDC or SAML providers (such as Okta, Azure AD, or Google Workspace) so that each automation job receives a short‑lived token representing a non‑human identity. The token carries group membership that maps to a role in the organization’s policy store. This step decides who the request is and whether it may start, but it does not enforce any runtime constraints.