Segregation of Duties for Subagents

When a subagent with unchecked privileges runs a destructive command, the organization can lose data, face regulatory penalties, and spend weeks on remediation. The root cause is often a lack of segregation of duties: a single automation identity can both request and approve privileged actions, blurring accountability and opening the door to abuse.

Most teams treat subagents like any other service account. A shared secret is baked into CI pipelines, a static token is checked into source control, and the same identity is used for deployment, configuration changes, and data extraction. Because the credential is static, any engineer who can read the repository can invoke the subagent directly, bypassing any human review. The result is a flat permission model where the subagent can perform any operation it can reach, and there is no reliable record of who triggered which action.

This reality violates the principle of segregation of duties. The goal is to separate the responsibility for requesting a privileged operation from the responsibility for approving it. In a well‑designed system, a developer can ask for a database schema change, but an independent reviewer must explicitly grant permission before the subagent executes the change. The same pattern applies to secret rotation, firewall rule updates, or bulk data exports. Without a dedicated enforcement point, the request still travels straight to the target service, and the organization loses visibility into the decision‑making process.

Why subagents need clear duty boundaries

Subagents are often embedded in CI/CD runners, monitoring bots, or AI‑driven assistants. They act on behalf of humans, yet they inherit the same level of trust as a human operator. When duty separation is missing, a compromised CI runner can both request and carry out a destructive command without any checks. The cost is not only the immediate impact on the system but also the downstream effort required to prove who was responsible, which can stall audits and breach compliance timelines.

Segregation of duties also helps limit the blast radius of a compromised credential. By forcing a second party to approve high‑risk actions, the organization creates a window for detection and response. The approval step can be tied to a logging system that records the request, the approver, and the outcome, providing an immutable audit trail for investigators.

The missing enforcement gap

Even when an organization defines policies that require separate request and approval steps, the enforcement often lives in the orchestration layer, not in the data path. The request may be logged in a ticketing system, but the subagent still connects directly to the database, Kubernetes API, or SSH host. Because the gateway is absent, the subagent can bypass the approval check, and there is no guarantee that the command was recorded or that sensitive fields were masked.

In practice this means that the setup can satisfy the policy on paper while the technical reality remains insecure. The request reaches the target service unchanged, the command executes, and no real‑time guardrails intervene. If the subagent is compromised, the attacker inherits the full set of privileges without any chance for a just‑in‑time block or a replayable session record.

hoop.dev as the enforcement point

hoop.dev provides the data‑path gateway that every subagent must traverse. By placing the gateway between the subagent identity and the target resource, hoop.dev becomes the only place where segregation of duties can be enforced. The gateway validates the request, checks whether an approval exists, and only then forwards the command to the backend service.

When a subagent initiates a connection, hoop.dev extracts the caller’s OIDC token, evaluates the requested operation against the policy, and decides one of three outcomes:

• Approve and forward: The request has a valid approval, so hoop.dev relays it to the target.
• Require approval: The request is high‑risk; hoop.dev pauses the flow and notifies a designated reviewer. Once approved, the gateway resumes the session.
• Block: The request violates policy (for example, attempts to drop a production database). hoop.dev stops the command and records the denial.

Because hoop.dev sits in the wire‑protocol layer, it can also mask sensitive fields in responses, ensuring that downstream logs never expose secrets. Every session is recorded, enabling replay for forensic analysis and providing the audit evidence needed for regulators. The enforcement outcomes, approval gating, command blocking, inline masking, and session recording, exist only because hoop.dev occupies the data path.

To get started, follow the getting‑started guide and configure a subagent connection in the portal. The documentation explains how to define duty‑separation policies, assign approvers, and enable session capture. For deeper policy language details, explore the learn section of the site.

How hoop.dev enforces segregation of duties

Setup begins with identity provisioning. Each subagent receives a distinct service account that is federated through OIDC. The gateway uses the token to map the subagent to a logical role. The role defines what actions the subagent may request, but not whether it may execute them without oversight.

The data path, hoop.dev, intercepts every protocol message. For a database query, the gateway parses the SQL, checks the policy, and either forwards, queues for approval, or aborts. For a Kubernetes exec, hoop.dev inspects the command string, applies the same decision logic, and records the entire terminal session. Because the gateway holds the credential, the subagent never sees the underlying password or certificate, eliminating credential leakage.

When an approval is required, hoop.dev integrates with common notification channels (email, Slack, or ticketing systems) to surface the request to the designated reviewer. The reviewer’s decision is logged alongside the original request, creating a reliable, immutable audit trail. If the reviewer denies the request, hoop.dev returns a clear error to the subagent and records the denial for audit.

FAQ

Can I use hoop.dev with existing CI pipelines? Yes. hoop.dev works with any client that can speak the target protocol (psql, kubectl, ssh, etc.). You only need to point the pipeline at the gateway endpoint and grant the pipeline’s service account the appropriate OIDC scope.

Does hoop.dev store credentials? The gateway holds the credential in memory for the duration of a session. It never writes the secret to disk and never exposes it to the subagent, ensuring that credential leakage is avoided.

What audit evidence does hoop.dev provide? Each session is recorded in an immutable log that includes the requester identity, the approval decision, the exact commands executed, and any masked fields. This log satisfies the evidence requirements for most regulatory frameworks.

Ready to add segregation of duties to your subagents? View the open‑source repository on GitHub and start building a more accountable automation layer today.