Separation of Duties for AI Agents: Who Proposes, Who Authorizes, Who Is Accountable

SoD is usually taught as two roles, maker and checker, the "four-eyes" principle. Agent systems force a third role into the open, because automation makes it easy to lose track of who is answerable when something goes wrong. The clean model has three distinct seats:

The failure mode is collapsing any two of these into one actor. The most dangerous collapse is proposer-equals-authorizer: an agent that applies its own change. The quietest and most common collapse is authorizer-equals-accountable disappearing entirely, where automation runs and no human can say who owns the result. For an insurer, where a mispriced endorsement or a broken claims rule has direct policyholder and solvency consequences, the accountable seat can never be vacant or assigned to a system.

The classic argument for SoD is collusion and fraud. The agent-era argument is narrower and harder to wave away: the proposer's judgment about its own work is not independent evidence. An agent that generated a change and then certifies it passed validation is grading its own exam with an answer key it wrote.

The industry data makes this concrete rather than theoretical. Roughly 41% of codebases are now AI-generated, and around 45% of AI coding tasks introduce a critical flaw or security issue. The cost of poor software quality already sits near $2.41 trillion. You are not weighing whether to admit capable-but-fallible actors into your pipeline. They are already there, producing a defect rate you cannot prompt away. A better model lowers that rate; it does not give you a control. You cannot audit a probability, and you cannot let the thing that might be wrong be the thing that decides it was right.

There is also a security dimension specific to agents that SoD never had to handle for humans. A compromised or manipulated agent can produce a confident, well-formatted proposal complete with plausible-looking evidence. If the authorizing function trusts artifacts the proposer generated, a single compromised proposer defeats the whole control. That is why the checker must validate against an independent source of truth, not against the proposer's own claims.

A checker that only reads what the maker handed it is theater. Real separation requires the authorizing path to derive its facts from somewhere the proposer cannot author.

This is where a live System Graph becomes a control, not a convenience. Because it maps services, dependencies, and CI/CD into one change-aware model, the authorizing function can independently answer the question that actually governs risk: what does this change reach? A change to a quoting service that fans out to the binding path is a different risk class than the same diff on an internal reporting job, and the graph establishes that without trusting the proposer's self-description of blast radius.

Validation has to be independent in the same way. Coordinated Testing Fleets plan and execute validation that is aware of what changed and what depends on it, then emit the evidence the gate reads, which paths were exercised, what regressed, what reachability analysis says about exposure. That last signal matters for security authorization specifically: reachability-based prioritization, asking whether a flaw sits on a path that is actually reachable in your deployed system, can mean 70 to 90% less exploitable exposure to triage. The authorizer routes a reachable defect to a human and lets an unreachable one through on policy. Either way, the decision rests on evidence the proposer did not manufacture.

The principle underneath is the one your auditors already recognize: agents propose, humans authorize. The control layer can map, validate, and stage the change. It does not get to authorize the dangerous ones on its own behalf. Governance, policy, approval, and audit, is the engineering, not a wrapper added after the agent ships.

Authorization decides whether a change proceeds. Accountability decides who answers for it afterward. Insurers learn the hard way that these are not the same when an examiner asks who approved a rule that underpaid a class of claims, and the honest answer is "an automation pushed it and no one is named."

Accountability has to be encoded as policy, not left to org-chart inference:

That last point is where most programs fail. Roughly 80% of developers admit to bypassing policy or guardrails when they add friction. A separation of duties that lives in a wiki or a change-advisory meeting gets routed around at exactly the moment it matters. The control has to be a property of the system, where it cannot be skipped, with the audit trail as a byproduct of how the pipeline runs.

For workloads that cannot leave your perimeter, and in insurance, policyholder and claims data rarely can, the authority model has to hold inside your boundary. Edge Runners execute as signed capsules inside a secure enclave and emit audit-ready evidence outward, so residency and separation of duties stop being a tradeoff. The data stays; the proof leaves.

A note on the hardest case: remediation. Letting agents fix code unsupervised is reckless precisely because it is the step where proposing and authorizing are most tempting to merge. Governed Remediation Fleets stage the fix and the evidence but never self-authorize a change to a regulated or revenue-critical path.

You do not need a platform rebuild to restore separation. Start with mapping, then enforcement.