The problem with unchecked non‑human identities
Many assume that service accounts and automated bots can be left to run without any human-in-the-loop approval, but the lack of that control creates a blind spot that attackers can exploit. In reality, those identities often hold long‑lived credentials that grant broad access to databases, Kubernetes clusters, or internal APIs. Teams typically embed the same secret in multiple pipelines, copy it into CI runners, and allow the credential to be used whenever a job executes. The result is a moving target for attackers: once a secret leaks, every downstream system becomes vulnerable, and there is no reliable record of which automation performed which action.
Because the credential is static and the connection goes directly from the automation to the target, there is no point at which an approval step can intervene. Auditors cannot trace a specific command back to a human decision, and security teams have no way to block a risky operation before it reaches the database or the cluster. The environment ends up with standing access that is both invisible and ungovernable.
Why human‑in‑the‑loop approval matters for bots
Human‑in‑the‑loop approval introduces a deliberate pause before a privileged operation is allowed to proceed. The precondition is that a non‑human identity must request access, and a policy mandates an explicit human decision for actions that exceed a defined risk threshold. This approach fixes the lack of oversight, but it still leaves the request traveling straight to the target service. Only a dedicated gateway can ensure the request is held until approval is recorded and can create an immutable audit trail of the decision.
The missing piece, therefore, is a control surface that sits between the automation and the resource, forcing every request to pass through a checkpoint that can enforce approval, record the interaction, and apply additional safeguards such as data masking. Only a gateway that occupies the data path can guarantee that the approval outcome is enforced.
hoop.dev as the enforcement point
hoop.dev is a Layer 7 gateway that proxies connections from identities, human or non‑human, to infrastructure such as databases, Kubernetes clusters, SSH hosts, and internal HTTP services. By placing hoop.dev in the data path, every request from a service account or bot must travel through the gateway before reaching the target.
Approval workflow built into the gateway
When a non‑human identity initiates a connection, hoop.dev checks the request against a policy that requires human‑in‑the‑loop approval for high‑risk commands. If approval is needed, the gateway pauses the request and routes it to an approver defined in the policy. The approver can grant or deny the action from a web console or notification channel. Only after a positive decision does hoop.dev forward the command to the backend system.
Session recording and immutable audit
hoop.dev records each session end‑to‑end, capturing the identity that initiated the request, the exact commands issued, and the approval decision. The recorded session can be replayed later for forensic analysis or compliance reporting. Because the recording happens inside the gateway, the backend never sees an unrecorded operation.
Inline data masking for sensitive responses
For workloads that return personally identifiable information or secret values, hoop.dev can mask those fields in real time before they leave the gateway. The masking policy is applied after approval, ensuring that only authorized humans ever see the raw data while the rest of the pipeline receives a sanitized view.
Getting started with human‑in‑the‑loop approval
To adopt this model, deploy the hoop.dev gateway in your network and register the resources you want to protect. Configure OIDC or SAML authentication so that the gateway can verify the identity of both the service account and the human approver. Define a policy that marks specific commands, such as schema changes in a database or privileged pod creation in Kubernetes, as requiring approval. The getting‑started guide walks you through the deployment steps, and the feature documentation provides details on policy syntax and approval routing.
All of the heavy lifting, credential storage, session capture, masking, and approval enforcement, occurs inside hoop.dev, so the automation never handles secrets directly. This separation of duties satisfies the principle of least privilege while giving security teams a clear, enforceable control point.
FAQ
- Do I need to modify my existing CI pipelines? No. Once hoop.dev is in place, pipelines simply point their client tools (psql, kubectl, ssh, etc.) at the gateway endpoint. The gateway intercepts traffic without requiring code changes.
- What happens if an approver is unavailable? Policies can define fallback approvers or time‑based auto‑denial. The request will remain paused in hoop.dev until a decision is recorded.
- Can I audit past approvals? Yes. hoop.dev stores each session and approval decision, making it searchable for compliance audits or incident investigations.
Ready to add human‑in‑the‑loop approval to your non‑human identities? Explore the open‑source repository and start building a safer automation pipeline today.
