Many assume that a service account is just another user that can be treated like a human login. In fact, a service account is a machine-originated, non-human identity that needs its own lifecycle, permissions, and audit trail.
In most organizations, tool‑using agents – CI runners, backup scripts, automated deployers – still reach databases, clusters, or SSH endpoints with a single static credential that is shared across dozens of pipelines. Those secrets sit in configuration files, environment variables, or secret‑management vaults, and anyone who can read the file can impersonate the agent. The result is standing access that never expires, no visibility into which pipeline ran which command, and a wide blast radius if the credential leaks.
This pattern violates the principle of least privilege and makes it impossible to answer basic forensic questions: Who accessed the production database at 03:12? Which CI job modified a Kubernetes secret? Without distinct identities, the answer is always "the shared service account".
Assigning a non-human identity to each automated consumer solves the credential‑sharing problem at its source. The identity is minted in the organization’s IdP (Okta, Azure AD, Google Workspace, etc.) and is bound to a specific role, expiration, and set of permissions. Because the identity is distinct, you can audit usage per agent, rotate secrets automatically, and enforce just‑in‑time (JIT) grants that expire as soon as the job finishes.
However, creating a non‑human identity alone does not close the security gap. The request still travels directly from the agent to the target service. Without a control point on that path, there is no way to record the session, mask sensitive fields in query results, or require an approval before a destructive command runs. The setup stage decides who may start a request, but it does not enforce policy on the traffic itself.
Placing enforcement in the data path
To achieve full runtime governance, the enforcement point must sit in the data path – the network hop that all traffic must cross before reaching the target. This is where hoop.dev operates. hoop.dev acts as an identity‑aware proxy that verifies the non‑human token, translates it into the credential needed for the backend, and then inspects every protocol message.
hoop.dev records each session so that auditors can replay exactly what an automated job did. hoop.dev masks sensitive fields in database responses, preventing downstream logs from leaking credit‑card numbers or personal data. hoop.dev blocks commands that violate policy, such as "DROP DATABASE" issued from a CI pipeline. hoop.dev also routes risky operations to a human approver before they are executed, providing a final safeguard.
Practical steps to adopt non‑human identities with hoop.dev
- Define a service account in your IdP for each class of agent (e.g., "ci‑runner", "backup‑service"). Assign it the minimal role needed for its job.
- Map the IdP group or attribute to a hoop.dev role that scopes the target resources (specific databases, clusters, or hosts).
- Register the target resource in hoop.dev and let the gateway store the backend credential. The agent never sees the password or key.
- Enable JIT access in hoop.dev so that the token is only valid for the duration of the job.
- Turn on session recording and inline masking for any data‑bearing connections.
- Configure approval workflows for high‑risk commands; hoop.dev will pause the request until a designated reviewer approves.
By keeping the enforcement logic in the data path, you guarantee that every action – even those performed by a non‑human identity – is observable and controllable.
Common pitfalls to avoid
- Failing to rotate the IdP‑issued service account credentials regularly. Even with hoop.dev, a stale credential can be abused if an attacker compromises the token.
- Over‑scoping the role attached to the agent. Grant only the specific tables or namespaces the job needs.
- Disabling session recording because of storage concerns. Without logs, you lose the audit trail that hoop.dev provides.
- Neglecting approval steps for destructive operations. JIT grants are useful, but some actions still require a human check.
For detailed configuration guidance, see the getting‑started documentation and the learn section that walks through role mapping, JIT setup, and masking policies.
FAQ
Do I need to change my existing CI pipelines?
No. Agents continue to use their standard client tools (psql, kubectl, ssh). The only change is that they authenticate against the IdP and then route traffic through hoop.dev.
Can I use hoop.dev with multiple IdPs?
Yes. hoop.dev supports any OIDC‑compatible provider, so you can mix Okta, Azure AD, or Google Workspace as long as the non‑human identities are provisioned there.
What happens if an agent tries to run a command that is not allowed?
hoop.dev blocks the command in real time and returns an error to the client. The blocked attempt is logged in the session record.
Ready to see the code? View the source on GitHub.
