Coding agents now open about 60% of the pull requests across your 900 repositories. They run under one bot identity that is also permitted to approve and merge. Your segregation-of-duties control states that every change needs an approval from someone other than its author, and the evidence shows an approval on every merge. Which change actually restores the control?
Show the full answer Hide the answer
The deciding property
Segregation of duties counts actors with intent, not accounts. An agent is a tool; the actor is the person who told it to act. One bot identity that can author and approve is one actor doing both halves of the control, however many pull requests pass through it, and the approval records it leaves behind are evidence of a control that is not operating.
So the deciding property is whether the system can name the human behind a change at the moment the approval requirement is evaluated.
The mechanism that makes it work
Mint a short-lived credential per agent run that carries the triggering user as a claim, the way workload identity federation already carries a subject into a cloud API call. The pull request then has an actor, distinct from the bot that typed the diff, and the branch rule compares approver to actor rather than approver to author. Three settings make it hold:
- The bot identity holds no approval permission at all, so an agent cannot satisfy the requirement even by accident.
- Administrative merge and rule bypass are counted, not forbidden, and any bypass merge on a protected repository alerts the same day - a control with an untracked override is a control over the subset of changes that chose to use it.
- The actor claim is recorded in the merge evidence, because the audit question a year later is who authorised the change, and "the automation" is not an answer.
Why the other options fail
- Rotating the credentials is good hygiene against theft and does nothing here. The identity is being used exactly as issued; the problem is what it is permitted to do.
- Two approvals instead of one multiplies a requirement the bot can already satisfy. If the bot can approve, two approvals from the bot is still zero actors.
- A weekly report of author-equals-approver merges is a useful detective control and a poor substitute for a preventive one. It finds the violations after the change is in production, and it will not catch the case where the bot approves work that a different bot session authored.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| Agents can only propose and a human presses merge in a session | the weekly report | the preventive control already exists in the interface |
| Agents can self-merge | actor attribution | nothing else distinguishes the two halves |
| Changes are generated artefacts such as lockfiles or SBOMs | an explicit carve-out with a waiver | human approval adds no judgement and the queue trains people to click |
| A regulator samples change approvals | actor attribution plus bypass alerting | the sample will include the 03:00 self-approved merge |
When this is the wrong answer
For a repository whose contents are machine-generated and verified by a check, approval theatre is worse than no approval: it consumes reviewer attention and produces an evidence record asserting judgement that nobody exercised. Carve it out in the open, with a named owner, an expiry and a compensating automated verification, so the exception is a decision rather than a habit. The same applies below a size threshold: with one team and twenty repositories, the preventive rule costs almost nothing and the attribution plumbing is probably not worth the week.