The Security Principle of Separation of Duties
You apply the security principle of separation of duties by splitting tasks between two people. One person requests or writes a change, and another person approves or runs it. Many teams start by giving every senior engineer broad admin roles to move fast. Broad roles let one person make a bad change or hide a mistake alone. When one account holds every permission, a stolen key puts the whole system at risk. How the security principle of separation of duties works This rule stops any single p
DPoP (Demonstration of Proof-of-Possession) + Least Privilege Principle: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You apply the security principle of separation of duties by splitting tasks between two people. One person requests or writes a change, and another person approves or runs it. Many teams start by giving every senior engineer broad admin roles to move fast. Broad roles let one person make a bad change or hide a mistake alone. When one account holds every permission, a stolen key puts the whole system at risk.
How the security principle of separation of duties works
This rule stops any single person from controlling a full task from start to finish. In finance, the person who writes a check cannot sign that same check. In software teams, the developer who writes code should not push it to production alone. A second engineer must check the code and approve the merge first.
Teams set up this split through identity groups and database roles. You create one role for building apps and another role for running live systems. Cloud admins map these roles to separate teams in the identity provider. Database admins also split read roles, write roles, and schema admin roles.
Good role design follows a clear four-step flow. First, list every high-risk task in your system, like dropping tables or reading keys. Second, split each big task into a request step and an approval step. Third, assign those steps to different job roles in your identity system. Fourth, check your system logs each month to catch anyone holding both roles.
Where native role splits fall short in daily work
Native cloud and database roles solve the problem of who can log in. They block a builder from logging into a production server with an admin key. This setup works well for steady, predictable tasks during normal work hours.
Still, static roles leave a big gap during live fixes and daily database work. Once an approved engineer logs in with a write role, the system trusts every command. Native roles decide who logs in, not what each command or query does in flight. An admin who logs in to fix one row can still drop a whole table.
DPoP (Demonstration of Proof-of-Possession) + Least Privilege Principle: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static roles also break down when a small team faces a late-night outage. If the only approver is asleep, the on-call engineer cannot fix the broken app. Teams often work around this by sharing admin keys or granting permanent broad roles. Shared keys ruin your audit logs because you cannot see who ran which command.
How to enforce duty splits at the command level
To fix this gap, move your approval step from the login screen to the action. Let engineers log in with low-risk read roles for their daily checks. When someone needs to run a write query, require a peer to approve that command.
You should also add data masking to your read roles. Masking rewrites matched fields in results, such as emails, phone numbers, and card numbers. This lets builders check live app bugs without reading raw customer data. By pairing action approvals with masking, you keep duties split even in small teams.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How does separation of duties differ from least privilege?
Least privilege gives one user the smallest set of permissions needed for a job. Separation of duties splits a critical task so two users must work together.
How can small teams split duties without blocking down work?
Small teams can require peer reviews only for high-risk production write commands. Low-risk read queries can run right away with masking turned on for sensitive fields.
What happens to duty splits during an urgent outage?
Teams use an emergency break-glass flow that grants temporary access for a short time. Every command run during that window goes to a security team for review afterward.