When a single engineer can run any script on production servers, the organization pays the price in data loss, compliance penalties, and eroded trust. A single careless command can wipe a database, expose secrets, or trigger a cascade of downstream failures. The financial impact of a breach caused by over‑privileged code execution often dwarfs the cost of the controls that could have prevented it.
Current practice without segregation of duties
Most teams start with a shared service account or a static SSH key that multiple people use to reach critical workloads. The credential lives in a password manager, a CI secret store, or even a plain‑text file on a shared server. Because the same identity is used for deployment, debugging, and ad‑hoc queries, there is no way to tell who actually launched a particular command. Auditing is an after‑the‑fact exercise: logs are scattered across host syslog, application logs, and occasional cloud‑provider audit trails, none of which are tied to a single, accountable identity.
This model violates the core principle of segregation of duties: the same entity should not be able to both request and approve a high‑risk operation. The result is an unchecked blast radius, difficulty proving compliance, and an environment where a compromised credential instantly grants unrestricted access.
What segregation of duties fixes – and what it still leaves open
Introducing a policy that separates the requestor from the approver reduces the risk of accidental or malicious changes. The requestor can ask for a specific operation, while a designated reviewer must explicitly grant permission before the command reaches the target system. This split creates a clear audit trail and makes it possible to enforce least‑privilege principles at the moment of execution.
However, if the request still travels directly from the reviewer’s workstation to the production host, the organization loses the enforcement point. The requestor’s identity is verified, but nothing inspects the actual payload, masks secrets in responses, or records the session for replay. In short, the policy exists, but the technical control plane is missing.
Why the data‑path gateway is essential
To close the gap, the enforcement layer must sit on the data path – the exact place where the request leaves the reviewer’s client and enters the target service. Only a gateway that proxies the connection can see every command, apply real‑time checks, and enforce the segregation of duties policy without exposing credentials to the end user.
Introducing hoop.dev as the enforcement gateway
hoop.dev is a Layer 7 gateway that sits between identities and infrastructure. It proxies database connections, SSH sessions, Kubernetes exec calls, and HTTP APIs, inserting policy enforcement at the protocol level. By positioning hoop.dev in the data path, every code‑execution request is subject to the same controls that the segregation of duties policy demands.
Setup: identity and least‑privilege grants
First, define non‑human identities for each automation workflow. Use an OIDC or SAML provider (Okta, Azure AD, Google Workspace, etc.) so that each user receives a short‑lived token containing group membership. Assign the minimal set of roles needed for the requested operation – for example, read‑only access to a database or exec rights on a specific Kubernetes pod. These tokens are the only credential the user presents to hoop.dev.
The data path: hoop.dev as the only place enforcement happens
When a request reaches hoop.dev, the gateway authenticates the OIDC token, extracts the user’s groups, and checks the request against the configured policy. Because the connection is terminated at the gateway, the target system never sees the raw user token or any privileged credential. All traffic flows through hoop.dev, making it the sole point where command‑level decisions are made.
Enforcement outcomes provided by hoop.dev
- hoop.dev records each session, creating a replayable audit trail that ties every command to a specific identity.
- It masks sensitive fields in responses, preventing secrets from leaking to the console or logs.
- Just‑in‑time approval workflows pause high‑risk commands until an authorized reviewer grants permission.
- Dangerous commands are blocked before they reach the target, reducing the blast radius of a mistake.
- The gateway never exposes the underlying service credentials to the user, ensuring that the “agent never sees the secret”.
These outcomes exist only because hoop.dev occupies the data path. Remove the gateway and the same policies would have no technical enforcement point, leaving the system vulnerable.
Getting started
Deploy the gateway using the official getting‑started guide. The documentation walks you through configuring OIDC authentication, defining role‑based policies, and registering a database or SSH target. Once the gateway is running, users connect with their standard client tools (psql, kubectl, ssh) while hoop.dev transparently applies segregation of duties controls.
For deeper insight into policy configuration, masking rules, and approval workflows, explore the learn section. The open‑source repository contains example manifests and a community‑driven FAQ that can help you tailor the solution to your organization’s risk model.
FAQ
Does hoop.dev replace my existing identity provider?
No. hoop.dev consumes tokens from your IdP and uses the embedded group information to make decisions. It does not store or broker credentials for the IdP itself.
Can I enforce segregation of duties for both human users and service accounts?
Yes. By issuing short‑lived OIDC tokens to service accounts, you can apply the same approval and masking policies that you use for human engineers.
What happens to logs after a session ends?
hoop.dev retains a replayable record of the session, including the command stream and any masked output. These logs can be exported to your SIEM or retained for audit purposes.
Take the next step
Explore the source code, contribute improvements, or spin up a local demo by visiting the official GitHub repository: hoop.dev on GitHub.
