When a service account or an automated build pipeline is granted unrestricted access, a single compromised secret can let an attacker move laterally, delete data, or spin up costly resources, often without any trace. The financial and reputational damage of such a breach far exceeds the convenience of static credentials.
Why non‑human identities break traditional segregation of duties
Non‑human identities include service accounts, CI/CD runners, AI agents, and any credential that a program uses instead of a person. They are created to automate repetitive tasks, but they also inherit the same privileges as a human user when they are given broad, standing permissions. Because they are not tied to a single individual, it is easy to assign them to multiple responsibilities, deployment, database migration, and secret management, all at once. This conflation violates the principle of segregation of duties, which requires that no single entity be able to both request and approve a critical operation.
In practice, teams often store a service account key in a shared vault, embed it in configuration files, or bake it into container images. The key is then used directly by the program to reach the target system, be it a database, a Kubernetes cluster, or an SSH host. The gateway that the request traverses is the target itself, so there is no place to interject a policy check, capture the command, or require an additional approval step. Auditing becomes a matter of reviewing log files that may be incomplete, tampered with, or simply not correlated to the identity that originated the request.
The missing enforcement layer
The prerequisite for fixing this problem is to keep non‑human identities as the source of truth for who is making a request, but to route every request through a dedicated enforcement point. Without that point, the request still reaches the target directly, leaving the following gaps:
- No real‑time approval workflow for privileged actions.
- No command‑level audit that ties an operation to the originating service account.
- No inline masking of sensitive fields that might be exposed in responses.
- No ability to block dangerous commands before they hit the backend.
These gaps mean that segregation of duties remains a policy on paper, not an enforceable control.
hoop.dev as the data‑path enforcement gateway
hoop.dev is built to sit in the data path between any identity, human or non‑human, and the infrastructure it wants to reach. It acts as an identity‑aware proxy that verifies OIDC or SAML tokens, extracts group membership, and then applies policy decisions before forwarding traffic to the target resource. Because the gateway is the only place the request can pass, hoop.dev can enforce segregation of duties in a way that no setup‑only approach can.
When a service account initiates a connection, hoop.dev checks the request against a policy that can require separate roles for different actions. For example, a CI runner may be allowed to deploy containers but not to delete databases. If the runner attempts a prohibited command, hoop.dev can block it outright or route it for human approval. Every session is recorded, and the recorded data includes the exact command, the identity that issued it, and the response from the backend. This creates a reliable audit trail that satisfies compliance requirements and makes forensic analysis straightforward.