Change management when the committer is a machine

Change management is the part of governance that engineers find most tedious and auditors find most important, and both positions are defensible. The frameworks are old, they are written in the vocabulary of a different era of computing, and they encode a set of controls that survive because the failures they prevent are expensive and invisible when prevention works.

They also contain an assumption so basic that it is rarely stated: a change has an author, the author is a person, and that person can account for what they did.

Agentic development does not satisfy that assumption, and the responses I see fall into two unhelpful camps. One insists nothing has changed and applies the existing process unmodified, which produces a control that is satisfied on paper and meaningless in substance. The other declares the frameworks obsolete, which is both wrong and a fast route to a finding.

The useful position is that the controls are asking sensible questions and the evidence that satisfies them has to change.

What the controls are actually asking

Strip the vocabulary away and most change control frameworks are asking five questions.

Was this authorised?Did someone with the authority to want this, want it. A question about intent, not implementation.

Was it reviewed by someone other than the author?Segregation of duties. The oldest control in the set and the least negotiable.

Was it tested before it reached production?Evidence of verification, and evidence of what the verification covered.

Can it be reversed?A rollback path that someone has actually exercised, not one that theoretically exists.

Is there a record?Enough to reconstruct what happened months later, for an auditor or an incident.

Read that list and the shape of the problem becomes clearer. Four of the five are about the process surrounding the change and are entirely answerable in an agentic pipeline, often better than before. Only the second one has a genuine structural complication.

Authorisation gets better, if you wire it up

Authorisation is the question of whether the change traces back to something a person with authority actually wanted.

In the traditional model this was weak. A ticket existed, an engineer worked on it, and the connection between the ticket and the resulting commit was a convention: someone typed the ticket number in the branch name, usually, when they remembered. Auditors accepted this because there was nothing better available, and everyone knew that the mapping between what the ticket asked for and what the commit did was unverified.

An agentic pipeline can do considerably better, because the work is initiated from the intent rather than merely associated with it after the fact. The chain from ticket to criteria to generated change to verification result exists as data rather than as a naming convention.

This is worth pressing on with auditors, because it is a case where the new model is stronger than the old one and the instinct in the room will be to assume the opposite. The claim “we can show you, for any line in production, the ticket that authorised it, the criteria it was built against, and the evidence those criteria were met” is a stronger authorisation control than any manual process produces.

Segregation of duties is the real problem

Here is where it gets genuinely difficult, and I want to resist the temptation to make it sound solved.

Segregation of duties says the person who makes a change is not the person who approves it. The purpose is to ensure at least two minds, with at least partly independent interests, were applied. It is a control against both error and fraud, and it is the one auditors will not trade away.

Now consider the common pattern. An engineer writes a prompt describing a change. An agent produces the change. The engineer reviews it and approves it.

Has segregation been satisfied? There are two defensible readings and they lead to opposite conclusions. One says yes: two distinct actors, one produced and one approved. The other says no, and I think this reading is stronger: the engineer specified the change and the agent executed the specification, which makes the engineer the author in every sense that matters. Approving your own specification is self-approval with an intermediary.

Segregation in appearance

• Engineer specifies, agent generates
• Same engineer approves the result
• Two identities in the log
• One mind applied to the decision
• Passes a naive control test

Segregation in substance

• Engineer specifies, agent generates
• A second human approves
• Or: independent automated verification plus human sign-off on criteria
• Two genuinely independent judgements
• Survives a competent auditor

The practical resolution most organisations land on has two parts. For changes with meaningful blast radius, a second human approves, full stop, and the agent’s involvement is irrelevant to that requirement. For lower-risk changes, the independent judgement comes from criteria that were authored separately from the change and verified automatically, with a human accountable for the criteria rather than for each instance.

That second arrangement is defensible but it requires something most organisations have not built: criteria authored by someone other than the person prompting the change, under version control, with their own review process. If the same engineer writes the criteria and the prompt, the independence is gone again and you are back to self-approval with two intermediaries instead of one.

Testing evidence gets stronger and more specific

The testing control usually asks whether the change was tested. Answers historically were weak: a coverage percentage, a green pipeline, a checkbox.

An agentic pipeline can answer a better question, which is what was verified rather than whether tests ran. For a given change, the criteria it was built against, the checks that evaluated those criteria, and the result of each. That is more specific evidence than a pipeline status, and it maps directly onto what the control is trying to establish.

It also exposes something uncomfortable, which is that the evidence now makes clear what was not verified. A pipeline that is simply green hides its own coverage gaps. A record listing four criteria and their results invites the question of what the fifth criterion should have been. This is an improvement that will not feel like one during the first audit.

The record, and why self-reported logs are not enough

The last control is documentation, and this is where agentic pipelines have a specific vulnerability worth naming.

At volume, the record is produced by the same system that performs the actions. A pipeline that merges changes and writes its own log of having merged them is attesting to its own behaviour. For most purposes that is fine. For a control environment, it is exactly the circular arrangement that controls exist to avoid, and a competent auditor will ask about it.

The mitigations are ordinary and worth doing before someone asks: records signed at the boundary rather than by the acting component, append-only storage the pipeline cannot rewrite, and a chain where each link references the previous one so that removal is detectable rather than silent.

IntentTicket, requester, business justification. Signed at creation.

CriteriaWhat done means, authored and reviewed separately from the change. Versioned.

GenerationWhich agent, which runtime, on whose behalf, against which criteria.

VerificationEach criterion and its result. Explicitly including what was not checked.

ApprovalWhich human, with what authority, at what time. Independent of the specifier.

DeploymentWhat went where, when, and the rollback path with its last exercise date.

Where this breaks down

Some frameworks specify human review by rule, not by outcome. Where a control literally requires a named person to have inspected the change, no amount of superior automated evidence substitutes. Arguing the control is outdated is a losing strategy during an audit. The productive move is to make that human review fast and well-informed and to save the framework conversation for a different meeting.

Independent criteria authorship is organisationally expensive. The clean answer requires criteria written and reviewed separately from the implementation, which means a person and a process. Small teams cannot always afford it, and the honest fallback is to accept that low-risk changes have weaker segregation and to draw the risk line conservatively.

Emergency changes break every model. At three in the morning during an outage, the process is bypassed, and it should be. Every framework has a break-glass provision, and the quality of an organisation’s change management is mostly determined by what happens in the retrospective review of those events rather than by the steady-state process.

Auditors are not uniform. Some will accept a cryptographic chain as superior evidence and engage with it seriously. Others will want the artefact they recognise, which is a person’s name in an approval field. Both exist, and the work of preparing for the second kind is largely translation rather than engineering.

A perfect record of a bad process proves the process was bad. Comprehensive provenance is not the same as good control. It makes weak controls legible, which is genuinely valuable and is not what most people expect when they invest in it.

The takeaway

Change control is asking five reasonable questions and four of them are answered better by an agentic pipeline than by the manual process it replaces. Authorisation, testing evidence, reversibility and documentation all improve when the chain from intent to production exists as data.

The fifth question, segregation of duties, is genuinely harder and does not have a clean answer. Specifying a change and approving the result is self-approval regardless of what generated the code in between. The workable resolutions are a second human on anything with blast radius, and independently authored criteria on everything else.

If you take one thing into next week: look at your last twenty merged changes and ask whether the person who described the change is the person who approved it. In most teams the answer is yes far more often than anyone would want to state in an audit.

The next piece takes the remaining governance question, which is what happens after the control fails: incident response when the thing that caused the incident was an agent.