What does separation of duties mean for autonomous systems?

An old idea, applied to a new actor

Separation of duties is a long-standing control in finance and accounting: the person who initiates a payment should not also be the person who approves it, because combining the two removes the check the whole control exists for. The failure mode it prevents (self-dealing, or an unchecked actor with too much combined authority) is exactly the failure mode an AI agent with write access and no independent approver reintroduces, just with a different kind of actor.

The rules, stated concretely

Four rules do most of the work in a system built around this principle.

• A proposer cannot approve their own proposal, whether the proposer is a human or an agent acting under a human's identity.
• The platform-engineer role can execute approved changes but cannot approve them; other authorized roles may hold both permissions.
• Whoever holds the permission to edit policy holds no propose, execute, or approve permission themselves, so the person who can change the rules cannot also act under a favorable version of them.
• An audit or view-only role carries no effect-bearing permission at all; it can see everything and change nothing.

Why role-based access control is not enough by itself

RBAC answers who can do a given thing. Separation of duties answers a different question: which two things must never be permitted to the same identity at once. A role may include both proposal and approval permissions while the system still prevents a person from approving their own proposal. The failure is allowing the same proposing principal to approve that action, regardless of which role they use. The enforcement point matters as much as the rule: if the restriction lives only in a UI that happens to hide the approve button for certain roles, and the same action is reachable through an API with no equivalent check, the rule is not actually enforced.

Where the field is thin, and where it is further along

One services-led platform names executive personas with what it describes as role-aware access controls, but a granular, publicly inspectable permission matrix is not published as of this writing. ServiceNow's Autonomous Workforce promises role-scoped permissions under its AI Control Tower, and PagerDuty gives its SRE Agent per-agent permissions with an explicit choice to act on a recommendation or wait for approval, both of which are steps toward the same discipline without a fully published matrix behind them yet.

Cleric, one of the agentic-SRE startups, is explicit that it defaults to read-only and escalates to write access only when a team is ready for it, which is close in spirit to the graduated-trust model this page describes, applied to when an agent earns broader authority rather than only to who approves a given action.

What to test in a demo

In a separately authorized evaluation, try to have the proposing identity approve the same action through the interface and API. The system should refuse both attempts and retain the refusal receipt. HELM by LockedIn Labs exposes seven role definitions, twenty-four permissions and four separation-of-duties rules in Access. Its read-only role and ledger previews explain those rules; they do not submit a real governed action or grant a guest its selected role. Testing the server refusal requires an authorized evaluator action.

What happens when the rule is only a policy document

A separation-of-duties rule that exists only in a written policy, with no system-level check, tends to survive right up until it is inconvenient. A common failure pattern looks reasonable on paper: an operations lead is trusted to both propose an emergency change and approve it themselves during an outage, because waiting for a second approver felt too slow in the moment. Each individual exception is defensible; the pattern across many exceptions is exactly the unchecked combined authority the control exists to prevent, and it tends to surface only after something goes wrong, at which point the audit trail shows a policy that was never actually enforced.

This is why the enforcement point matters more than the written rule. A system that makes the disallowed combination structurally unavailable, rather than merely discouraged, does not depend on anyone remembering the policy under pressure, which is precisely the condition an incident creates.

The same reasoning applies with more force once an agent, not a human, is the one proposing the emergency change. A human operator under pressure might remember to call a second person; an agent has no such instinct unless the system itself refuses to let it proceed without one, which is the entire argument for enforcing this at the platform level rather than trusting good judgment in the moment, human or artificial.