When dealing with non-human identity, an offboarded contractor’s CI job kept querying a production database with a service‑account token that never expired. The token had broad read‑write rights, and no one noticed the job running after the contractor left. The same pattern repeats when a nightly batch process uses a hard‑coded API key that can access dozens of internal services. Those are classic examples of how non‑human identities are often managed today: static credentials stored in code repositories, over‑scoped tokens granted to automation, and no visibility into what the automated actors actually do.
Teams recognize the need for tighter control. They start by issuing short‑lived tokens, moving secrets to vaults, and defining role‑based permissions for each service account. Those steps constitute the setup, the identity layer that decides who the request is and whether it may start. However, the setup alone does not stop a compromised token from issuing a destructive command, nor does it provide a record of every query the automation performed.
Why the data path matters for non‑human identity security
The real enforcement point must sit on the network path between the automated client and the target resource. Only a gateway that inspects traffic can apply real‑time decisions such as:
- Blocking commands that match a deny list before they reach the database.
- Routing risky queries to a human approver for explicit consent.
- Masking sensitive fields in responses so that logs never contain raw credit‑card numbers or personal identifiers.
- Recording the full session for replay and audit, ensuring that every SELECT, UPDATE, or SSH command is traceable to a specific service account and token.
These outcomes exist only because the gateway sits in the data path. Without that interception point, the request would travel directly from the automation runner to the target, bypassing any guardrails.
Introducing hoop.dev as the enforcement gateway
hoop.dev fulfills the architectural requirement of a Layer 7 gateway that proxies connections for databases, Kubernetes, SSH, RDP, and internal HTTP services. By placing hoop.dev between the non‑human identity and the infrastructure, it becomes the active enforcer of policy.
When a CI pipeline authenticates via OIDC, hoop.dev validates the token, extracts the service‑account identity, and then applies the configured policies. For each request it:
- Records each session so auditors can replay exactly what the automation did.
- Applies inline masking to hide sensitive columns before they are written to logs.
- Enforces just‑in‑time approval for operations that exceed the baseline privilege set.
- Blocks disallowed commands in real time, preventing accidental data loss.
Because hoop.dev is the only component that sees the clear‑text traffic, the enforcement outcomes are guaranteed to happen regardless of how the service account was provisioned. If the token were stolen, hoop.dev would still block prohibited actions and record the attempt.