When an AI coding agent can push code straight to production without any human checkpoint, a single mis‑generated query can corrupt databases, expose secrets, and trigger costly incident responses. The financial impact of a rogue change often dwarfs the convenience gained from full automation, and regulators increasingly expect clear separation of responsibilities. That is why segregation of duties matters even for machine‑driven developers.
Current practice: agents with unchecked power
Many teams treat an AI coding assistant as just another library. The agent runs inside a CI pipeline, authenticates with a static service account, and talks directly to the target system, whether a PostgreSQL instance, a Kubernetes cluster, or an SSH host. The service account typically has broad write privileges, and the pipeline does not require a human to approve the final step. As a result, the organization loses visibility into who (or what) actually performed each operation, and there is no barrier to prevent a dangerous command from being executed.
What segregation of duties aims to fix
Segregation of duties requires that no single identity, human or non‑human, can both create a change and deploy it without independent verification. In practice this means splitting the responsibilities of code generation, approval, and execution across distinct entities. The AI agent should be allowed to generate code, but a separate policy decision must decide whether that code is safe to run. Even after the decision, the system must retain a reliable record of the execution for audit and forensics.
Implementing this split without a dedicated control point leaves a gap: the request still reaches the database or cluster directly, bypassing any real‑time check, audit, or data‑masking step. The setup, service accounts, OIDC tokens, role bindings, identifies the caller, but it does not enforce the policy that the caller must be vetted before the command touches the target.
Introducing hoop.dev as the enforcement layer
hoop.dev is a Layer 7 gateway that sits between the AI coding agent and the infrastructure it talks to. By placing the gateway on the data path, hoop.dev becomes the only place where policy can be evaluated before traffic reaches the target system. The gateway validates the agent’s OIDC token, reads group membership, and then applies the segregation‑of‑duties rules that your organization defines.
hoop.dev records every session, so you always have a replayable audit trail that shows exactly which AI‑generated command was executed, when, and by which identity. It can mask sensitive fields in query results, preventing the agent from seeing secrets that it does not need. If a command matches a risky pattern, hoop.dev blocks it outright or routes it to a human approver for real‑time review. All of these enforcement outcomes exist only because hoop.dev sits in the data path.
How the architecture satisfies segregation of duties
The first step, identity provisioning, remains a setup concern. You create a service account for the AI agent, bind it to a minimal role, and configure OIDC authentication. That step decides who the request is, but it does not guarantee that the request is safe. The next step is the gateway itself. hoop.dev receives the request, checks the policy, and either forwards it, masks the response, or asks for approval. Because the gateway is the only place the traffic passes, you cannot bypass the policy without breaking the connection.
When an approval is required, a human reviewer sees the exact command the agent wants to run, along with context such as the target database and the requesting pipeline. The reviewer can approve, deny, or modify the request. Once approved, hoop.dev forwards the command, records the decision, and continues to record the session. This flow enforces a clear separation between code generation (the AI) and code execution (the approved, recorded action), which is the essence of segregation of duties.
Practical steps to get started
Begin by defining the segregation‑of‑duties policy for each target system. Identify which commands need approval, which fields should be masked, and the retention period for session logs. Then deploy hoop.dev using the getting started guide. Register each resource, PostgreSQL, Kubernetes, SSH, as a connection in the gateway, and point your CI pipelines to the hoop.dev endpoint instead of the raw target. Finally, enable the built‑in approval workflow and session recording features; you can read more about those capabilities in the learn section.
FAQ
- What if the AI agent needs to read secret values? hoop.dev can mask those fields in the response, so the agent never sees the raw secret while still being able to continue its workflow.
- Does hoop.dev add latency to the connection? Because it operates at the protocol layer, the overhead is minimal and is outweighed by the security benefits of real‑time policy enforcement.
- Can I still use existing CI tools? Yes. The gateway presents the same network endpoint and protocol as the original target, so existing tools work unchanged.
By routing AI‑generated traffic through a dedicated gateway, you enforce segregation of duties without rewriting your pipelines or sacrificing developer velocity.
Explore the source code and contribute on GitHub.
