Many teams assume that a service account is just another user and that reviewing its permissions is no different from reviewing a human login. The reality is that non‑human identities behave like permanent keys: engineers rarely rotate them, they share them across scripts, and they often evade the regular access‑review cycle. These gaps undermine access reviews, which depend on accurate, timely data about who used which credential.
When a service account is created, engineers typically embed its secret in configuration files or CI pipelines. The credential sits for months, sometimes years, while the code that uses it changes dozens of times. No one looks at who actually invoked the account, what commands were run, or whether the secret was ever revoked. The result is a blind spot in the audit trail and a high‑risk vector for lateral movement.
Even when an organization enforces a policy that every non‑human identity must be provisioned through a central IAM system, the request still travels directly to the target database, Kubernetes node, or SSH host. The gateway that could enforce policy sits outside the request, but the request bypasses it. At that point the system can see that a connection was made, but it cannot enforce just‑in‑time approval, mask sensitive fields, or record the session for later review. Access reviews therefore lack the granularity needed to answer questions like “who ran this destructive command?” or “did this query expose PII?”.
Why access reviews matter for non‑human identities
Access reviews aim to ensure that every principal has only the permissions it needs at any given time. For a human user, reviewers can tie changes to role updates, onboarding, or offboarding events. For a service account, engineers often decouple the lifecycle from any human action, allowing the account to accumulate privileges long after its original purpose has faded. Without a mechanism that can intercept and log each request, reviewers must rely on static credential inventories that quickly become outdated.
In practice this gap shows up in three ways:
- Stale permissions: A script that once needed read‑only access may later be used for migrations, but the credential still carries only read‑only scopes, causing failures or, conversely, unchecked writes if engineers broaden the scope without a review.
- Untracked activity: When a CI job runs a database migration, the audit log often records only the service account name, not the specific SQL statements executed. This makes forensic analysis painful.
- Credential sprawl: Secrets appear in multiple repos, Docker images, and environment variables, creating duplicate attack surfaces that reviewers cannot see.
Addressing these issues requires a control point that sits on the data path – the exact place where the request reaches the target resource.
hoop.dev as the data‑path enforcement layer
Enter hoop.dev. It is a Layer 7 gateway that proxies connections to on‑prem resources such as databases, Kubernetes clusters, SSH hosts, and internal HTTP services. By placing hoop.dev between the identity provider and the target, every request passes through a single enforcement point.
In the setup phase, the system federates identities – including service accounts – via OIDC or SAML. The gateway validates the token, extracts group membership, and decides whether the principal may start a session. This step decides *who* the request is, but it does not enforce any policy on its own.