Static secrets for bots are a gold mine for attackers and a glaring secrets management failure.
In many organizations, a service account’s password lives in a Git repository alongside application code. A container image may bake in an AWS access key that never expires. Teams often share a single API token across dozens of CI pipelines, trusting that the token will be revoked only when a breach is discovered. The result is a sprawling web of long‑lived credentials that no one can reliably inventory.
Because these non‑human identities talk directly to databases, Kubernetes clusters, or SSH endpoints, a compromised secret instantly grants unfettered access to critical infrastructure. Attackers can exfiltrate data, modify workloads, or pivot laterally, all while the original owners remain unaware. The lack of per‑request visibility means that even a well‑intentioned engineer cannot prove which bot performed a destructive command.
What teams need is a dedicated secrets management discipline for non‑human identities. Centralizing secrets in a vault, rotating them on a schedule, and assigning each service account a minimal set of permissions are essential steps. However, those steps alone do not stop a rogue request from reaching the target unchecked. The request still travels straight from the agent to the database or the Kubernetes API, bypassing any real‑time guardrails. No command‑level audit, no inline masking of sensitive fields, and no just‑in‑time approval are applied once the secret is presented.
Enter hoop.dev. hoop.dev places a Layer 7 gateway between the non‑human identity and the target system. Every connection, whether it is a PostgreSQL query from a CI job, a kubectl exec from an automation script, or an SSH session launched by a deployment bot, must pass through this gateway.
How the gateway fits into the identity stack for secrets management
The first piece of the puzzle is identity. Non‑human identities are issued OIDC or SAML tokens by an existing identity provider. Those tokens convey who the request is and what groups the service account belongs to. This setup decides who may start a connection, but it does not enforce what the connection can do.
The data path, embodied by hoop.dev, is the only place enforcement can happen. The gateway terminates the incoming protocol, inspects each request, and then forwards it to the target. Because the gateway sits in the middle, it can apply policies that no downstream system can override.
Enforcement outcomes delivered by hoop.dev
- hoop.dev records every session, creating a replayable audit trail that shows which bot ran which command and when.
- hoop.dev masks sensitive response fields in real time, preventing secrets from leaking into logs or downstream pipelines.
- hoop.dev requires just‑in‑time approval for high‑risk operations, forcing a human to sign off before a destructive command is executed.
- hoop.dev blocks prohibited commands at the protocol layer, stopping dangerous actions before they reach the target.
- hoop.dev scopes credential use to the exact duration of the session, eliminating the need for long‑lived static keys.
These outcomes exist only because hoop.dev occupies the data path. If the gateway were removed, the same OIDC tokens and vault‑stored secrets would still be presented directly to the target, and none of the above protections would apply.
Why this matters for secrets management
By moving control to the gateway, organizations gain visibility and control without rewriting existing automation. Engineers continue to use their familiar clients, psql, kubectl, ssh, while hoop.dev silently enforces policy. The approach reduces blast radius: a compromised service account can no longer issue arbitrary commands because hoop.dev will either mask the response, require approval, or block the command outright.
Additionally, the session logs generated by hoop.dev provide the evidence auditors look for when assessing secrets‑management processes. Teams can demonstrate that each secret was used in a controlled, auditable manner, satisfying compliance requirements without building a custom logging pipeline.
Getting started
To adopt this model, begin with the getting‑started guide. Deploy the gateway, configure your non‑human identities to obtain OIDC tokens, and register the target resources you want to protect. The learn section contains deeper discussions of policy design, masking strategies, and approval workflows.
FAQ
How does hoop.dev handle secret rotation for service accounts? Rotation happens in the secret store, not in the gateway. Because hoop.dev always fetches the current credential at session start, a rotated secret takes effect immediately without interrupting existing policies.
Does hoop.dev replace my existing vault? No. hoop.dev complements a vault by enforcing access at the connection level. The vault still protects the secret at rest; hoop.dev protects the use of that secret in flight.
Ready to see the code? Explore the open‑source repository on GitHub and start building a tighter secrets‑management posture for your bots and service accounts.
