When segregation of duties is ignored and a single engineer can both approve and execute production changes, the organization pays a hidden price in risk, compliance penalties, and lost trust.
In many self‑hosted deployments, teams rely on a handful of static admin passwords, shared SSH keys, or long‑lived service‑account tokens. Those credentials are often stored in plain text files or password managers that are accessed by multiple people. The result is a “golden” credential that can be used to read, modify, or delete critical data without any visibility into who actually performed the action.
This practice creates a perfect storm for accidental data loss, malicious insider activity, and audit failures. A compliance reviewer will struggle to answer simple questions: Who changed this configuration? Was the change authorized? Was any sensitive data exposed during the operation? Without concrete evidence, the organization either faces fines or must spend weeks reconstructing events from fragmented logs.
Segregation of duties (SoD) is the control framework that breaks this chain. It requires that the person who requests a privileged operation is not the same person who executes it, and that each role has only the permissions needed for its specific purpose. SoD reduces the blast radius of a compromised credential and forces a second line of review before high‑impact actions are taken.
Implementing SoD in a self‑hosted environment is more than assigning roles in an identity provider. The real challenge is where the enforcement lives. If a request is sent directly to a database, Kubernetes API, or SSH daemon, the target system has no visibility into the policy that demanded a separate approver. The request reaches the resource unchanged, and the system cannot log the decision point, mask sensitive fields, or block dangerous commands.
Why identity alone is not enough
Modern identity platforms can issue OIDC or SAML tokens, attach group memberships, and enforce least‑privilege service accounts. Those mechanisms answer the question “who is allowed to start a connection?” but they stop short of answering “what happens after the connection is opened?” Without a gate in the data path, the request still flows straight to the target, bypassing any runtime checks, approvals, or real‑time masking.
In this pre‑condition, the organization has taken the first step toward SoD, defining non‑human identities and scoping them tightly, but the enforcement gap remains. The connection reaches the database or Kubernetes node directly, leaving no audit trail of the command, no opportunity to require a manager’s sign‑off, and no way to hide credit‑card numbers that might appear in query results.
hoop.dev as the enforcement layer
hoop.dev solves the missing piece by acting as a Layer 7 gateway that sits between the identity layer and the infrastructure. It intercepts traffic for databases, SSH, RDP, and Kubernetes, then applies policy decisions before the request reaches the target.
Because hoop.dev is the only component that sees both the authenticated identity and the actual payload, it can enforce the full set of SoD controls:
- It records each session, producing an audit trail that captures the approving identity and the executing identity.
- It requires just‑in‑time approval for privileged commands, forcing a separate approver to grant a short‑lived token before the operation proceeds.
- It masks sensitive fields in responses, preventing accidental exposure of PII or financial data.
- It blocks dangerous commands, such as DROP DATABASE or sudo rm ‑rf, based on policy rules.
- It stores the session for replay, enabling post‑mortem investigations without giving the agent direct access to the underlying credential.
All of these outcomes are possible only because hoop.dev occupies the data path. The surrounding identity setup (OIDC providers, service‑account roles, least‑privilege grants) decides who may attempt a connection, but hoop.dev is the gate that actually enforces segregation of duties.
Putting the pieces together
Setup: Configure an OIDC or SAML provider (Okta, Azure AD, Google Workspace, etc.) to issue short‑lived tokens. Define non‑human service accounts with the minimum permissions required for each workload. Deploy those accounts in your orchestration platform and grant hoop.dev permission to assume them when needed.
The data path: Deploy the hoop.dev gateway inside the same network segment as the target resource. Register each database, Kubernetes cluster, or SSH host as a connection in hoop.dev. The gateway holds the actual credential; users never see it.
Enforcement outcomes: When an engineer initiates a connection, hoop.dev validates the token, checks the policy, and either allows the request, prompts a manager for approval, or blocks it outright. The session is recorded, any sensitive data is redacted, and the audit record is stored for compliance reporting.
This architecture satisfies the core SoD requirement: the requestor cannot both approve and execute a privileged operation because the approval step occurs inside hoop.dev, a component that the requestor cannot bypass. Even if a credential is leaked, an attacker would still need a separate approval token to perform a high‑risk action.
Benefits for compliance and security
Because every command is tied to an explicit approval, auditors can trace the full chain of custody for any change. The recorded sessions provide concrete evidence for standards such as SOC 2, without requiring additional tooling. Masking protects regulated data during routine queries, reducing the risk of accidental leakage. Command blocking and just‑in‑time approval shrink the attack surface, limiting what a compromised service account can do.
In practice, teams that adopt hoop.dev report faster incident response, clearer ownership of changes, and lower remediation costs after a breach. The gateway also simplifies onboarding: new services are added by registering a connection, and policy updates propagate automatically across all protected resources.
Get started
Review the getting started guide to spin up a self‑hosted gateway and connect your first database. The learn section dives deeper into policy definitions, approval workflows, and masking rules.
When you are ready to explore the code, contribute, or run your own instance, the open‑source repository is available on GitHub: github.com/hoophq/hoop.
FAQ
Q: Does hoop.dev replace my existing identity provider?
A: No. hoop.dev consumes tokens from your IdP and uses the identity information to make access decisions. It adds a control layer without removing the existing authentication flow.
Q: Can I use hoop.dev with multiple cloud providers?
A: Yes. The gateway supports connections to databases, Kubernetes clusters, SSH hosts, and HTTP services regardless of where they run. Each target is registered individually, and policies are applied uniformly.
Q: How does hoop.dev help with audit requirements?
A: Every session is recorded and stored with the approving identity, timestamps, and command details. Those logs can be exported for SOC 2 or other compliance audits, providing an authoritative audit trail that links each action to the approving identity and timestamp.
