Seven Writes I Would Keep Outside an Agent's Authority

I have argued elsewhere that agent authority should track how hard a write is to reverse rather than how capable the model is. Here I have applied it to specific operations.

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. I would record the reason for each restriction so that a later team can understand why it was chosen.

A correct result alone would not persuade me to grant these permissions. Each operation also has requirements for authority, review, and accountability.

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. The correction leaves both entries available for later review.

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 (Public Company Accounting Oversight Board, 2024).

Two. Executing a payment run

A payment transfers funds to another party. Recovery is a commercial negotiation with a counterparty who now has your funds, not a technical operation, and the runs themselves are already a favorite target: business email compromise remains one of the costliest reported crime categories year after year (Federal Bureau of Investigation, 2024). An agent with this authority is an expansion of the threat surface into a path that 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. Tight coupling is precisely the property that turns one bad write into a system-wide event (Perrow, 1999).

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, which is the same requirement regulated electronic records impose (U.S. Food and Drug Administration, 2025).

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

This is the oldest fraud path in accounts payable, and it still works. Change where a legitimate supplier's money goes and every subsequent control passes cleanly, because everything about the payment except the destination is genuine. The invoice is real. The goods were delivered. The approval chain approves, correctly, at every step. The only falsified fact in the entire transaction is a bank account number, and no control downstream of the master record ever looks at it again.

Which is why any process touching this field is already wrapped in ritual. A change request arrives and somebody in payables calls the supplier back, on the number held in the master record rather than the number in the request. A second person approves. The change waits out a holding period before the next payment run picks it up. Replacing those independent checks with an agent would require reviewing the control design, including which people verify the request and authorize the change. Layered defences depend on those responsibilities remaining effective (Reason, 2000).

Six. Granting or changing permissions

An agent with permission to widen its own access could undermine the restrictions around its other work. I would keep the authority model outside its reach.

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. Least privilege has said so since 1975 (Saltzer & Schroeder, 1975), and segregation of duties assumes an authority model no participant can quietly widen (Committee of Sponsoring Organizations of the Treadway Commission, 2013).

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 a missing record may only become apparent during an investigation. Regulated environments therefore treat the audit trail itself as a protected artifact with its own retention rules (U.S. Food and Drug Administration, 2025).

Work still available within these boundaries

These boundaries leave room for useful work: drafting, reconciling, summarizing, explaining, proposing, checking. Those tasks can be scoped without granting the permissions above. It is also where automation historically pays: leaving humans only the residual hard cases is the failure mode to avoid, not the goal (Bainbridge, 1983).

Nor is the list 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. Current governance frameworks are written to be revisited as exactly those conditions change (National Institute of Standards and Technology, 2023), and Article 14 of the EU AI Act provides for human intervention in high-risk systems within its scope (European Parliament & Council, 2024). I would require evidence that those conditions are met before revisiting a permission. An improvement in model performance alone would not answer them.

The remaining operations still need their own reversibility review. This list records my starting exclusions, not blanket permission for everything else.

Why write the list before choosing a model

The team should know these boundaries while it can still choose an approach that respects them.

Stated on day one, this is architecture, and it is far cheaper than the entanglement that accrues once a system has been built around an assumption (Sculley et al., 2015). It scopes the program, it answers finance's loudest objection before finance has to raise it, and it avoids designing around access the process owner may later refuse.

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.