In a well‑governed environment, access reviews confirm that every automated service, CI job, or micro‑service is represented by a distinct identity, and each of those identities appears in review reports with clear ownership, expiration, and evidence of actual usage.
When reviews are run, reviewers can instantly see which non‑human identities have accessed which internal SaaS APIs, why they needed that access, and whether the permission set is still justified. Stale tokens are revoked automatically, privileged calls are logged with full context, and any sensitive fields returned to callers are masked before they reach the consuming system. The result is a concise, accurate review that satisfies auditors and reduces the time spent chasing ghost accounts.
Why access reviews need non‑human identity
Access reviews traditionally focus on human users because their credentials are obvious in directory services. Service accounts, API keys, and machine‑issued tokens are often created ad‑hoc, named ambiguously (e.g., "app_user"), and never retired. Reviewers end up with a long list of opaque entries that cannot be tied back to a team, a project, or a business justification.
This lack of clarity creates two major risks. First, unused or over‑privileged non‑human identities become a foothold for lateral movement. Second, during audits the evidence trail is incomplete; reviewers cannot prove that a particular service call was legitimate, leading to “cannot attest” findings.
Current reality without proper control
Many organizations still rely on shared static credentials stored in configuration files or secret managers that are accessed directly by applications. The setup looks like this:
- Developers embed a single database password in the code repository.
- CI pipelines reuse that password for every job, regardless of the job’s purpose.
- Service‑to‑service calls use long‑lived API keys that never rotate.
In this model, the request travels straight from the application to the target SaaS endpoint. No component records the request, masks returned data, or asks for a human approval when a risky operation is attempted. Access‑review processes therefore see only a flat list of credentials, with no visibility into who actually used them or what data was exchanged.
Introducing a non‑human identity model
Moving to a model where each automation piece authenticates with its own OIDC token or short‑lived service account improves identity clarity. The setup layer now defines who each token belongs to, what roles it can assume, and how it is provisioned via the identity provider.
However, even with this improvement the request still reaches the SaaS service directly. The gateway that could enforce policies, record sessions, or mask sensitive fields is missing. Without a data‑path enforcement point, the organization still lacks the evidence needed for thorough access reviews.
Putting the gateway in the data path
hoop.dev acts as a Layer 7 identity‑aware proxy that sits between the non‑human identity and the internal SaaS endpoint. Because hoop.dev is the only place the traffic passes through, it can enforce the controls that access reviews require.
- hoop.dev records every session, capturing who initiated the request, what command or API call was made, and the full response.
- hoop.dev masks sensitive fields in real time, ensuring that downstream logs never contain raw secrets.
- hoop.dev can require just‑in‑time approval for high‑risk operations, inserting a human decision point before the action is executed.
- hoop.dev never exposes the underlying service credentials to the caller, keeping the secret confined to the gateway.
Because these outcomes are produced by hoop.dev in the data path, they become part of the audit trail that reviewers examine. When an access‑review cycle runs, the generated logs show exactly which non‑human identity performed which action, when it happened, and whether any masking was applied.
To get started, follow the getting started guide and explore the learn section for deeper details on policy configuration.
FAQ
- Do I need to change my existing service accounts? You can gradually migrate by assigning each existing account a short‑lived token that hoop.dev validates. The gateway will handle the transition without downtime.
- Will hoop.dev add latency to my API calls? The proxy operates at the protocol layer and adds only the minimal processing needed for logging, masking, and approval checks, which is typically negligible compared to network latency.
- How does this help with compliance audits? The session records and approval logs generated by hoop.dev provide concrete evidence for auditors, reducing “cannot attest” findings in access‑review reports.
Explore the source code and contribute on GitHub.
