All posts

Segregation of Duties for Agentic AI: A Practical Guide

When an autonomous model can execute privileged commands without a human check, the organization pays the price in data loss, compliance gaps, and costly remediation. Unchecked actions ripple through production databases, cloud clusters, and internal services, turning a clever automation into a liability. Without segregation of duties, the model can both request and execute high‑risk changes without any human oversight. Many teams hand an agentic AI the same static credentials that engineers u

Free White Paper

DPoP (Demonstration of Proof-of-Possession) + AI Agent Security: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

When an autonomous model can execute privileged commands without a human check, the organization pays the price in data loss, compliance gaps, and costly remediation. Unchecked actions ripple through production databases, cloud clusters, and internal services, turning a clever automation into a liability.

Without segregation of duties, the model can both request and execute high‑risk changes without any human oversight.

Many teams hand an agentic AI the same static credentials that engineers use for day‑to‑day work. The model connects directly to a PostgreSQL instance, an SSH host, or a Kubernetes API, and runs with the full breadth of those permissions. There is no record of which query was generated by the model, no way to hide credit‑card numbers that appear in a response, and no gate that forces a human to approve a destructive operation. The result is a black box that can read, write, and delete exactly as any privileged user could.

Why segregation of duties matters for agentic AI

Segregation of duties (SoD) is a control principle that separates critical functions so that no single identity can both request and approve a high‑risk action. In the context of AI‑driven automation, SoD prevents the model from becoming the sole decision‑maker for privileged work. Without SoD, an AI that can both generate a change request and execute it defeats the purpose of any approval workflow.

The precondition we must address is simple: the system must be able to recognize the AI’s identity, enforce a policy that limits the AI to a defined subset of duties, and still allow the request to travel to the target infrastructure. At this stage the request still reaches the database or the SSH host directly, and there is no audit trail, no masking of sensitive fields, and no human approval step for risky commands.

Placing the enforcement point in the data path

hoop.dev provides the missing enforcement layer. It sits as a Layer 7 gateway between the AI client and the underlying resource. The gateway is the only place where traffic can be inspected, altered, or blocked before it reaches the target.

Setup – Identity is established through OIDC or SAML. The AI obtains a token from the organization’s identity provider, and hoop.dev validates that token and extracts group membership. This step decides who the request is and whether it may start, but it does not enforce any duty separation on its own.

Continue reading? Get the full guide.

DPoP (Demonstration of Proof-of-Possession) + AI Agent Security: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

The data path – All connections flow through hoop.dev. Because the gateway terminates the protocol, it can examine each command, query, or SSH instruction in real time.

Enforcement outcomes – hoop.dev records every session for replay, masks sensitive fields in responses, and can pause a command that matches a high‑risk pattern. For actions that require dual control, hoop.dev routes the request to a human approver before forwarding it. The model never sees the underlying credential; hoop.dev holds the credential and presents a short‑lived, scoped token to the target.

Applying SoD to an autonomous model

  • Define duty boundaries. Create identity groups such as ai-readonly and ai‑admin‑requester. Assign the AI’s service account to the read‑only group for routine queries.
  • Require just‑in‑time approval for privileged actions. When the model attempts a DDL statement, a data‑modifying operation, or an SSH command that alters system configuration, hoop.dev triggers an approval workflow. A designated operator must approve before the command is sent.
  • Mask sensitive data in responses. If the AI queries a table that contains personally identifiable information, hoop.dev redacts those columns before the result reaches the model, ensuring that downstream prompts cannot leak data.
  • Record and replay. Every interaction is logged with the AI’s identity, the exact command, and the approval decision. Auditors can replay the session to verify that duties were properly separated.

By forcing the AI to operate through hoop.dev, the organization gains a single control surface that enforces SoD without having to embed policy checks into the model’s code. The gateway’s placement guarantees that no privileged command can bypass the approval step, because the only path to the resource is through hoop.dev.

Benefits of a gateway‑centric SoD model

Because enforcement lives in the data path, the organization enjoys several concrete advantages:

  • Reduced blast radius. If the AI is compromised, the attacker inherits only the duties assigned to the AI’s identity. Any attempt to exceed those duties is stopped by hoop.dev.
  • Clear audit trail. Every command, approval, and masking decision is stored centrally, making it trivial to answer “who did what and when?” during a compliance review.
  • Dynamic policy changes. Adjusting duty groups or approval thresholds takes effect immediately because the gateway re‑evaluates each request in real time.
  • Zero credential exposure. The AI never sees the underlying service account password or cloud IAM key; hoop.dev presents a short‑lived, scoped credential only for the allowed operation.

These outcomes exist only because hoop.dev occupies the data path. Removing the gateway would return the environment to the original state where the AI holds unrestricted credentials and no audit exists.

Getting started

Begin with the getting‑started guide to deploy the gateway in your network. Define identity groups for your AI workloads, configure the approval workflow, and enable inline masking for any fields that contain sensitive information. The full feature list and configuration details are available in the learn section.

FAQ

Does hoop.dev replace my existing IAM policies?

No. IAM still decides which identities can obtain a token. hoop.dev adds a second, mandatory control layer that enforces segregation of duties on every request that reaches the resource.

Can I use hoop.dev with any AI model?

Yes. As long as the model can present an OIDC or SAML token, hoop.dev can validate the identity and apply the SoD policies you define.

What happens if an approval is delayed?

The request remains pending in the gateway until a human approves or rejects it. This prevents the AI from proceeding with a high‑risk action without explicit consent.

Ready to protect your autonomous workloads with an open‑source gateway? Explore the hoop.dev repository on GitHub and start building a segregation‑of‑duties control plane today.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts