Many assume that only human users need identity controls, but non-human identity is equally essential for automated processes. In practice, teams often rely on a handful of shared API keys, static service‑account passwords, or long‑lived tokens that multiple pipelines and scripts consume. Those credentials are usually stored in plain text files or environment variables, and they grant broad access to databases, internal HTTP services, and cloud‑native resources.
Consider a typical CI/CD runner that pulls code, runs tests, and pushes artifacts. The runner authenticates to a PostgreSQL instance and an internal metrics endpoint using the same service account that also has write access to a production S3 bucket. No per‑job audit trail exists; the same credential is reused across dozens of jobs, and any compromise instantly exposes every downstream system.
This model creates three hidden risks. First, credential leakage spreads laterally because a single secret unlocks many services. Second, there is no visibility into which automated job performed which query or command, making forensic analysis almost impossible. Third, policy violations, such as a job that should only read data but accidentally writes, are never intercepted.
Addressing these risks starts with a solid non-human identity foundation. Assigning each CI job its own OIDC‑issued token, limiting its scopes, and binding it to a specific service account constitute the Setup layer. This step determines who the request is and whether it may start, but it does not enforce any guardrails on the actual traffic.
Even with finely scoped tokens, the request still travels directly to the target system. The database or HTTP service sees only a valid credential and processes the request without any inline checks, masking, or approval workflow. In other words, the enforcement outcomes that protect data and limit blast radius remain absent.
To close that gap, the access path must include a data‑path component that can inspect, control, and record every interaction. This is where hoop.dev enters the architecture.
Why non-human identity alone is not enough
Non-human identities provide authentication and authorization context, but without a gateway they cannot enforce command‑level policies. The target system receives the request unchanged, so any mis‑configuration or malicious use of the credential goes unchecked. A separate enforcement layer is required to apply just‑in‑time approvals, inline data masking, and session recording.
hoop.dev as the enforcement gateway
hoop.dev is an open‑source layer 7 gateway that sits between identities and infrastructure. It validates OIDC or SAML tokens, maps group membership to policy rules, and then proxies the connection to the underlying resource. Because the gateway resides in the data path, it is the only place where enforcement can happen.
When a non-human identity initiates a connection, hoop.dev performs three core actions:
- Policy enforcement. It checks the request against defined rules, blocks dangerous commands, and can route risky operations to a human approver before they reach the target.
- Inline masking. Sensitive fields in responses, such as credit‑card numbers or personal identifiers, are redacted in real time, preventing downstream systems from leaking data.
- Session recording. Every command and response is captured, enabling replay, audit, and forensic analysis without exposing the original credential.
All of these outcomes exist because hoop.dev occupies the data path. The Setup layer still decides who may start a request, but hoop.dev is the mechanism that actually enforces the policy.
Applying hoop.dev to automated workloads
For CI pipelines, each job can request a short‑lived token from the identity provider. hoop.dev validates that token, applies the job‑specific policy, and then forwards the traffic to the database or HTTP service. If the job attempts a write operation that is not permitted, hoop.dev blocks the command and logs the event. If the job reads a column containing personally identifiable information, hoop.dev masks that column before it reaches the downstream consumer.
Because the gateway runs alongside a lightweight agent inside the network, credentials never leave the control plane. The agent holds the static service credentials needed to reach the target, but those credentials are never exposed to the calling process. This satisfies the principle that "the agent never sees the credential" while still allowing automated services to operate securely.
Getting started with hoop.dev
Deploying hoop.dev is straightforward. The official getting‑started guide walks you through a Docker Compose launch, an OIDC configuration, and the registration of a sample PostgreSQL connection. Once the gateway is running, you can define policies in the learn section and attach them to your non-human identities.
Because hoop.dev is MIT licensed and fully open source, you can audit the code, extend the policy engine, or contribute new connectors. The repository is available on GitHub, and contributions are welcomed.
FAQ
How do I provision a non-human identity for a CI job?
Use your identity provider’s OIDC client credentials flow to issue a short‑lived token scoped to the specific service account. Assign the token to the job’s environment and let hoop.dev validate it at connection time.
Does hoop.dev store the credentials for the target systems?
No. The static credentials needed to reach the backend are kept inside the network‑resident agent. The calling process never sees them, and hoop.dev only proxies the traffic.
Can I replay a recorded session for an automated task?
Yes. hoop.dev records each session in a replay‑able format. You can retrieve the logs from the audit store and replay them for debugging or compliance verification.
Explore the code, report issues, or contribute improvements at https://github.com/hoophq/hoop.
