Segregation of duties survives contact with agents, barely

I am not a lawyer, this is not legal advice, and nothing here should be treated as an assessment of your obligations. What follows is a control design argument.

Segregation of duties is one of the oldest controls in the book, and one of the few that has come through the last two years still meaning something. It survives. But it survives in a state most teams have not noticed, because the way nearly everyone implements it stopped testing the thing it was designed to test.

The implementation is: the author of a change cannot be its approver, enforced by comparing two identities in the source control system. Branch protection does this, it does it reliably, and it goes green.

My position: identity-based segregation of duties is now close to meaningless under agentic delivery, because a single human can occupy every role in the sequence while the usernames all differ. The control is salvageable, but only by re-anchoring it on authority: who stated the criteria, who produced the change, and who attested that it meets them. Those are three separable acts. Two usernames are not.

What the control was actually for

Segregation of duties exists to stop one party from both creating a risk and certifying it away. That is the whole idea. Everything else is implementation.

The identity check was a proxy. It worked because in a human process, “a different person approved it” reliably implied “a second, independent judgement was applied”. The proxy held because forming that judgement was the expensive part, and only a human could do it.

Now consider the ordinary agentic sequence. An engineer writes a prompt from a two-line ticket. An agent, running under a service account, produces the implementation and the tests. The engineer reads the summary, decides it looks right, and approves. Branch protection compares svc-agent-prod against p.nolan and passes.

One person exercised judgement, once, about work they specified. The control reported success. Nothing was segregated.

Identity-anchored (what most pipelines enforce)

• Test: author identity differs from approver identity
• Passes when a human specifies, an agent builds, the same human approves
• Service account counts as a distinct party
• Green regardless of whether judgement was applied
• Auditable, cheap, and now largely uninformative

Authority-anchored (what the control was for)

• Test: the party who stated the criteria is not the party who attests they are met
• Fails when specification and attestation collapse into one person
• An agent is an instrument of a party, never a party
• Requires a recorded criterion to attest against
• Harder to implement, actually tests the thing

Three acts, and which two must not merge

Under agentic delivery the sequence has three distinct acts, and it is worth naming them precisely because most process documents blur them.

Stating the criteria. Someone decides what “done” means for this change: the behaviour, the constraints, the things that must not break. This is an act of authority whether or not anyone writes it down.

Producing the change. Someone or something turns those criteria into a diff. This is increasingly done by an agent, and it is the act with the least judgement in it.

Attesting the change meets the criteria. Someone forms and records a view that the diff satisfies what was stated. This is where the risk is certified away, and it is the act the control exists to protect.

The separation that matters is between the first and the third. If the same person states what done means and then attests it was achieved, they have marked their own homework, no matter how many usernames appear in the commit trail. The second act is the one everybody is watching, and it is the least important of the three.

That reframing has a practical consequence. If you have no recorded criterion, you cannot separate the first act from the third, because there is nothing to attest against. Attestation without a stated criterion is just someone saying it looked fine. That is not a control, and no amount of branch protection turns it into one.

Do not give the agent a human-shaped identity

A specific, avoidable mistake: issuing agents identities that are indistinguishable from human ones in the audit trail, or worse, having them commit under the identity of the engineer who invoked them.

Both are common. Both are understandable, because tooling defaults push you there and because it makes the commit history read cleanly. Both destroy your ability to answer the question that matters six months later, which is not “who typed this” but “who is accountable for this being correct”.

Agent commits as the invoking engineerWorst case. The record asserts a human authored something no human read. Unrecoverable after the fact.

Agent commits as a generic shared service accountCommon. Tells you it was generated, tells you nothing about which party directed it.

Agent identity plus recorded principalWorkable. The record shows the instrument and the human on whose authority it acted.

The above, plus the criterion it was working toWhat you want. Now the attestation has something to be an attestation of.

An agent is not a party to a control. It is an instrument, in the same sense that a deployment script is an instrument. Nobody would accept “the deploy script approved it” as segregation of duties, and the fact that this instrument writes prose should not change the analysis.

Where the traceability requirement bites

There is a regulatory dimension worth flagging carefully, without overstating it.

EU AI Act enforcement began on 2 August 2026. Article 12 requires automatic logging of events relevant to identifying risk and ensuring traceability, with logs that are tamper-evident and retained for at least six months, twenty-four for biometric and law-enforcement uses. Whether that applies to your systems depends on classification questions that are legal work, not engineering work, and you should get proper counsel rather than a view from an article.

The relevant point for this argument is narrower. If your traceability records show that a change was authored by a service account and approved by a human, and no criterion was recorded anywhere, then the record documents a sequence of events without documenting that any control operated. That is a weak position independent of any particular regulation, and it is a weak position in front of a customer’s security questionnaire, an incident review, or an insurer.

No tool makes anyone compliant with anything, ours included. What a tool can do is make the record complete enough that someone qualified can assess it.

Where this breaks down

Rigorous separation slows down small teams to no benefit. A four-person startup where everyone knows the domain and everyone reads everything does not have a segregation problem worth solving. Imposing an authority-anchored control there buys ceremony and loses velocity. This argument is aimed at organisations that already have a reason to care, and I would not push it on ones that do not.

Identity-based checks are not worthless, and I have been harsh. They still stop the crudest failure, which is one person merging their own work with nobody else in the loop at all. That failure is common. A control that catches it cheaply and mechanically is worth keeping, as long as nobody mistakes it for evidence that judgement was applied.

Recording a criterion invites the criterion to be written for the control rather than for the work. Once “there must be a stated criterion” becomes a gate, some criteria will be written after the diff, to match the diff. That is a well-known failure of every documentation-based control, and I do not have a mechanical defence against it. The partial answer is timestamps and the order of events in the record, which raise the cost of retrofitting without eliminating it.

Separating specification from attestation genuinely costs you time. It means a second person has to understand the intent well enough to judge the outcome, and in specialised domains that person may not exist. In a team with one expert on a subsystem, insisting that they cannot both define and verify a change in it may mean the change does not get made. That is a real trade-off, not a rhetorical one.

And a complete, well-attested record can still describe a bad process. Provenance makes what happened legible. It does not make what happened correct. An organisation that can prove precisely how its weakly reviewed changes reached production has documented the problem with great fidelity.

The takeaway

Segregation of duties still works, but the usual implementation of it stopped testing what it was designed to test the moment one human plus one service account could occupy every role in the sequence.

Re-anchor it on authority. Three acts: state the criteria, produce the change, attest it meets them. The separation that matters is between the first and the third, the one everyone watches is the second, and none of it functions without a criterion recorded before the diff exists.

If you take one thing into next week: pick ten merged changes at random and, for each, name the party who stated what done meant and the party who attested it was met. Where those are the same person, your branch protection has been reporting green on a control that was not operating.