Segregation of Duties for Agent Runtimes

Segregation of duties breaks down when an agent runtime runs with a single, overly‑privileged credential, a breach can spread from one service to every internal system, inflating remediation costs and extending downtime.

In many organizations the reality is even harsher. Teams hand out static service‑account tokens, embed them in CI pipelines, and let the same runtime process both request creation and execution. The token often has admin‑level rights across databases, Kubernetes clusters, and SSH hosts. No one records which user triggered a particular command, and no guardrails stop a dangerous query from reaching production. The result is a black box where responsibility is impossible to assign and risk is amplified.

Even after moving to identity‑based authentication, the core problem remains. The setup may now issue short‑lived OIDC tokens and assign minimal IAM roles, but the agent runtime still talks directly to the target system. There is no point in the traffic flow where policy can be examined, where a request can be approved, or where sensitive fields can be masked. The request reaches the database or the Kubernetes API unchecked, leaving the same exposure to insider misuse or compromised automation.

Why segregation of duties matters for agent runtimes

Segregation of duties is a control that separates the authority to request access from the authority to execute privileged actions. Applied to agent runtimes, it means that a developer can ask for a connection, but a separate policy engine decides whether the request is allowed, whether it needs approval, and what it can do once the connection is open. This split reduces the blast radius of a compromised credential, provides clear audit trails, and satisfies auditors who look for evidence that no single identity can both request and consume high‑risk privileges.

To achieve true segregation, three layers are required:

• Setup: Identity providers (OIDC/SAML) issue tokens that identify the caller and carry group membership. Service accounts and least‑privilege roles define what a token *could* do.
• The data path: A gateway sits between the caller and the target, inspecting every wire‑protocol message.
• Enforcement outcomes: The gateway records each session, masks sensitive response fields, blocks prohibited commands, and can pause a request for human approval.

If any of these layers is missing, segregation of duties collapses. The setup alone cannot stop a malicious query, and without a data‑path gateway there is nowhere to enforce the policy.

How hoop.dev enforces segregation of duties

hoop.dev implements the data‑path layer that makes segregation of duties enforceable for agent runtimes. It acts as an identity‑aware proxy that terminates the client connection, validates the caller’s OIDC token, and then forwards the request to the target only after applying policy checks.

Because hoop.dev is in the traffic flow, it can:

• Record every command and response, creating a replayable audit log that attributes actions to the original identity.
• Mask sensitive columns or fields in database results, ensuring that even privileged users only see what their policy permits.
• Require just‑in‑time approval for high‑risk operations, pausing the request until an authorized reviewer grants access.
• Block commands that match a deny list, preventing destructive actions before they reach the backend.

All of these outcomes exist only because hoop.dev occupies the data path. If the gateway were removed, the same OIDC token would flow straight to the database or Kubernetes API with no inspection, and the segregation of duties guarantees would disappear.

Putting the pieces together

The practical deployment looks like this:

1. Configure your identity provider (Okta, Azure AD, Google Workspace, etc.) to issue short‑lived tokens for engineers and automation.
2. Define least‑privilege roles for each target system – for example, read‑only access to a reporting database and exec‑only rights on a Kubernetes namespace.
3. Deploy hoop.dev as a Docker Compose stack or in Kubernetes near the resources you want to protect. The agent runs inside your network and holds the credentials that the target expects.
4. Register each resource in hoop.dev, attaching the appropriate role and any masking or approval policies.
5. Users connect with their normal client tools (psql, kubectl, ssh) but point them at the hoop.dev endpoint. The gateway enforces segregation of duties before the traffic reaches the backend.

For a step‑by‑step walkthrough, see the getting started guide. The broader feature set, including masking rules and approval workflows, is documented on the learn page.

FAQ

Does hoop.dev replace existing IAM policies?

No. IAM or role‑based policies still define what a token *could* do. hoop.dev adds a runtime guard that decides *whether* and *how* those capabilities are exercised for each request.

Can I use hoop.dev with existing CI pipelines?

Yes. CI jobs can obtain short‑lived OIDC tokens and call the gateway just like a human user. The same segregation of duties checks apply, so a compromised CI token cannot automatically run destructive commands without approval.

What happens to logs after a session ends?

hoop.dev stores session records in a configurable backend. The logs include the identity, timestamps, commands, and any masked results, providing the evidence needed for audits and post‑incident investigations.

Ready to see the code and contribute? Explore the repository on GitHub and start building a more accountable runtime environment.