Automating Separation of Duties
Automating separation of duties splits high-risk tasks across two or more people using system rules. One engineer writes a change or query, and a second person approves it before it runs. Teams often start by setting up static identity roles in their cloud accounts. They give developers read rights and give operations staff write rights. Over time, emergencies happen and engineers ask for broader permissions to fix urgent bugs. Static roles stay broad after the fix, which breaks the two-person
DPoP (Demonstration of Proof-of-Possession): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Automating separation of duties splits high-risk tasks across two or more people using system rules. One engineer writes a change or query, and a second person approves it before it runs.
Teams often start by setting up static identity roles in their cloud accounts. They give developers read rights and give operations staff write rights. Over time, emergencies happen and engineers ask for broader permissions to fix urgent bugs. Static roles stay broad after the fix, which breaks the two-person rule in production.
How automating separation of duties works in identity tools
To build this workflow, teams link their identity directory to a ticketing or chat tool. First, you map out which tasks carry high risk in your production accounts. Writing code, approving code, and running database updates must sit in separate roles. No single user account should hold the rights to do all three tasks alone.
Next, you set up rule checks in your code pipeline and identity tool. When an engineer pushes code, the pipeline checks who wrote the change. The system blocks the writer from clicking the approve button on their own request. A second peer from the right team must log in and approve the step.
The same pattern applies when someone needs to run a production task. An engineer sends a request through a chat app or ticket form. The workflow tool checks if the requester and the approver are different people. It also checks if the approver holds the right role for that database or server. Once approved, the identity tool grants temporary role permissions for a set window of time. When the timer ends, the system drops the role rights and writes an audit log.
What role setup solves and where the gap remains
Identity role workflows solve the problem of standing admin rights across your team. Auditors can read the ticket logs to see who asked for permissions and who approved them. This stops one person from pushing unreviewed code or logging into a database unseen.
DPoP (Demonstration of Proof-of-Possession): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, role workflows only check who can log in to a target system. Once the identity tool grants the role, the engineer gets a full session. The native role cannot check each individual command or query while it runs in flight. An approved user with write rights can still run a bad update by mistake. Also, a user with read rights can query tables that hold raw customer records. The role setup does not rewrite emails, phone numbers, or card numbers in query results. True separation requires checking both the login request and the live commands inside the session.
Building command-level peer review for live sessions
To close this gap, teams move approvals down to the command and query level. Instead of approving a broad four-hour role, peers review the exact action before it runs. The engineer submits the specific SQL statement or script they need to run in production. The peer reads the exact text of the command and approves only that task.
This approach keeps engineers moving fast while keeping strict rules in place for sensitive data. Routine read queries can run right away while high-risk write commands wait for a peer check. At the same time, data rules can rewrite national IDs or card numbers in the output. You get clean audit logs that show both the peer approval and the exact command run.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the main goal of separation of duties?
The main goal is to stop one person from making unchecked changes in critical systems. Splitting tasks between two people reduces fraud and catches human errors before they cause outages.
How do small teams handle two-person rules during on-call shifts?
Small teams automate routine read tasks so on-call staff can check logs right away. They only require a second person to approve destructive write commands or sensitive data reads.
Why are static database roles not enough for separation of duties?
Static roles only control who can log in and which tables they can touch. They do not inspect live queries, block bad updates, or mask card numbers in results.