A common misconception is that giving a service account permanent rights is harmless because the account never logs in interactively. In reality, standing access for non‑human identities is a silent privilege‑escalation vector that can be abused without any visible user action.
Most teams today create a bot or CI service account, generate a static password or key, and embed that secret in build pipelines, deployment scripts, or configuration files. The credential is checked into version control or stored in an unprotected vault, and every job that runs on the CI server uses the same identity to reach databases, Kubernetes clusters, or internal APIs. Because the connection is made directly from the runner to the target, there is no central place that can see which command was issued, which rows were read, or whether a secret was inadvertently exposed. Auditing is left to the target’s own logs, which often lack the context of who or what actually initiated the request.
This situation illustrates the core precondition that any mitigation must address: the need to limit standing access for non‑human identities while still allowing automated processes to function. Even if you rotate the secret daily, the request still travels straight to the backend service, bypassing any gate that could enforce just‑in‑time approval, mask sensitive fields, or block dangerous commands. The standing access problem is therefore fixed only partially – the credential is managed, but the enforcement surface remains absent.
Why standing access is dangerous for non‑human identities
Non‑human identities such as service accounts, bots, and CI runners are designed to be long‑lived. Their privileges are often scoped broadly because developers want convenience over security. When a breach occurs, an attacker who obtains a single static key instantly inherits all the rights that the service account possesses, and because the account never logs in interactively, traditional user‑centric monitoring tools miss the activity. The risk is amplified in environments where the same account is reused across multiple clusters or databases, creating a single point of failure.
What a data‑path gateway must provide
The missing piece is a control plane that sits between the identity and the target resource. This gateway must be able to:
- Inspect each request at the protocol level.
- Enforce just‑in‑time access policies that grant the minimum privilege for the duration of the operation.
- Require human approval for high‑risk commands before they reach the backend.
- Mask or redact sensitive fields in responses, preventing downstream leakage.
- records every session for replay and audit, creating an immutable trail that ties actions to the originating non‑human identity.
Only a gateway that lives in the data path can guarantee that these controls are applied consistently, regardless of how the service account is invoked.
Setup: defining non‑human identities
First, every automated workload should be represented by a distinct OIDC or SAML token, or by a service‑account identifier that the gateway can read. The token conveys who the caller is, what groups they belong to, and any attributes that drive policy decisions. This step is purely about authentication – it tells the system which identity is requesting access, but it does not enforce anything on its own.
The data path: enforcing controls
Once the identity is known, the gateway becomes the only place where enforcement can happen. hoop.dev sits in front of databases, Kubernetes clusters, SSH endpoints, and HTTP services, acting as an identity‑aware proxy. Because every packet passes through hoop.dev, it can apply the policies listed above before the request ever reaches the target.
Enforcement outcomes delivered by hoop.dev
hoop.dev records every session for replay and audit, creating an immutable trail that ties actions to the originating non‑human identity. It masks sensitive columns in database result sets, ensuring that downstream services never see raw credit‑card numbers or personal identifiers. When a command matches a high‑risk pattern, hoop.dev blocks it and routes the request to a human approver, turning a potential breach into a controlled workflow. Finally, because the gateway holds the backend credential, the agent or CI runner never sees the secret, eliminating credential sprawl.
By moving the enforcement point to the data path, organizations can retire standing access for non‑human identities without breaking automation. The gateway grants temporary, scoped permissions on demand, and every action is captured for compliance and forensic analysis.
To get started, follow the getting‑started guide and explore the learn section for deeper details on policy configuration. For those who prefer to run the gateway themselves, the source code and contribution guidelines are available on GitHub.
Explore the source code and contribute at https://github.com/hoophq/hoop.
