Relying on a single service account for every automated job creates a single point of failure that attackers love. When those jobs run under a shared non-human identity, the risk multiplies.
In many organizations, agents that run CI pipelines, auto‑scaling workers, or background bots are given a static credential – often a long‑lived API key or a shared SSH key. The same credential is copied into dozens of scripts, baked into container images, and stored in plain‑text configuration files. When a breach occurs, the attacker inherits the full privilege set of every downstream system the agent can reach, and there is little visibility into which job actually performed the malicious action.
This is the unsanitized starting state for most agent orchestration environments. Engineers prioritize speed over security, so they grant broad standing access to non-human identities and accept the lack of audit as a cost of convenience. The result is a sprawling web of privileged tokens that are hard to rotate, impossible to attribute, and completely invisible to compliance teams.
Why non-human identity alone is not enough
Introducing a distinct non-human identity for each automation job is a necessary first step. Modern identity providers can issue short‑lived OIDC or SAML tokens to service accounts, and orchestration platforms can attach these tokens to individual tasks. This setup gives us two important pieces of the puzzle:
- Setup: The identity provider decides who the request is – a CI runner, a backup daemon, or a monitoring agent – and enforces least‑privilege scopes at token issuance time.
- Setup limitation: The token still travels directly to the target database, Kubernetes API, or SSH endpoint without any inline enforcement. No command is inspected, no response is masked, and no human ever sees a request for approval.
Because the enforcement point is missing, the following gaps remain:
- There is no real‑time audit of what each automated job actually does once it reaches the backend.
- Sensitive fields – passwords, personal data, or credit‑card numbers – can be returned in clear text because no gateway inspects the payload.
- High‑risk commands (e.g., dropping a production table) can be issued without a checkpoint, even if the token’s policy says “read‑only”.
In other words, non-human identity fixes identity‑level control but leaves the data path completely open.
Placing enforcement in the data path with hoop.dev
hoop.dev provides the missing layer‑7 gateway that sits between the non-human identity and the target resource. By proxying every connection – whether it is a PostgreSQL query, a kubectl exec, or an SSH session – hoop.dev becomes the only place where enforcement can happen.
When an automated job presents its OIDC token, hoop.dev validates the token (the Setup step) and then forwards the request through its agent. At that point the gateway applies a set of policies that constitute the Enforcement outcomes:
- hoop.dev records each session, creating a replayable audit trail that ties every command back to the originating non-human identity.
- hoop.dev masks sensitive fields in responses, ensuring that downstream logs or screen captures never expose raw secrets.
- hoop.dev blocks commands that violate the policy – for example, a “DROP DATABASE” issued by a backup agent – and can route them to a human approver for just‑in‑time consent.
- hoop.dev enforces just‑in‑time access, granting temporary elevation only for the duration of an approved request.
All of these outcomes exist only because hoop.dev occupies the data path. Remove the gateway and the same non-human identity would again enjoy unrestricted, unrecorded access.
Because the gateway runs as a network‑resident agent, the actual credential used to talk to the backend never leaves the controlled environment. The automation job never sees the database password or the Kubernetes service‑account token; it only presents its short‑lived identity token to hoop.dev.
Practical considerations for adopting non-human identity with a gateway
Before you deploy a gateway, make sure your identity provider can issue short‑lived tokens for each automation workload. Map each workload to a distinct group or role that reflects the minimal privileges it needs. Then register the target resources in the gateway, linking them to the appropriate credential store.
Once the setup is complete, you gain three concrete benefits:
- Full visibility – every automated action is logged and can be replayed for forensic analysis.
- Data protection – sensitive columns are redacted in real time, reducing leakage risk.
- Risk reduction – dangerous commands require explicit approval, turning accidental blasts into controlled events.
For a step‑by‑step walk‑through, start with the getting started guide and explore the policy language in the learn section. The repository on GitHub contains the full source code and deployment manifests.
FAQ
Q: Do I need to change my existing CI pipelines?
A: No. The pipelines continue to use their standard clients (psql, kubectl, ssh). The only change is the endpoint – it now points at the gateway instead of the raw service.
Q: How does hoop.dev handle token rotation?
A: The gateway validates each incoming OIDC token against the identity provider, so token rotation is transparent to the automation job.
Q: Can I still use existing service‑account keys for legacy tools?
A: Legacy tools can be wrapped by the gateway, but you should migrate them to short‑lived non-human identities to gain full audit and masking capabilities.
Explore the open‑source implementation and contribute improvements on GitHub.
