Seven Places an Agent Must Never Write

I have argued elsewhere that agent authority should track how hard a write is to reverse rather than how capable the model is. That framing is useful for arguing. This is the version for actually doing.

Seven specific write operations inside an enterprise system that I would close to agents on day one, before anybody has chosen a model, and would keep closed through several generations of models. Each with the reason, because a rule whose reason nobody can state gets relitigated every quarter by whoever arrives next.

These are not closed because the model might be wrong. They are closed because being right is not sufficient authority to perform them.

One. Posting to the general ledger

A posted entry cannot be deleted. The correction is a reversing entry in an open period, and both live in the record permanently, so an agent's error is not undone, it is appended and then explained.

That alone would justify the boundary. The stronger reason is that posting is the moment a transaction becomes something an external party relies on, and reliance is what the entire control structure exists to protect.

Two. Executing a payment run

The money leaves the building. Recovery is a commercial negotiation with a counterparty who now has your funds, not a technical operation, and the time to notice is bounded by their willingness to give it back.

Payment runs are also unusually attractive to attack, which means an agent with this authority is not merely a reliability question. It is an expansion of the threat surface into a path that already gets attacked by people who are good at it.

Three. Closing or reopening a period

Closing changes what every other control in the system means. Reopening a closed period is worse, because it retroactively changes numbers that have already been reported, sometimes externally.

Period state is also how the organization coordinates. A close is dozens of teams agreeing to stop at the same moment. Software that can move that boundary can desynchronize an entire company's month, and it will do it far faster than anybody notices.

Four. Tax determination on a filed return

The requirement here is reproducibility and defense to an authority, not accuracy. You must produce the same answer twice, years apart, and explain the rule you applied to somebody with the power to assess a penalty.

A probabilistic system that is more accurate than the incumbent process is still the wrong shape, because the standard is not correctness on average. It is the ability to re-derive on demand.

Five. Creating or changing a bank account or remit-to detail

This is the oldest fraud path in accounts payable and it is still, by a wide margin, the most effective. Change where a legitimate supplier's money goes and every subsequent control passes cleanly, because everything about the payment except the destination is genuine.

Any process touching this is already wrapped in callbacks, dual approval, and out-of-band verification. Those controls specifically assume a human on both ends. Inserting an agent does not weaken one control, it invalidates the design of several.

Six. Granting or changing permissions

An agent that can modify permissions has no fixed boundary, only a current one. Every other restriction in this list becomes advisory, because the system's authority model is now something the agent can edit.

This holds even when the change looks trivial and even when a human approves it, because approval fatigue is real and the request will arrive looking exactly like the forty routine ones before it. Keep the authority model outside the agent's reach entirely; it is the one boundary that makes the others mean anything.

Seven. Editing the audit trail, or its retention settings

The audit trail is how you investigate every other item on this list. An agent that can write to it, prune it, or shorten its retention removes the ability to reconstruct what happened, including what it did.

This is the least likely of the seven to come up in a proposal and the most damaging to concede, because the loss is silent. You do not discover the gap until the day you need the record, which is by definition the worst day.

What this list is not

It is not a claim that agents are unsafe. Most of the value in enterprise AI sits well below these lines: drafting, reconciling, summarizing, explaining, proposing, checking. That work is large, real, and mostly unclaimed, and none of it requires a single item above.

It is not permanent in principle. If an agent can one day hold an identity the audit trail recognizes, be a genuine party to segregation of duties, and produce a reproducible derivation on demand, several of these deserve reconsideration. None of that is true today, and none of it is fixed by a better model, because none of it is a capability problem.

And it is not a substitute for the reversibility analysis on everything else. Seven doors closed does not mean the rest of the building is open. It means these are the ones not worth spending a meeting on.

Why write the list before choosing a model

Because the conversation is completely different depending on when it happens.

Stated on day one, this is architecture. It scopes the program, it answers finance's loudest objection before finance has to raise it, and it costs nothing because nothing has been built yet.

Stated in month seven, after a team has built something that crosses one of these lines, it is a political fight about sunk work, and the outcome depends on who has more standing rather than on what is correct. I have watched several of those. The correct answer usually wins eventually, some months and a good deal of goodwill later than it needed to.