Many teams assume that giving a service account a single static key is enough to satisfy RBAC. In practice, that key is often copied across dozens of CI pipelines, shared between multiple micro‑services, and stored in plain‑text configuration files. The result is a world where a compromised credential instantly grants unrestricted access to every downstream resource, and no one can tell which automated job performed which operation.
Because the credential is baked into the connection, the request bypasses any central policy engine. The service account talks directly to the database, the Kubernetes API, or the SSH daemon, and the target sees only the service identity – not the originating pipeline, the user who triggered it, or the business purpose behind the call. Auditors cannot answer who ran a destructive query, and security teams have no lever to block a dangerous command before it reaches the server.
RBAC for non‑human identities therefore needs two things: a way to express fine‑grained roles for bots and service accounts, and a place to enforce those roles on every request. The first piece – defining roles, groups, and least‑privilege permissions – lives in the identity provider and the provisioning system. That setup decides *who* the service identity is and *what* it may request, but it does not stop the request from flowing straight to the target without oversight.
Even with a well‑scoped role, the request still reaches the backend directly, without a checkpoint that could log the exact query, mask sensitive columns, or require an on‑demand approval for high‑risk actions. Without a control point in the data path, the organization cannot guarantee that every automated action is visible, reversible, or aligned with internal policies.
hoop.dev inserts the enforcement point exactly where it is needed – between the non‑human identity and the infrastructure resource. By acting as a Layer 7 gateway, hoop.dev receives the connection, validates the OIDC or SAML token, and then applies the RBAC policy before any traffic reaches the target.
Setup: provisioning non‑human identities
The first step is to create service accounts, CI tokens, or automation users in your identity provider (Okta, Azure AD, Google Workspace, etc.). Assign each identity to a group that reflects its intended role – for example, ci‑deploy‑read or batch‑processor‑write. These groups become the source of truth for RBAC decisions.
Because the identity provider is only the source of truth, you must ensure that the groups are kept up to date and that any new service account is placed in the correct group before it can be used. This is a classic “setup” responsibility: it decides who the request is and whether it may start, but it does not enforce anything on its own.
The data path: hoop.dev as the enforcement gateway
hoop.dev sits in the network close to the protected resource. When a non‑human identity initiates a connection, hoop.dev validates the presented token, extracts the group membership, and looks up the corresponding RBAC policy. Only after the policy check passes does hoop.dev forward the request to the backend.
hoop.dev records each session, capturing the exact commands or queries that were executed. This creates a replayable audit trail that can be examined later for compliance or forensic analysis.