What an Agent-Authored Change Owes an Auditor

Ask an engineer what happened to a pull request six months ago and you will get a reasonable answer. Ask them to prove it and the answer changes shape. This is not a new problem, but agent-authored change makes it unavoidable, because the assumptions the old answer rested on no longer hold.

The audit question used to be answerable by a person. Someone wrote the code, someone else read it, a name went on the approval, and the trail was the names. That worked because the person who understood the change was usually the person who could speak to it later. An agent breaks that chain. The change may have been written by a model, sponsored by a human who never read it closely, and merged by a policy nobody remembers configuring.

When that happens, "who reviewed this?" has no satisfying answer, and it was never quite the right question anyway.

The question an auditor is actually asking

An auditor is not asking whether a change was reviewed. They are asking whether the organisation can demonstrate, after the fact, that the change was allowed to happen for a reason that still holds up.

That breaks into a small set of questions that a record either answers or does not.

What changed, and which parts of it did a machine produce. Not the whole pull request — the specific lines, and the agent that touched them. If the record cannot separate agent-authored change from human-authored change, the rest of the answers are about the wrong object.

Who was accountable. Not who clicked merge, but who carried the accountability for this change being allowed. For agent-authored work, that is a human sponsor, and the sponsor is a claim the record has to make explicitly.

What evidence was considered. Which checks passed, which work item the change was bound to, what the repository context was. An auditor does not need every signal; they need the ones the decision actually used, and they need to know that nothing material was left out.

What policy was applied. Not "our policy" in the abstract, but the exact version of the exact rules that produced this outcome. A policy that changed last month cannot explain a decision made last year.

Why this outcome. The decision itself, and the reason it was reached, stated in a form that does not require the reader to reconstruct anyone's intent.

Every one of those is a fact about the moment of the decision. None of them can be reconstructed later from memory, and most of them cannot be reconstructed later at all.

Why the usual evidence does not survive

Teams tend to believe they already have this. They point to the pull request, the CI logs, the chat thread, the ticket. Each of those is evidence of something, and none of them is evidence of the decision.

The pull request shows the diff and the approvals. It does not show which lines an agent authored, or which policy version was in force, or what evidence the decision consulted. It shows the ritual, not the reasoning.

The CI logs show that checks ran. They do not show what the checks were asked to establish, or whether their results were the ones that mattered.

The chat thread shows that people talked about it. It is not a record; it is a transcript, and a transcript is only as good as the memory of the person reading it.

Worse, all of these are mutable. A pull request description can be edited, a log can be rotated out, a thread can be deleted. Evidence that can be changed after the fact is not evidence an auditor can rely on, which means it does not answer the question no matter how complete it looks.

The uncomfortable asymmetry

There is an asymmetry that makes this harder than it first appears. When a human writes a change, the record of the decision and the record of the work are the same artifact — the person is the trail. When an agent writes the change, the work and the decision separate, and only one of them was ever being recorded.

So the organisation ends up with a thorough record of the work and almost no record of the decision. It can tell you what the code does and who touched it. It cannot tell you, with anything an auditor would accept, why it was allowed to merge.

The temptation is to solve this with more logging. Capture everything, keep it forever, and the answer must be in there somewhere. That fails for a specific reason: a pile of logs is not a record. An auditor needs to know which facts were load-bearing, and a system that records everything equally has not made that judgment. It has moved the work of the audit from the organisation to whoever is reading the pile.

What a decision record has to carry

The useful shape is narrower than "log everything." It is a record of the decision itself, produced at the moment the decision is made, carrying the facts that decision used and nothing else.

It should state the outcome and the reason. Not a status, a reason — something a reader can follow back to the policy rule that produced it.

It should name the evidence it considered. The checks, the work item, the repository context, and the attribution that ties the change to an agent and a sponsor. If the decision ignored a signal, the record should not pretend otherwise.

It should pin the policy version. A decision is only explainable against the rules that were in force when it was made.

And it should be signed, so that the record can be shown to be the record — unaltered since the moment of the decision, and verifiable without access to the system that produced it.

That last property is the one that changes the audit. If verifying the record requires logging into the system that made the decision, the auditor is trusting the system, not the record. A signature that can be checked independently is what turns a claim about the past into something a third party can confirm.

The objection worth taking seriously

The objection is that this is a lot of machinery to answer a question that most organisations are never asked. Audits are rare, the reasoning goes, and building for them is building for a bad day that may not come.

The objection would land if the record were only for auditors. It is not. The same record answers the questions a team asks itself constantly: why did this block, what changed about the policy last week, did the decisions match what we expected before we turned on enforcement.

Shadow mode is the clearest case. A team runs the engine in report-only mode precisely to compare the decisions against its own judgment. That comparison is impossible without a record of what each decision used. The audit record and the rollout instrument are the same artifact, which is why building it early is not speculative. It is the only way to earn the confidence that enforcement requires.

The auditor is the stress test, not the use case.

What this changes

If a decision record is a first-class output rather than a report generated on request, three things follow.

The audit becomes a verification instead of an investigation. The organisation produces a record, the record is checked, and the check does not depend on anyone's recollection or the system's availability.

The scope of what can be authorized widens without widening the scope of what has to be read. Routine agent-authored change can be authorized on evidence, because the evidence is recorded; the human attention goes to the changes that are genuinely novel.

And the accountability question gets a real answer. A record that names a sponsor, states a reason, pins a policy, and carries a signature is a stronger account of authority than a name on an approval, because it can be checked by someone who was not there.

The trail was never the signature. It was the ability to show your work. Agent-authored change did not create that requirement; it removed the person who used to satisfy it by remembering, and left the requirement standing.