Static service credentials are a silent backdoor that attackers love, and without proper policy enforcement they become a permanent foothold.
Non‑human identities, service accounts, CI/CD bots, AI agents, are often granted long‑lived keys that sit in code repositories, CI pipelines, or container images. When a breach occurs, those keys let an adversary move laterally, exfiltrate data, or spin up new workloads without ever touching a human login. The lack of visibility means teams discover the abuse only after damage is done.
Most organizations address the problem by tightening the creation process: they issue short‑lived tokens, enforce least‑privilege scopes, and store secrets in vaults. Those steps are essential, but they stop at the point of authentication. The request still travels straight to the target database, Kubernetes API, or SSH server, and the infrastructure never sees a policy check. No audit trail records the exact commands, no inline masking protects sensitive fields, and no real‑time approval can block a dangerous operation.
Why policy enforcement needs a dedicated data‑path control
The missing piece is a place where every request can be inspected before it reaches the resource. A setup that only defines who may ask for access cannot enforce what they may do once the connection is open. Without a gateway, a service account with read‑only database rights could still execute a destructive stored procedure if the application logic allows it. The enforcement outcome, preventing that call, must happen where the traffic is flowing, not merely at the identity provider.
In practice this means three distinct responsibilities:
- Setup: Configure OIDC or SAML tokens for the service account, assign it to a group, and apply least‑privilege roles. This tells the system who the request is.
- The data path: Insert a proxy that sits between the identity and the target. Only this layer can examine the protocol payload and apply policy.
- Enforcement outcomes: Record the session, mask sensitive response fields, require just‑in‑time approval for risky commands, and block disallowed actions. These outcomes exist only because the proxy is in the data path.
Introducing hoop.dev as the policy enforcement gateway
hoop.dev is built exactly for this role. It is a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH servers, and internal HTTP services. When a non‑human identity presents a valid OIDC token, hoop.dev verifies the token, extracts group membership, and then decides whether to allow the request to pass.
Because hoop.dev sits in the data path, it can enforce policy at the protocol level. It records each session for replay, masks fields such as credit‑card numbers in query results, and can pause a command that matches a risky pattern until a human approves it. The gateway never hands the underlying credential to the caller; the credential lives only inside hoop.dev’s agent, eliminating credential leakage.
All of these enforcement outcomes, session recording, inline masking, just‑in‑time approval, command blocking, are possible only because hoop.dev is the point of inspection. If you removed hoop.dev and left the setup unchanged, the service account would again have unrestricted access to the backend.
Key capabilities for non‑human identities
- Just‑in‑time access: A CI job can request a short‑lived connection, and hoop.dev will grant it only for the duration of the pipeline step.
- Inline data masking: Query results that contain personally identifiable information are redacted before they reach the bot, reducing data exposure.
- Command‑level audit: Every statement executed by an AI agent is logged with identity, timestamp, and outcome, giving you a complete forensic trail.
- Human approval workflow: If a deployment script attempts a destructive operation, hoop.dev can route the request to an on‑call engineer for explicit approval.
What to watch for when securing non‑human identities
Even with a gateway in place, certain pitfalls can undermine policy enforcement:
- Over‑broad group membership: Assigning a service account to a group that has wide access defeats the purpose of fine‑grained policies. Keep group scopes narrow and review them regularly.
- Credential rotation gaps: The gateway holds the credential for the target system. If the underlying secret is rotated without updating hoop.dev’s configuration, the connection will fail and may trigger emergency credential reuse.
- Insufficient logging retention: Recording sessions is only useful if you retain them for the period required by your compliance program. Configure your log storage accordingly.
Addressing these concerns starts with a solid identity setup, but the decisive control point remains the gateway.
Getting started with hoop.dev
To protect non‑human identities, deploy hoop.dev near the resources you want to guard. The quick‑start guide walks you through a Docker Compose deployment, OIDC configuration, and adding a connection for a PostgreSQL database or a Kubernetes cluster. Once the gateway is running, register your service accounts, define policy rules, and let your CI pipelines point at the hoop.dev endpoint instead of the raw target.
For detailed steps, see the getting started documentation. For a deeper dive into policy features such as masking and approval workflows, explore the learn section. The source code and contribution guidelines are available on GitHub.
FAQ
Do I need to change my existing CI scripts?
No. hoop.dev accepts standard client connections (psql, kubectl, ssh, etc.). You only change the hostname and port to point at the gateway.
Can hoop.dev enforce policies on AI agents that generate code?
Yes. The gateway inspects the LLM‑generated commands before they reach the target, applying the same masking and approval rules you define for any non‑human identity.
What happens if the gateway goes down?
Without the gateway, the service account cannot reach the protected resource because the credential is stored only inside hoop.dev’s agent. This fail‑closed behavior prevents accidental credential exposure.
