When a single service account can both read and modify production data, a single mistake can corrupt weeks of work and trigger costly incident response. In many organizations, automation scripts, CI pipelines, and AI‑driven agents loop through the same credential to perform every operation, violating segregation of duties. The convenience of a shared secret hides a dangerous concentration of power: the same identity that extracts logs can also execute destructive commands, and there is no built‑in checkpoint that forces a second set of eyes before a write occurs.
Because the loop runs end‑to‑end, every request reaches the target system directly. Engineers see only the final success or failure; the platform logs who ran the script, but they do not capture which exact SQL statement changed a row, which API call altered a Kubernetes object, or whether a secret was exposed in a response. The result is a blind spot that makes it hard to prove compliance, to investigate incidents, and to enforce the principle of least privilege.
Segregation of duties (SoD) asks that no single identity be allowed to both request and approve a privileged action. In practice, this means splitting the "who can read" and "who can write" responsibilities, inserting an approval step for write‑heavy commands, and recording every interaction for later review. The missing piece is a control surface that sits on the actual data path, where the request can be inspected, masked, or blocked before it reaches the backend.
hoop.dev provides that control surface. It acts as an identity‑aware gateway that sits between agents and the infrastructure they target. The gateway authenticates users via OIDC or SAML, then enforces SoD policies on each protocol‑level request. Because hoop.dev intercepts traffic at Layer 7, it can apply just‑in‑time approvals, inline masking, command blocking, and session recording before any data leaves the gateway.
How segregation of duties works with hoop.dev
The enforcement flow consists of three distinct layers:
- Setup: Identity providers (Okta, Azure AD, Google Workspace, etc.) issue tokens that identify the caller and convey group membership. Service accounts are provisioned with the minimum set of permissions required for read‑only operations. This stage decides who may start a session, but it does not enforce any guardrails.
- The data path: hoop.dev sits in the data path as a proxy for the target system, whether a PostgreSQL database, a Kubernetes API server, or an SSH host. All traffic from the agent must pass through the gateway, giving hoop.dev the sole point where policy can be applied.
- Enforcement outcomes: Because hoop.dev controls the data path, it can record every command, mask sensitive fields in responses, require a human approval before any write‑type command is executed, and block disallowed operations outright. The recorded session can be replayed later for audit or forensic analysis.
With this architecture, a read‑only service account can be granted access to query data, while any attempt to issue a DML statement, a privileged kubectl command, or a file‑write over SSH is intercepted. hoop.dev then routes the request to an approval workflow, typically a Slack or email notification to a designated reviewer. Only after the reviewer approves does hoop.dev forward the command to the backend. If the request is denied, the gateway returns an error to the caller and logs the denial.